SWYoon Labs

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 16 The problem: A wire patch makes Revision A work, but the next board may repeat the same mistake. The goal: Convert symptoms and workarounds into traced design changes and regression tests. The result: A Revision B process that preserves evidence instead of hiding failure. AI-generated illustration of hardware iteration. The boards and defect notes are not artifacts from a physical project. The wire patch worked—so was the board fixed? Revision A would not start reliably. A wire was added, one resistor changed, and the board began working. That is a valuable diagnostic result, but it is not yet a controlled design revision. The patch may create a new antenna, bypass protection, depend on assembly skill, or fix only the one unit on the desk. In software, a quick production patch should eventually become a reviewed source change and regression test. Hardware ne...

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 15 The problem: Connecting full power immediately can turn one assembly error into several damaged parts. The goal: Make first power-on a sequence of reversible tests with stop conditions. The result: A bring-up checklist from visual inspection to firmware and interfaces. AI-generated illustration of preparation for first power-on. No measurement shown is evidence from a real board. I wanted to plug in USB and see the LED blink After waiting for a new PCB, the natural impulse is to connect everything and run the full program. That single action combines too many unknowns: assembly, polarity, shorts, regulators, clocks, reset, programming, firmware, and external devices. If smoke appears, the evidence has already been destroyed. First power-on should be deliberately boring. The objective is not to demonstrate the whole product. It is to discover the first incorr...

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 14 The problem: A routed board can look complete while containing a mirrored connector, missing return path, or untestable power rail. The goal: Review electrical intent, physical reality, manufacturing, assembly, and test before ordering. The result: Twelve checks that turn “DRC passes” into a reviewable release decision. AI-generated illustration of a design review, not a manufactured board from this series. The green board on the screen looked like a product The traces were routed, the ground zone was filled, and the 3D view looked convincing. That visual finish created a dangerous feeling: the PCB seemed done. Then a review question changed everything: If the connector is mounted on the real board, which side is pin 1 on? The layout was not a product yet. It was a set of assumptions waiting to meet copper, components, cables, tools, and a manufacturer. ...

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 13 The problem: The prototype works, but its meaning exists only in wire colors and memory. The goal: Convert physical connections into named, reviewable electrical intent. The result: A schematic checklist that becomes the source of truth for PCB design. AI-generated illustration of the documentation transition. It is not a circuit to copy. The prototype failed after I cleaned the desk The breadboard had worked the night before. I disconnected a few wires to organize them, rebuilt the circuit from a photo, and the sensor disappeared. The photo showed where the wires appeared to go. It did not explain which nodes were power, ground, I2C, reset, or an intentionally unused pin. It also did not reveal the breadboard's hidden internal strips. A working breadboard proves that one physical arrangement worked once. A schematic explains the intended electrical rela...

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 7: Reading Arduino Pin-Current Specifications · Episode 8 The problem: A terminal shows random symbols even though both devices say “UART.” The goal: Understand what must match electrically and logically before bytes become readable text. The result: A debugging order for TX/RX, ground, voltage, baud rate, frame format, buffering, and signal capture. AI-generated illustration of a low-voltage UART bench. It is not a measurement record or exact wiring guide. The terminal opened, but the text looked broken UART is often the first communication interface I use on a board. It prints boot messages, accepts commands, connects two controllers, or talks to a GPS, modem, Bluetooth module, serial display, or USB-to-serial adapter. Then the terminal shows this: text ��H�l� The program may be sending Hello , but UART does not transmit software strings. It places timed voltage levels on a wire. The receiver must agree about vo...