Prototyping · Study deck

Firmware Architecture Patterns

Picture a greenhouse prototype where one loop reads temperature, starts a fan, sends a status update, and retries every failure.

Voltage Vera is your guide for this deck.

After studying this chapter

Learning objectives

You will be able to:

Choose an architecture pattern from evidence needs rather than implementation habit.
Separate driver, application state, communication, storage, update, and observability responsibilities.
Compare super loop, state machine, event queue, and RTOS task models as prototype evidence tools.
Review timing, blocking, fault recovery, and shared-state risks before a demo becomes an architecture.

Major section

In 60 Seconds · Start With the Story

It works on the bench until the network stalls.

For each one, name its input, output, time limit, saved state, and failure owner.
Delay communication, return a bad sensor value, fill stored work, restart the device, and hold the fan output.
This sketch does not select a final operating system or prove production scale.

Major section

Architecture Sets Trust Lines · Separate Three Hard Problems

Firmware architecture is not only code organization.

It decides which behavior can be measured, repeated, and trusted when the prototype leaves the bench.
An event queue carries changes into the state machine, which decides when the fan relay should switch.
The fault path records missing readings and recovery behavior with an identified owner.

Firmware architecture should route the greenhouse ventilation prototype question through explicit driver, state, gateway, storage, update, and diagnostic boundaries before pattern choice, run evidence, review decision, and handoff.

Major section

Prototype Architecture Ages Fast

Production firmware must survive missing packets, long sleep periods, full queues, corrupted settings, partial updates, and restarts without a developer watching the serial monitor.

The architecture should therefore make hidden coupling visible.
A TLS handshake may block long enough for a display to show stale values.
A queue may drop events faster than the review log records them.

Major section

Prototype Architecture Ages Fast (continued)

A flash erase may pause a low-cost MCU while an alarm transition is due.

An interrupt may update a shared flag while the main loop is formatting a payload.
The architecture is trustworthy only when those behaviors have an owner and an observation point.
Embedded operating-system boundaries are part of that evidence.

Major section

Prototype Architecture Ages Fast (continued)

Early firmware often works because the device is observed, reset manually, and tested on one network.

On a phone, laptop, or Linux gateway, the kernel usually protects itself from ordinary application code and mediates hardware access through drivers and services.
Interrupt handling is the sharpest version of that boundary.
Event-driven and threaded designs expose different costs.

Major section

Prototype Architecture Ages Fast (continued)

On a Linux gateway, include service restart behavior, systemd unit state, persistent queue size, and what happens when DNS or the broker is unavailable.

Many MCU firmwares are flatter: application code, driver code, and runtime code may share one address space, and a bad pointer or runaway callback can stop the whole device.
Cortex-M memory-protection units help when the runtime actually configures them, but the prototype record should not assume that protection exists.
If configuration migration, OTA download, bootloader confirmation, and rollback policy are hidden inside unrelated application code, a partial update can leave the prototype in an unclear state.

Major section

Architecture Choice Is Evidence Choice · Avoid Pattern Prestige

A useful prototype chooses the simplest architecture that can expose the deciding risk and records when that choice must be revisited.

The language chapter decided which runtime carries each software risk.
Architecture decides how responsibilities are separated inside that runtime.
An RTOS is not automatically better than a small state machine.

Major section

Responsibility Boundaries

Architecture starts by naming ownership.

If every function reads hardware, changes state, formats payloads, and publishes messages, the prototype may work once but will be hard to review.
It uses full stack for the work that connects both sides.
App state, message rules, local storage, and updates each have their own edge.
It should not decide business rules.

Firmware architecture separates hardware, state, communication, storage, and update ownership while observability crosses every boundary.

Major section

Responsibility Boundaries (continued)

The durable lesson is the boundary, not an assumed label: write interface/interaction, application logic/data, and cross-boundary contract in the architecture record so every contributor agrees which side owns each decision.

Stale data, retry delay, queued data, moves, and rollback cannot sit between modules.
It should not hide hardware errors.
It should expose failed publish attempts.

Major section

Boundary Review Minimum · Pattern Selection Map

Architecture patterns are not levels to climb.

A super loop can expose one read-decide-publish-sleep sequence if blocking points are bounded.
A state machine makes allowed, stale, and recovery transitions visible.
A host harness can stress event and fault sequences before each run reaches hardware.

Software architecture pattern evidence map

Major section

Timing and Shared-State Review

The prototype should show which work can block, which work must be quick, and which data can be shared safely.

The main loop takes that input, lets the state machine decide, and only then reaches the gateway publish path.
Queue depth, drop policy, and loop duration also need records before a timing claim is made.
The greenhouse trace in the Timing and shared-state review diagram separates a quick door interrupt from slower publish work.
The queue owns input facts and the state machine owns decisions, so a network wait cannot quietly become the rule for urgent state changes.

Major section

Timing and Shared-State Review (continued)

Blocking path: Network, storage, bus, and update calls must not freeze state review or hide stale output.

Interrupt handoff: Interrupts and callbacks should capture minimal facts and hand work to a loop, queue, or task.
Queue pressure: Events can arrive faster than they are handled.
Priority inversion: In task models, a low-priority owner can block urgent work.

Major section

Greenhouse Ventilation Controller · Architecture Review Record

A team is prototyping firmware for a greenhouse ventilation controller.

The device reads temperature, humidity, and door state, drives a fan relay, reports status to a gateway, and must recover safely if a sensor or gateway is unavailable.
The team records where blocking can occur and keeps the loop intentionally small.
Each transition has a reason, timeout expectation, and recovery rule.
The team now has evidence for behavior, not just a sequence of function calls.

Deck summary

Key takeaways

It works on the bench until the network stalls.

Firmware architecture is not only code organization.
Production firmware must survive missing packets, long sleep periods, full queues, corrupted settings, partial updates, and restarts without a developer watching the serial monitor.
A flash erase may pause a low-cost MCU while an alarm transition is due.
Early firmware often works because the device is observed, reset manually, and tested on one network.

Retrieval practice

Recall check 1 of 4

Voltage Vera says: answer from memory, then check your reasoning.

Q1Per this chapter's cold-room sensor example, what should trigger moving communication out of the simple loop and into a state transition, queue, or task?

AMQTT presence alone, even without measured fan-safety delay or backoff effects

BLarge I2C sensor count alone, without measured timing or safety interference

CMeasured publish backoff delaying fan safety logic during the instrumented loop

DChoose state machines because the team's preferred architecture also satisfies the safety-loop timing requirement.

Show answer

Answer: C The chapter's instrumentation guidance is measure first, restructure only if evidence demands it: 'If the loop still responds within the required window, keep it simple.

Retrieval practice

Recall check 2 of 4

Voltage Vera says: answer from memory, then check your reasoning.

Q2Per this chapter's 'Prototype Architecture Ages Fast' section, what does most hidden coupling in prototype firmware come from?

ACoupling through state, time, or fault ownership alone.

BCoupling through driver, communication, or storage boundaries.

CCoupling through interrupt priority, queues, and stack size.

DCoupling through time, memory, or ownership assumptions.

Show answer

Answer: D see answers page

Retrieval practice

Recall check 3 of 4

Voltage Vera says: answer from memory, then check your reasoning.

Q3Per this chapter's responsibility boundaries, which boundary owns hardware reads and actuator writes but should not decide business rules?

AApplication state boundary for product decision rules.

BCommunication boundary for exchanging device messages.

CStorage boundary for persisting recorded device state.

DDriver boundary for hardware reads and actuator writes.

Show answer

Answer: D The chapter's responsibility-boundary list assigns hardware reads, actuator writes, and bus transactions to the driver boundary specifically, and says it should not decide business rules -- that job belongs to application state.

Retrieval practice

Recall check 4 of 4

Voltage Vera says: answer from memory, then check your reasoning.

Q4A prototype reads sensors, publishes to a gateway, and updates a display in one loop. The demo works, but gateway publish sometimes blocks and the display shows stale values. What architecture review action is most useful?

AKeep the single loop unchanged, because one successful demo proves publish timing, display freshness, and architecture ownership.

BMove every sensor read, publish call, and display update into interrupt handlers so each action starts immediately.

CMap the blocking publish path, separate state ownership, and add a state, event, or task boundary where it exposes stale data.

DLeave stale display behavior for a later test phase, because architecture prototypes only need one clean demo.

Show answer

Answer: C Architecture evidence should reveal responsibility ownership, blocking paths, state transitions, and fault recovery.

Print reference

Answers 1 of 2

Answer key.

C · The chapter's instrumentation guidance is measure first, restructure only if evidence demands it: 'If the loop still responds within the required window, keep it simple.
D · The chapter names time, memory, and ownership as the three sources of hidden coupling, then illustrates each with an example: a blocking TLS handshake (time), a flash erase pausing an alarm transition (memory/timing), and an interrupt updating a shared flag mid-format (ownership).

Print reference

Answers 2 of 2

Answer key.

D · The chapter's responsibility-boundary list assigns hardware reads, actuator writes, and bus transactions to the driver boundary specifically, and says it should not decide business rules -- that job belongs to application state.
C · Architecture evidence should reveal responsibility ownership, blocking paths, state transitions, and fault recovery.