Firmware Architecture

Firmware Architecture

A working blink is not an architecture. This subject is structuring firmware so timing and I/O stay predictable: super-loop vs. interrupts vs. an RTOS later, state machines for protocols and UI, and clear module boundaries (drivers vs. application). You document the structure so a teammate can change one part without breaking the rest.

Starting Points

• Embedded systems overview
• Operating systems & RTOS
• Samek, M. Practical UML Statecharts in C/C++ (state-machine chapters), or a short state-machine tutorial you cite.

Key Points

• You draw or describe the firmware structure (modules, data flow, who owns which peripheral).
• You implement at least one explicit state machine for a real behaviour (button, protocol, robot mode).
• You separate hardware access from application logic so the same logic can be tested or ported.
• You choose super-loop, interrupt-driven I/O, or an RTOS with a reason tied to timing requirements.
• You keep blocking delays off critical paths, or you document why a delay is acceptable.