How to use this course

Each lab tells you which of three lab modes it suits.

Simulate means you build the circuit and run the program on a website that pretends to be the hardware. No parts needed. Wokwi runs Arduino code on pretend boards. Tinkercad Circuits has a pretend classic Arduino Uno and a breadboard. Falstad's simulator shows current moving around a circuit, with no chip involved. You open these sites yourself, and make a free account where one is needed. The course never relies on them. They also lag behind new boards. In October 2026, Wokwi's list of boards had the older Arduino Uno and the ESP32-S3, but not the Uno R4. So a simulated Uno R4 lab runs on the older Uno instead.

Build means you wire it up on your own breadboard and run it on your own board. Only this mode shows you what real parts do. A wire half out of its hole. A USB cable that charges but can't carry data. A sensor that reads two degrees too warm.

Both means you simulate first to get the program right, then build it for real. When the parts are new to you, this is the safest path.

Keep one thing in mind. A simulator copies how parts are supposed to behave. It can't test your actual parts. If your code works there, you know your logic and your wiring plan are right. You don't yet know about your hardware.

Every lab names one of three lab modes:

• Simulate. Build the circuit and run the program in a free online simulator. Wokwi (wokwi.com) simulates microcontroller boards running Arduino code; Tinkercad Circuits (tinkercad.com) simulates a classic Arduino Uno with parts on a breadboard; Falstad's circuit simulator (falstad.com/circuit) animates currents and voltages in a circuit with no microcontroller. You open these yourself, on your own account where one is needed; the course never depends on them. Simulators lag behind new boards: as of 2026-10, Wokwi's supported-hardware list includes the Arduino Uno (ATmega328P) and the ESP32-S3 but not the Uno R4 (Wokwi docs), so a simulated Uno R4 lab runs on the older Uno instead.
• Build. Wire it on your breadboard and run it on your own board. This is the only mode that meets real-part behaviour: a loose jumper, a USB cable that only charges, a sensor that reads two degrees high.
• Both. Simulate first to get the logic right, then build. This is the most reliable route when parts are new to you.

A simulator models its parts; it does not test them. Code that works in one has proved its logic and your wiring plan, not your hardware.

People say firmware "works" when they mean three quite different things. This course keeps them apart.

1. Compiled for a board. The code was turned into a program with the real tools for that exact board, and it built without errors. Each code box on these pages names its boards, for example "Arduino sketch · Uno R4 Minima, ESP32-S3". Each one was built for those boards when the site was made. That proves the code is written correctly and only uses commands the board has. It does not prove the program does what you want.
2. Logic unit-tested on the host. A lab you download keeps its thinking part apart from its hardware part, such as a table of blink timings. That part comes with tests. A unit test is a small program that runs one piece of code and checks its answer. These tests run on an ordinary computer, called the host. That proves the logic is right, but not the wiring.
3. Hardware-tested. A real person ran it on that board and wrote down what happened. Only this covers wires, timing and real parts.

Unless a page says otherwise, the labs here are compiled and host-tested. We have not tested them on hardware. When a page says what an LED "should" do, that is what to expect, not a recording of a real run. No page runs code in your browser or pretends to be a board.

Every hardware example names its board. Where the wiring or code is different, a board switch shows each version. Choose your board once. Every switch like it, on every page, then follows your choice. Here is one.

Three claims can be made about a piece of firmware, and they are not the same:

1. Compiled for a board. The code was built with the real toolchain for that exact board. Every sketch on these pages is labelled with its boards, for example Arduino sketch · Uno R4 Minima, ESP32-S3, and was compiled for each one when the site was built. That proves it has no syntax or type errors and that every function it calls exists for that board. It does not prove the program does the right thing.
2. Logic unit-tested on the host. A lab's downloadable project keeps its board-free logic (a timing table, a state machine) in separate files with tests, and those tests run on an ordinary computer, the host. A unit test is a small program that runs one piece of code and checks the result. That proves the logic, not the wiring.
3. Hardware-tested. A person ran it on the named board and recorded what happened. That is the only claim that covers wiring, timing and real parts.

Unless a page says otherwise, the labs here are compiled for their boards and host-tested, and not hardware-tested by us. When a page describes what an LED or a serial window should show, that is the expected behaviour, not a recorded run. No page runs code in your browser or pretends to be a microcontroller.

Every hardware example names its board. Where wiring or code differs, a board switch shows each version. Pick your board once and every such block on every page follows it. Here is one.

The chapters are written to be read in order. If you are new to all of this, do exactly that. If you already know some of it, you can follow a shorter route, a suggested list of chapters:

• Beginner maker: chapters 0 to 5, then 7, 8, 10, 11, 12, 16 and 17, then the first big project at the end.
• Arduino and electronics: chapters 0 to 13 and 16 to 19, then the first two big projects.
• Programmer new to hardware: chapters 0, 2, 3, 5, 6, 8, 9, 11 to 15, and 19 to 22. It skips Chapter 10, the short C++ course.
• Embedded C/C++: chapters 9, 13 to 15, and 20 to 22.
• Low-power devices: chapters 4, 6, 20, 22 and 23, then the battery-powered project.

A route is only a suggestion. Every page stays open to you. If a later page uses a word you don't know, the chapter you skipped is where to look. You don't have to buy all the parts at once, either. Chapter 1 says which parts each chapter needs.

The chapters are written to be read in order, and a beginner should do exactly that. Readers who arrive with experience can take a shorter route, a suggested subset of chapters:

• Beginner maker: 0–5, 7, 8, 10, 11, 12, 16, 17, then the first capstone project.
• Arduino and electronics: 0–13 and 16–19, then the first two capstones.
• Programmer new to hardware: 0, 2–3, 5–6, 8–9, 11–15, 19–22. It skips the Chapter 10 C++ primer.
• Embedded C/C++: 9, 13–15, 20–22.
• Low-power devices: 4, 6, 20, 22–23, then the battery-powered capstone.

A route is a reading guide, not a lock: every page stays open, and a skipped chapter is the place to look when a later page uses a term you don't know. Hardware can be bought chapter by chapter, since Chapter 1 §3 says which parts each chapter needs.