Debugging and Troubleshooting: Fixing Code and Circuits

Every programmer and maker gets things wrong, constantly, and debugging is the skill that turns those failures into working projects. This lesson covers the kinds of errors you will meet, a systematic way to hunt them down, and the libraries that let you reuse proven code instead of reinventing it. You will practice by driving a seven-segment display and showing a live sensor value on an OLED screen.

The three kinds of errors

Errors come in three flavors, from friendliest to worst. A syntax error is a typo the compiler catches, such as a missing semicolon or an unbalanced bracket; your code will not even compile until you fix it, which makes these quick to solve. A logic error is harder: the program compiles and runs, but does the wrong thing, because the logic itself is flawed. These can hide for a long time and are the everyday work of debugging. A hardware error is the trickiest, because your code may be perfectly correct while a miswired or faulty component makes it fail anyway. Knowing which kind you are facing points you at where to look.

A systematic way to debug

Do not stare at the whole program hoping the bug jumps out. Break the code and circuit into small parts and test each on its own; this is one more reason to write clean, function-based code. Lean on the Serial Monitor: print sensor values every pass, and drop in simple markers like printing reached here so you know which parts actually run. Check your wiring physically, because a component not fully seated in the breadboard makes an incomplete connection. Above all, simplify and isolate: once you suspect where the trouble is, ignore the rest and narrow in with print statements until the exact line reveals itself.

Rubber-duck debugging

A classic trick for logic errors is to explain your code out loud, line by line, to a rubber duck on your desk, as if teaching a coworker. Surprisingly often you catch the mistake mid-sentence: you say what a line should do, notice it does something else, and the bug reveals itself. The value is in forcing yourself to articulate your assumptions rather than skim past them.

Libraries: reusing proven code

A library is a collection of pre-written code that makes a component or a complex task easy to use. You have been using one all along: functions like pinMode and Serial.println come from the board's core library, which the editor automatically includes for you when you compile. When you need capabilities beyond the built-ins, you add a library and call its ready-made functions instead of writing hundreds of lines yourself. An OLED graphics library, for instance, hides all the low-level display communication so display.print does in one line what would otherwise take hundreds.

Two ways to add a library

The first is the built-in Library Manager: open Sketch, then Include Library, then Manage Libraries, search by name, and install. The second, and the recommended one for your kit, is adding a ZIP file: download the tested library ZIP from craftingtable.com/downloads, then choose Sketch, Include Library, Add .ZIP Library, and select the file. The ZIP versions have been verified against your exact hardware. One thing to watch: if you import the same library twice you will get a duplicate-definition error, so remove the extra copy if that happens.

Working through it

Wire and initialize the seven-segment display. Connect the four-digit display's digit and segment pins to the board following the diagram, and add the SevSeg library. Include its header, then create an object, for example SevSeg sevseg, which is how you call the library's functions.

Configure the display in setup. Store the digit pins and segment pins in byte arrays; byte is used instead of int because these small pin numbers do not need int's larger memory. Call sevseg.begin with the display type (common anode or common cathode), the number of digits, and the two pin arrays, then set the brightness.

Show a number and debug it. In loop, call sevseg.setNumber(1234) and sevseg.refreshDisplay(). If nothing lights, work the checklist: are the pins on the right board pins, is the display getting power and ground, and is the common anode or cathode setting correct for your specific part? Flipping that setting is a common fix.

Wire the OLED and potentiometer. Connect the OLED over I2C using the SDA and SCL pins, and a potentiometer to A0. Add the Wire and U8g2 libraries, which handle communication with the screen.

Display the live sensor value.