Connected Machines, Embedded & IoT

A Kaern Schools course on the SPIRIT + ESP32 stack — connecting real cycleWASH machines from silicon to dashboard.

Tutor: Volt

Welcome to the course

Hi — I'm Volt, and I'll be your tutor for the next several weeks. I've spent fifteen years putting microcontrollers inside machines that have to survive the real world: pumps that run wet, motors that draw inrush current that would scare you, and control boards bolted twenty centimetres from a 400 V variable-frequency drive. This course is the distillation of that experience, taught against a stack we actually ship: SPIRIT, our cycleX carrier board, paired with the ESP32.

We're going to take a real machine — a cycleWASH bicycle washing system, the kind you find at a trailhead or a city OASIS station — and we're going to connect it. End to end. By the time you finish, you will have read a pressure sensor, commanded a motor over Modbus/RS485, streamed telemetry over MQTT, lit up a live dashboard, taken a payment, survived a power brown-out, and locked the whole thing down against an attacker. Not in theory. On hardware, on your bench.

Who this is for

• Makers and hobbyists who can blink an LED and want to build something that runs unattended for a year.
• Working engineers from a mechanical, electrical, or software background moving into connected products.
• Field technicians at companies like cycleWASH who maintain machines and want to understand the brains inside them.

You should be comfortable reading basic C/C++ and using a command line. You do not need a degree in electronics — I'll build the physics up as we go.

What you'll be able to do (course outcomes)

By the end you will be able to:

1. Select and configure a microcontroller for an industrial-adjacent product, reasoning about clocks, memory, GPIO, and peripherals.
2. Interface real-world sensors — analog, digital, and industrial bus (Modbus/RS485) — and trust the numbers you get back.
3. Write firmware that is event-driven, non-blocking, and recoverable, using an RTOS where appropriate.
4. Connect a device to the network and a cloud broker over Wi-Fi/BLE/MQTT, and update it in the field via OTA.
5. Build a telemetry pipeline and a live operations dashboard.
6. Design for power and reliability: brown-outs, watchdogs, condensation, and the difference between "works on my desk" and "works for a year."
7. Threat-model and harden a connected machine — secure boot, encrypted transport, credential hygiene, and payment integrity.

Your tools

| Tool | What it is | Why we use it | |---|---|---| | ESP32 | Dual-core MCU with Wi-Fi + BLE | Cheap, capable, huge community, native networking | | SPIRIT | cycleX carrier board (ESP32 socket, RS485 transceiver, isolated I/O, sensor headers, regulated 24 V→3.3 V supply) | The bridge between a 3.3 V brain and a 24 V/400 V machine | | ESP-IDF / Arduino-ESP32 | Firmware frameworks | IDF for production, Arduino for fast prototyping | | Modbus RTU over RS485 | Industrial bus | How the VFD, flow meter, and I/O modules actually talk | | MQTT broker (Mosquitto / cloud) | Pub/sub messaging | Telemetry transport | | Grafana + InfluxDB / Node-RED | Dashboards & flow logic | Where operators watch the fleet |

How each module is structured

Every module follows the same seven-beat rhythm so your brain knows where it is: Microcontroller basics → Reading the physical world → Firmware → Connectivity → Cloud & dashboards → Power & reliability → Security. Each module gives you learning objectives, lessons with a teaching script, a worked example on a cycleWASH machine, a hands-on exercise you flash to real hardware, the three mistakes everyone makes, and a check for understanding. We close with a capstone and a rubric.

Let's power up.

Module 1 — Microcontroller Basics

Learning objectives

• Explain what a microcontroller is and how it differs from a microprocessor/SBC like a Raspberry Pi.
• Read an ESP32 block diagram and identify CPU, RAM, flash, clocks, and peripherals.
• Map GPIO pins to functions and avoid the ESP32's "trap" pins (strapping, input-only, flash).
• Set up a toolchain and flash a first program to the ESP32 on the SPIRIT board.
• Reason about the boot sequence and what happens between power-on and app_main().

Lesson 1.1 — What is a microcontroller, really?

Teaching script. Let me start with a picture. Your laptop is a city — a fast CPU, gigabytes of RAM that vanish when the power drops, an operating system, a hard drive, screens, all coordinated by a busy government. A microcontroller is a self-sufficient cabin in the woods. It has its own small brain, its own little pantry of memory that survives the winter, and it talks directly to the physical world through pins — no operating system required, no monitor, no negotiation. The ESP32 is a remarkably well-stocked cabin: two CPU cores running at up to 240 MHz, around 520 kilobytes of SRAM, a few megabytes of flash to hold your program, and — crucially for us — Wi-Fi and Bluetooth radios built right in. Here's why that matters for a cycleWASH machine: when a customer taps "start," there's no time to boot Windows. The chip wakes, reads the coin sensor, opens a valve, and counts seconds, deterministically, every single time, for years. That determinism — the fact that it does the same thing in the same number of microseconds — is the whole point. A general-purpose computer is capable; a microcontroller is dependable. So before we touch code: when you imagine the brain of a washing machine, are you picturing a city, or a cabin?

Lesson 1.2 — Inside the ESP32: clocks, memory, and peripherals

Teaching script. Open the block diagram and let's not be intimidated by it. Find three things first. One: the CPU cores — there are two, and we call them PRO and APP. We'll later pin networking to one core and machine control to the other so a slow Wi-Fi reconnect never stalls a valve. Two: memory. There's SRAM, which is fast but forgetful — it's your workbench, cleared every reset. There's flash, which is slower but permanent — your filing cabinet, holding the firmware and any settings you want to survive a power cut. Three: peripherals — and this is where the ESP32 earns its keep. These are little hardware engines that do work without the CPU: timers, UARTs for serial buses, ADCs to read voltages, PWM generators to dim or drive things, I²C and SPI controllers. The art of embedded is laziness in the best sense: let the peripherals do the grunt work so the CPU can sleep or think. A beginner polls a pin in a tight loop and burns the whole chip doing nothing. An expert configures a peripheral and an interrupt and lets the silicon notify them. Which approach do you think survives a year in the field — and why?

Lesson 1.3 — Pins, GPIO, and the traps that bite beginners

Teaching script. Now the pins — the cabin's doors and windows onto the world. The ESP32 has lots of GPIO, "general-purpose input/output," and most can be configured as digital in, digital out, or routed to a peripheral like a UART or PWM channel. But here's the hard-won truth nobody prints on the box: not all pins are equal. Some are strapping pins — the chip reads them at the instant of boot to decide how to start, so if your circuit holds one high or low at the wrong moment, the chip won't boot at all. Some are input-only and can never drive an output. Some are wired to the internal flash and will brick your boot if you touch them. On the SPIRIT board I've pre-routed the safe pins to the screw terminals precisely so you don't learn this the painful way — but you will meet a raw ESP32 someday, and the datasheet pin table is the difference between a working board and a confusing afternoon. Treat the datasheet as the source of truth, never a forum post. So, quick instinct check: if a board boots fine on the bench but refuses to start once you wire up your sensor, where's the first place you'd look?

Worked example — Booting the cycleWASH controller

The cycleWASH Mini Platinum controller is a SPIRIT board in the machine's electrical cabinet. On power-up it must: (1) come out of reset, (2) run the second-stage bootloader from flash, (3) load the application, (4) initialise GPIO so the main contactor stays open (machine safe/off) until firmware explicitly commands it. We deliberately use a pin with a pull-down for the contactor enable, so that during the uncertain milliseconds of boot — before our code runs — the motor cannot energise. That's a microcontroller-basics decision (boot sequence + GPIO default states) that is also a safety decision. Hardware defaults are policy.

Hands-on exercise — First flash

1. Seat an ESP32 module on the SPIRIT board; connect USB.
2. Install ESP-IDF (or Arduino-ESP32). Confirm the serial port enumerates.
3. Flash hello_world, then modify it to print the chip model, core count, flash size, and reset reason (esp_reset_reason()).
4. Add: blink the SPIRIT status LED at 1 Hz using a hardware timer/PWM, not a delay() busy-loop.
5. Read it back over serial. Note the reset reason after pressing the board's reset button vs. after a power cycle.

Deliverable: serial log showing chip info + reset reason, and a non-blocking blink.

Common mistakes

1. Using a strapping/flash/input-only pin for I/O and then blaming the code when the board won't boot or won't drive a load.
2. Blocking with delay() everywhere — it works in hello_world and falls apart the moment two things must happen at once.
3. Assuming SRAM persists — storing a "machine state" in a plain variable and being surprised it resets to zero after a brown-out.

Check for understanding

1. Name one concrete reason a cycleWASH machine uses a microcontroller and not a Raspberry Pi running Linux.
2. What is a strapping pin, and what's the failure mode if you misuse one?
3. Why default the motor-enable GPIO to "off" in hardware rather than in firmware?