SWYoon Labs

Series navigation: Episode 1: The Roadmap · Episode 12 The problem: One physical press increments a counter several times. The goal: Turn a noisy mechanical transition into one intentional software event. The result: A beginner-friendly choice between polling, software debounce, hardware filtering, and interrupts. AI-generated illustration showing the idea of contact bounce; the waveform is explanatory, not a claimed measurement. I pressed once, but the program counted four times The button wiring was correct. The input had a pull-up. Yet one press produced several events. Mechanical contacts do not always change cleanly from open to closed. They can touch, separate, and touch again for a short interval. A fast microcontroller sees those transitions individually. This is contact bounce . It is neither random software behavior nor the same problem as a floating pin. Three different layers Layer Question Electrical state Does the input have a pull-up or pul...

Series navigation: Episode 1: The Roadmap · Episode 11 The problem: A 5 V module and a 3.3 V controller have matching signal names, but direct wiring may fail or damage an input. The goal: Check voltage limits and logic thresholds in both directions. The result: A decision process for direct connection, dividers, buffers, and level translators. AI-generated illustration of a mixed-voltage workbench. Verify every connection against the exact device data sheets. The connector fit, so I almost connected it The peripheral board had VCC , GND , TX , and RX . The microcontroller had pins with the same names. One board used 5 V and the other used 3.3 V. Matching names describe functions, not electrical compatibility. Before joining the wires, I needed answers to two separate questions: Will a HIGH output be recognized as HIGH by the receiver? Can the receiver safely tolerate the maximum voltage? Passing the first test does not guarantee the second. Four data-sheet value...

Series navigation: Episode 1: The Roadmap · Episode 9: SPI LCD Debugging · Episode 10 The problem: A button input changes even when nobody presses it. The goal: Give every digital input a defined idle state. The result: A practical wiring and debugging checklist for pull resistors, polarity, noise, and shared ground. AI-generated illustration of a low-voltage GPIO debugging setup; it is not a record of a physical measurement. The button worked—until my hand moved near it I connected a pushbutton to a microcontroller, read the pin, and expected either HIGH or LOW . Instead, the value changed randomly. Touching a wire sometimes changed it again. The code was deterministic. The voltage at the input was not. A digital input is not automatically zero when nothing drives it. Its high impedance makes it easy to sense, but also allows leakage, electric fields, long wires, and switching signals nearby to move the voltage across the logic threshold. This is a floating input ....

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 9 The problem: The LCD backlight turns on, but the screen remains white. The goal: Separate display power from successful SPI communication and initialization. The result: A checklist for SCK, MOSI, MISO, CS, D/C, RESET, voltage, clock mode, and command order. AI-generated illustration of a low-voltage SPI debugging setup. Verify wiring against the exact display-controller data sheet. The backlight was on, so I assumed the LCD was working I connected a color display. It lit immediately, but the entire panel stayed white. The result is misleading. The backlight is often a separate load. It can receive power while the display controller is unpowered, held in reset, never selected, wired incorrectly, or receiving the wrong initialization. A white screen does not mean “SPI is almost working.” It only proves that light passes through the panel. What each wire does...

Series navigation: Episode 1: The Roadmap · Episode 2: Digital Multimeter and LED Circuit · Episode 3: Voltage Divider Under Load · Episode 4: What an Oscilloscope Shows · Episode 5: How Arduino Reads Sensor Voltage · Episode 6: Why Arduino Cannot Drive a Motor Directly · Episode 7 The surprising part: The ATmega328P data sheet contains a 40 mA-per-pin number, but designing an Arduino output to operate at 40 mA is the wrong conclusion. What you will learn: How to tell a damage boundary from a usable operating specification and turn one design question into a short path through a long data sheet. What you will be able to do: Identify the exact device and package, read conditions and footnotes, and record a defensible design decision instead of copying the first number you find. AI-generated illustration of a data-sheet-reading workflow. The tables are visual placeholders, not copied specifications; use the manufacturer's current document for design values. Reader...

Series navigation: Episode 1: The Roadmap · Episode 2: Digital Multimeter and LED Circuit · Episode 3: Voltage Divider Under Load · Episode 4: What an Oscilloscope Shows · Episode 5: How Arduino Reads Sensor Voltage · Episode 6 What you will learn: Why a GPIO pin can send a command but should not supply a motor's power. What problem it solves: A motor may fail to start, reset the board, overheat an output pin, or damage the controller when connected directly. What you will be able to do: Explain a low-side N-channel MOSFET circuit, choose parts from their important ratings, and identify where motor current flows when switching on and off. AI-generated instructional image of a typical low-voltage workbench. It is not a wiring reference or a photograph of a circuit tested for this article; use the schematic below for connections. Reader guide Indicator Details Article type Power-interface concept and design checklist Reading time About 12 minutes ...