2 Microcontroller Programming: Setup and GPIO

2.1 Overview

This first route takes a board from toolchain setup through a testable GPIO sketch and stable inputs.

This is part 1 of 2. Continue with Microcontroller Programming: Timing and Reliability for the second focused route.

Phoebe’s Field Notes: delay(250) Is A Nyquist Choice, Whether The Sketch Knows It Or Not

The mathematical gist. delay(250) produces a 4.0 Hz sample rate and a 2.0 Hz Nyquist ceiling. That is ample for room temperature, but a 100 ms button event needs at least 20 Hz, or a 50 ms interval—five times faster. Separately, a 12-bit ADC over 3.3 V has 0.806 mV steps, which an LM35’s 10 mV/°C slope turns into 0.0806 °C per code.

Math Bridge · guided foundationsWhen does delay(250) make a real event disappear?Let Voltage Vera turn one polling interval into sample rate, event coverage, and LM35 resolution. Learn the maths

2.2 Start With the Story

Picture a soil-moisture prototype that “sometimes works” on a desk. The sensor is wired, the board is powered, and the sketch uploads, but the readings freeze whenever serial output gets noisy. Before adding a radio, dashboard, or enclosure, the team needs one simple firmware story: prove the board starts, prove the loop keeps running, prove each input changes visibly, and prove timing does not hide a fault.

This chapter turns that story into a repeatable firmware habit. Every sketch should leave a record of board profile, pin choices, serial evidence, timing behavior, and the next risk it has not proved yet.

2.3 Firmware Makes Wiring Behave

In Figure 2.1, A microcontroller sketch is the bridge between a wiring diagram and observable device behavior. The code must configure pins, sample inputs, update outputs, keep time, and report enough evidence to show what the prototype actually did.

In Figure 2.1, The route in the figure is the minimum path from “the board powers on” to “the prototype behavior can be defended.” First prove the toolchain can upload to the exact board and port. Then prove setup() initializes the hardware once and loop() returns often enough to read inputs, update outputs, and report state. Only after that should the sketch combine GPIO, ADC, serial output, timers, and interrupt flags.

The safest beginner habit is to keep each loop pass short. Read inputs, update state, write outputs, log the important observation, then return quickly so the device can respond to the next event. A prototype that blinks an LED but blocks for five seconds may look alive while missing button presses, sensor thresholds, watchdog timing, network retries, or actuator safety checks. Good firmware turns wiring into behavior that another engineer can reproduce from board profile, code version, wiring, serial output, and timing notes.

That evidence habit matters across Arduino Uno, ESP32, RP2040, STM32, nRF52, and similar boards because the sketch structure can look familiar while the electrical limits, ADC scale, pull-up behavior, interrupt pins, timers, and library internals differ. The chapter’s goal is not to memorize every board package; it is to make each firmware boundary visible before adding more sensors, radios, storage, or cloud code. In a lab notebook, that means tying every behavior claim to a serial trace, measured pin state, wiring photograph, and board configuration rather than to memory of a successful upload.

2.4 Prove Firmware Steps Separately

Build confidence one boundary at a time before combining sensors, communication, and actuator behavior. Start with the smallest sketch that can prove upload, reset, and serial output. Record the board profile, USB or serial port, board-support package version, sketch hash or filename, serial baud rate, and the exact message observed after reset. If that record is missing, later sensor or network debugging starts on uncertain ground.

For hardware I/O, isolate each path before composing the behavior. A digital output test should prove the pin can drive the selected LED, relay input, MOSFET gate, or indicator within the board’s current and voltage limits. A digital input test should prove the default state, pull-up or pull-down choice, debounce behavior, and disconnected-wire failure mode. An ADC test should record reference voltage, raw count range, conversion formula, expected sensor range, and what happens at open-circuit or saturated input. A serial, I2C, or SPI test should record the port, address or chip-select, speed, library version, and one known-good transaction.

For timing, replace long delay() calls as soon as two jobs must share the device. Use elapsed-time checks with millis() or the board’s equivalent so LED status, sensor sampling, serial logging, button handling, communication retry, and safety checks can run on their own intervals. For interrupts, keep the ISR short: capture a timestamp, increment a counter, or set a volatile flag, then let loop() copy that state, log it, and run the heavier application work. Treat every proof as a handoff record, not just a working demo.

• Upload proof: record board profile, port, core version, sketch version, and the smallest sketch that proves the toolchain can reach the board.
• I/O proof: test each GPIO, ADC, serial, I2C, or SPI path with expected values and one fault case, such as disconnected input or out-of-range reading.
• Timing proof: replace long delay() calls with elapsed-time checks so sampling, logging, communication, and safety checks can share the loop.
• Interrupt proof: keep ISR work short, set a flag or capture a timestamp, and do the real processing in loop() where it can be logged and tested.

2.5 Under the Hood: The Loop Is a Scheduler

Arduino-style firmware looks simple because setup() and loop() hide runtime startup, timers, serial buffers, board package details, and sometimes an RTOS task. Blocking code can still starve sensor reads, watchdog resets, communication retries, or actuator safety checks.

Non-blocking firmware treats the loop as a small cooperative scheduler. Each task decides whether it is time to run, does bounded work, records evidence, and gives control back. That pattern scales better when the prototype later adds networking, storage, OTA updates, or power management. It also makes failures easier to localize because a missed sample, repeated reset, or stale network send can be tied to the task that monopolized the loop.

The hidden machinery differs by board. On a classic AVR Arduino, the sketch often runs close to the foreground loop model. On ESP32 Arduino, loop() runs inside a FreeRTOS task while Wi-Fi, Bluetooth, timers, and system services use other tasks and interrupts. On RP2040, dual-core behavior and PIO peripherals can move timing-sensitive work outside the normal loop. On nRF52 or STM32 boards, vendor SDK layers, timer peripherals, DMA, and low-power modes can change which code runs while the main loop appears idle.

On a Cortex-M style board, that hidden machinery has a concrete execution model. Normal application work runs in thread mode; an interrupt briefly runs in handler mode, then returns. Core registers such as r0 through r3 carry arguments and return values, while r13, r14, and r15 act as the stack pointer, link register, and program counter. The vector table at address 0x0, or at a relocated vector-table address on some firmware, points reset, fault, service, and chip-specific IRQ entries at their handlers. A prototype record does not need to memorize every register, but it should prove that the intended IRQ is attached, the fault path is visible, and shared values are copied safely when handler code and normal loop code touch the same state.

2.6 Learning Objectives

By the end of this chapter, you should be able to:

• Explain the setup() and loop() execution model used by Arduino-style firmware.
• Configure GPIO pins for digital output, digital input, and pull-up button input.
• Read analog sensor values and convert raw ADC counts into engineering units with board-specific limits.
• Use serial output as an evidence stream for debugging and prototype review.
• Replace blocking delay() patterns with millis()-based scheduling.
• Use interrupts safely by keeping ISR work short and moving processing into the main loop.
• Capture enough firmware evidence for another engineer to reproduce the result.

2.7 Chapter Route

This chapter is not a catalog of every Arduino function. It is the minimum firmware route needed before the hardware, software, and kit chapters become useful.

2.8 Board And Toolchain Setup

Arduino-style programming is an API and build workflow, not one chip family. The same sketch structure can target 8-bit AVR boards, ARM Cortex-M boards, ESP8266, ESP32, and newer RISC-V based boards, but voltage limits, pin capabilities, memory, ADC behavior, and interrupt details vary by board.

Use this setup sequence:

1. Install Arduino IDE 2.x or a compatible workflow such as PlatformIO.
2. Install the board support package for the board you actually have.
3. Select the exact board model and serial port.
4. Upload a minimal sketch.
5. Open the serial monitor and confirm baud rate, reset messages, and expected output.
6. Save board model, core version, library versions, wiring, and test result in the prototype record.

2.9 setup() And loop()

Most Arduino-style sketches have two required functions:

void setup() {
    // Runs once after reset.
    // Configure pins, start Serial, initialize sensors.
}

void loop() {
    // Runs repeatedly.
    // Read inputs, update outputs, process state, report evidence.
}

Behind that simple structure, the board support package initializes clocks, memory, pins, timers, and runtime services. Some boards run loop() directly; ESP32 Arduino runs it as a FreeRTOS task. The beginner mental model still holds: initialize once, then repeat small units of work forever.

The execution model matters because initialization and repeated work have different lifetimes. In Figure 2.2, compare the labelled setup() and loop() regions before deciding where a line of firmware belongs.

Figure 2.2 marks RUNS ONCE beside setup() and RUNS FOREVER beside loop(). The examples reinforce the split: Serial.begin(115200); initializes the serial interface, whereas temp = dht.readTemp(); belongs to the repeating sensor work. This distinction carries the programming narrative from board start-up into responsive operation: configure once, return through the loop often, and measure whether any repeated task prevents the others from running.

2.10 First Sketch: Blink With Evidence

The first sketch should prove that the toolchain, USB cable, board selection, upload path, reset behavior, and serial monitor work.

const int LED_PIN = LED_BUILTIN;

void setup() {
    pinMode(LED_PIN, OUTPUT);
    Serial.begin(115200);
    Serial.println("boot: blink evidence sketch");
}

void loop() {
    digitalWrite(LED_PIN, HIGH);
    Serial.println("led=on");
    delay(500);

    digitalWrite(LED_PIN, LOW);
    Serial.println("led=off");
    delay(500);
}

This version still uses delay() because it is a first hardware proof. Later in the chapter, you will replace that blocking pattern with millis().

2.11 Sketch Syntax Review

Arduino sketches use ordinary C/C++ building blocks, but the review question is always tied to firmware behavior. Record the type, range, and lifetime of values that cross a hardware boundary. A bool flag can describe a button state, an int or long counter can hold pulse counts or elapsed time, a float can carry a converted sensor value, and byte or unsigned values often appear in register, address, and buffer work. Use the smallest type that keeps the measurement honest, then note the unit and expected range in the prototype record.

Operators and control statements should make the device state readable. Arithmetic operators convert raw readings, comparison and Boolean operators test thresholds, bitwise operators mask register flags or packed status bytes, and compound assignments update counters without hiding the meaning. if/else, switch, for, while, and do...while blocks are acceptable when the stop condition is explicit. Avoid unbounded loops inside loop() unless they are waiting for a clearly timed hardware event; otherwise they can starve serial output, watchdog service, sampling, or communication retries.

Arrays and strings need the same discipline. Arrays are useful for fixed sensor windows, lookup tables, calibration points, or pin lists, but the index must stay inside the declared length. Character arrays and Arduino String objects can hold labels or serial messages, yet repeated dynamic string growth can fragment memory on small boards. For a first prototype, prefer fixed buffers or short, bounded strings when the sketch will run for a long time, and record any random-number or math-library use so reviewers can repeat the same test conditions.

2.12 GPIO: Output, Input, And Pull-Ups

GPIO pins are general-purpose digital pins. They can drive outputs, read inputs, or connect to special peripheral functions such as PWM, ADC, UART, I2C, and SPI. The same physical pin may not support every function, so always check the board pinout.

Inspect Microcontroller and INPUTPULLUP in Figure 2.3 for gpio: output, input, and pull-ups. For the evidence behind gpio: output, input, and pull-ups, put Microcontroller and INPUTPULLUP into the same reading of it. The route closes at evidence log.

Read Microcontroller with INPUTPULLUP in Figure 2.3 for gpio: output, input, and pull-ups. Follow it from Microcontroller through INPUTPULLUP to evidence log. Skipping INPUTPULLUP would leave evidence log unsupported. This supplies gpio: output, input, and pull-ups with a concrete retest point.

const int LED_PIN = 2;  // Example GPIO; verify for your board.

void setup() {
    pinMode(LED_PIN, OUTPUT);
}

void loop() {
    digitalWrite(LED_PIN, HIGH);
    delay(250);
    digitalWrite(LED_PIN, LOW);
    delay(250);
}

const int BUTTON_PIN = 4;
const int LED_PIN = 2;

void setup() {
    pinMode(BUTTON_PIN, INPUT_PULLUP);
    pinMode(LED_PIN, OUTPUT);
}

void loop() {
    bool pressed = digitalRead(BUTTON_PIN) == LOW;
    digitalWrite(LED_PIN, pressed ? HIGH : LOW);
}

2.13 Continue to Part 2

Continue with Microcontroller Programming: Timing and Reliability.