Embedded systems and their design constraints

Most computers are not on desks or in data centers. They are inside things: thermostats, washing machines, insulin pumps, car brakes, traffic signals, smart meters, drones and the roadside sensor at the end of your street. An embedded system is a computer built into a larger product to perform a dedicated function, usually without a keyboard or screen, often without anyone noticing it is there. Tens of billions of microcontrollers ship every year, far more than the processors in laptops and servers combined. The engineers who design them work at the boundary between hardware and software, and this course is about that boundary: how a microcontroller is built, how firmware drives its peripherals, how signals enter and leave it, how it talks to other devices, how it saves energy, and how its firmware is structured, tested and protected.

The course follows Northway Sensing, a small company in Ann Arbor, Michigan, that builds solar-powered roadside traffic counters. Jonah Abara, a junior on a co-op term who has already worked on the NS-4 counter's data structures, its circuit board and its processor choice, moves to the firmware team for a term under Maren Holt, the firmware lead. Ines Carvalho, PE, the hardware lead, shares the bench with them. Their job this term is to rework the NS-4 firmware, which has grown messy over five years of field updates, and to bring up the first prototype board of the NS-5, the next-generation node.

Students arrive at this course from different directions. Some have taken CMP-229 or CMPUT-229 and know assembly language and the memory hierarchy; others come from electrical engineering with circuit analysis and digital logic behind them. The course assumes C programming, binary and hexadecimal arithmetic, basic circuits (Ohm's law, dividers, RC time constants) and the idea of a processor fetching instructions from memory. Where a lesson leans on a specific earlier course, such as CMP-240 for circuits or CMP-310 for processor design, it says so.

What makes a system embedded

There is no sharp line between an embedded computer and a general-purpose one, but embedded systems share several traits. They are dedicated: the firmware does one job, or a fixed set of jobs, and the user cannot install new programs. They are reactive: they respond to events in the physical world, such as a vehicle passing, a button press or a temperature crossing a threshold, rather than to a user's requests. Many are real-time: a correct answer delivered too late is wrong, whether the deadline is a millisecond for a motor controller or a second for a thermostat. They are resource-constrained: memory is measured in kilobytes, clock rates in tens of megahertz, and power in milliwatts or microwatts. And they are long-lived: an industrial controller or a roadside counter may run unattended for ten or fifteen years.

A microcontroller, or MCU, packages a processor core with flash memory for the program, SRAM for data, and a collection of peripherals on one chip: timers, analog-to-digital converters, serial interfaces, general-purpose input and output pins, and often a real-time clock, a watchdog and a direct memory access engine. A microprocessor, by contrast, is a processor core that relies on external memory chips and usually runs a full operating system. Larger embedded products, such as a car's infotainment unit or a network router, use system-on-chip microprocessors running embedded Linux; smaller ones, such as the NS-4, use microcontrollers running bare-metal firmware or a small real-time operating system. This course concentrates on microcontrollers, because they are where hardware and software meet most directly.

The NS-4 node as an embedded system

The NS-4 is typical of a modern sensing node. A 32-bit microcontroller running at 48 MHz, with 256 KB of flash and 64 KB of SRAM, sits at the center. A 5 V radar module watches one lane and reports vehicle detections over an SPI link. A temperature sensor and a small ferroelectric memory share an I²C bus. A cellular modem connects through a UART, and an RS-485 link runs 40 m down the pole to a roadside cabinet where technicians plug in a laptop. A 12.8 V, 24 Ah lithium iron phosphate battery is charged by a solar panel, and a buck regulator supplies 3.3 V to the logic. A status LED, a tamper switch on the enclosure door and a heater relay complete the list of things the firmware must manage.

Each block on that diagram is a lesson. The radar and the memory are serial buses (lessons 8 to 10). The battery voltage is an analog input (lesson 5). The tamper switch and LED are digital input and output (lesson 4). Vehicle timestamps come from timers (lesson 6) and arrive through interrupts (lesson 7). The node spends most of its life asleep, which is lesson 11, and the firmware that ties everything together, survives faults and accepts secure updates is lesson 12.

Requirements and constraints

Embedded design starts from requirements, and the requirements are usually framed as constraints that every design choice must satisfy at once. Functional requirements say what the system must do: count and classify vehicles, timestamp each one to the nearest millisecond, upload hourly totals, accept configuration changes from a technician. Non-functional requirements say how well: the deadlines, the power budget, the cost, the size, the operating temperature range, the expected lifetime, the safety and security obligations. The skill of embedded engineering is trading these against each other, because improving one usually worsens another.

See how a single requirement fans out. The five-day reserve without sun sets the average current the whole node may draw, which limits how long the processor may stay awake, which limits how much computation can happen per vehicle, which pushes work into peripherals that run while the core sleeps. The temperature range rules out some crystals and capacitors and forces the heater, whose relay draws current the energy budget must cover. Embedded design is a web of such dependencies, and good engineers write them down early.

Real-time behavior

A real-time system must produce correct results within stated time limits. A hard real-time deadline is one where a late answer is a failure: an airbag that fires a second late, a motor commutation that comes too late and stalls the motor. A soft real-time deadline is one where lateness degrades quality but is tolerable: a dropped frame of video, a display that updates slowly. Many systems mix both. For the NS-4, timestamping a detection within 1 ms is firm: an occasional late timestamp corrupts speed estimates but does not endanger anyone. The real-time question is not raw speed but predictability. A processor that usually responds in 5 µs but occasionally takes 50 ms is worse, for real-time work, than one that always responds in 100 µs.

Predictability is why embedded engineers worry about worst cases. The worst-case execution time of a routine, the longest interrupt latency, the longest a task can be blocked by a lower-priority task: these, not averages, decide whether deadlines are met. Caches, dynamic memory allocation, garbage collection and complex operating systems all make worst cases harder to bound, which is one reason small microcontrollers often have no data cache and firmware often avoids heap allocation after start-up.

Energy as a first-class constraint

For battery and solar devices, energy is often the hardest constraint. Power is the rate of energy use; for the NS-4, the battery holds roughly 24 Ah at 12.8 V, about 307 Wh, and the node must survive five dark days. The firmware engineer's lever is the duty cycle: the fraction of time each part of the system is active. A microcontroller that draws 10 mA when running and 5 µA when asleep averages only about 0.5 mA if it runs 5 percent of the time. Lesson 11 develops this into a full battery-life model; here it is enough to see that energy, not processing speed, sets most of the NS-4's limits.

Hardware and software co-design

In a desktop computer, hardware and software are designed by different companies years apart. In an embedded product, one team often decides both at once, and the boundary between them is a design choice. Counting pulses can be done in software by polling a pin, in software by interrupts, or in hardware by a timer peripheral that counts edges while the core sleeps. Filtering a signal can be done in firmware, in a dedicated digital filter block, or with an analog RC network before the ADC. Each choice moves cost, power, flexibility and risk between the circuit board and the code. Throughout this course, watch for these choices; they are where embedded engineers earn their pay.

Co-design also means the firmware engineer reads schematics and datasheets daily. A microcontroller's reference manual, often more than a thousand pages, describes every register of every peripheral. The board's schematic shows which pin connects to what, which resistor sets a pull-up, which capacitor filters an input. Jonah's first task, before writing any code, is to annotate the NS-4 schematic with the microcontroller pin functions and to list every peripheral the firmware uses. The program below does a small version of that inventory and checks it against a requirement.

# NS-4 peripheral inventory and a simple pin-budget check
pins_available = 48          # package pins usable as I/O on the NS-4 microcontroller
uses = {
    "radar SPI (clock, data in, data out, select)": 4,
    "I2C bus (clock, data)": 2,
    "modem UART (transmit, receive, two flow-control lines)": 4,
    "RS-485 UART (transmit, receive, driver enable)": 3,
    "battery voltage ADC input": 1,
    "solar current ADC input": 1,
    "tamper switch input": 1,
    "status LED output": 1,
    "heater relay output": 1,
    "radar power switch output": 1,
    "modem power and reset": 2,
    "debug port (two-wire)": 2,
    "32.768 kHz crystal": 2,
    "main crystal": 2,
}
used = sum(uses.values())
for name, n in uses.items():
    print(f"{n:2d}  {name}")
print(f"used {used} of {pins_available} pins, spare {pins_available - used}")
print("spare fraction", round((pins_available - used) / pins_available, 2))

 4  radar SPI (clock, data in, data out, select)
 2  I2C bus (clock, data)
 4  modem UART (transmit, receive, two flow-control lines)
 3  RS-485 UART (transmit, receive, driver enable)
 1  battery voltage ADC input
 1  solar current ADC input
 1  tamper switch input
 1  status LED output
 1  heater relay output
 1  radar power switch output
 2  modem power and reset
 2  debug port (two-wire)
 2  32.768 kHz crystal
 2  main crystal
used 27 of 48 pins, spare 21
spare fraction 0.44

Twenty-seven of 48 pins are used, leaving 21 spare, a comfortable 44 percent. Ines likes at least a quarter of the pins spare on a new design, because every product grows features, and a board respin to free a pin costs weeks.

Safety, security and lifetime

Embedded systems act on the physical world, so their failures can hurt people, damage equipment or mislead those who rely on their data. Safety-critical domains, such as medical devices, automotive, aviation, rail and industrial machinery, have standards that require hazard analysis, defined development processes and evidence that the firmware behaves correctly. Even products outside those domains need defensive design: watchdogs that reset a hung processor, brown-out detection that holds the processor in reset when the supply sags, and firmware that checks its inputs. Security matters too, because a connected device that accepts unauthenticated commands or unsigned firmware can be hijacked. Lesson 12 returns to these topics.

Lifetime adds its own demands. Flash memory endures a limited number of erase cycles, so firmware that logs data must spread writes. Components drift with age and temperature. Remote firmware updates, essential for fixing bugs in the field, must never leave a device unable to boot, even if power fails halfway through. A device installed in 2026 may need to run until 2036, and its firmware must be maintainable by engineers who were not on the original team. That last requirement is the reason Maren wants the NS-4 firmware cleaned up this term.