Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming an Embedded/IoT Engineer

An embedded/IoT engineer develops software for devices with hardware constraints, from microcontrollers to connected IoT products, which is a perfectly reasonable specialism until you remember that the device has 64KB of RAM and strong opinions, the watchdog timer restarts the board just as you were about to find out why, the field firmware update must be reliable over a link that is not, and the fleet of devices all decide to phone home at once. You learn to translate "make it small" into C, Rust, peripherals, interrupts, buses, protocols, and a binary that must fit in flash, boot in time, and behave on a chip whose datasheet is longer than the deadline. An embedded system is not a computer; it is a microcontroller with opinions, a real-time loop with deadlines measured in microseconds, and a fleet of physical objects in the world that will, sooner or later, all need updating at once over a network whose mood is weather. This guide travels from blinking one LED to operating a fleet of connected devices, with practical stops at programming, microcontrollers, RTOS, hardware interfaces, debugging, connectivity, security, updates, and the recurring discovery that a device marked "online" is merely online to bill its radio. The grand objective is firmware that runs for years on a battery the customer cannot replace; the daily evidence is usually a current draw that names its cause, a debug probe that connects on the third attempt, and an OTA rollout that, when it fails, fails on a device someone has since installed in a ceiling three time zones away.

Things to recognise

• A peripheral marked "enabled" in the register is enabled to run and to draw current; it is not volunteering information about the clock gate, the pin mux, or the erratum that contradicts the datasheet on page two hundred and forty.
• Datasheets list headline behaviour, while the actual chip includes errata, undocumented registers, and silicon revisions that change the behaviour whether or not anyone is using them to do anything the manual promised.
• Confirm the board, the silicon revision, the toolchain, and the debug probe before flashing, because a correct binary on the wrong revision remains impressively broken and surprisingly persistent.

Take the useful exit

Level 1 · Novice

Read the datasheet before asking the chip to deploy civilisation

You inspect a development board, read the datasheet, build a sample firmware, and blink an LED, learning how a perfectly polite peripheral can introduce a small fortune of register confusion before you finish reading its manual.

You begin with read-only artifacts: a datasheet's register map, a reference manual, a development board's schematic, a sample firmware build, and a debug probe expressing recent opinions. A microcontroller is a single chip containing a CPU, memory, and peripherals; a peripheral is a hardware block the CPU configures to do a job it would rather not do itself; a register is a memory location the CPU writes to control that block. You review these with hardware engineers, testers, and an experienced firmware developer so everyone can trace how input, peripheral, and output connect before anyone flashes a binary whose confirmation is also a board brought to life with strong opinions.

Suppose a team wants to blink an LED "on the chip." On a development board with no field deployment, you read the GPIO register description, inspect the sample firmware, configure the pin as an output, toggle the bit, and note that the LED either stays on or stays off, because the clock gate is a register nobody documented. You record the clock tree, the pin mux, and the single line item that exceeds all others in making the LED blink. One brisk firmware is an anecdote with good posture, not a product; but it prevents the team from commissioning a sensor driver for a blink that runs four milliseconds a minute on the target battery.

Words from the spaceship manual, translated

Microcontroller: A single chip containing a CPU, memory, and peripherals, offered as a unit for embedded workloads. Peripherals on different chips can talk to each other, for a bus cycle, and at a speed that suggests they are on speaking terms rather than close friends.
Peripheral: A hardware block the CPU configures to handle a job — GPIO, timer, ADC, UART — priced in silicon and configured through registers. The chip handles the hardware; you handle the consequences of having asked a register to mean what you meant.
Register: A memory-mapped location the CPU reads or writes to control a peripheral, and the small print that decides whether "set bit 3" means set bit 3 or set bit 3 and quietly disable the whole port.
Datasheet: The manufacturer's reference for the chip's behaviour, usually welcoming on the first page and commemorative in its errata, which is where the truth tends to be filed.