When to activate
- Designing firmware architecture for a new embedded product
- Creating hardware abstraction layers (HAL)
- Structuring driver and application layers
- Porting firmware across microcontroller families
- Planning memory layout and linker scripts
When NOT to use
- For application-level software architecture
- For hardware PCB design
- For cloud backend architecture
Instructions
- Define layers. Hardware → HAL → Driver → Service → Application. Each layer only calls the layer below.
- HAL design. Abstract MCU-specific registers behind portable interfaces.
hal_gpio_set(pin, value) not GPIOB->BSRR = ....
- Driver pattern. Init → Configure → Read/Write → Deinit. Non-blocking with callbacks or DMA where possible.
- Memory layout. Flash: bootloader + app + OTA slot + config. RAM: stack, heap, static, DMA buffers. Use linker script explicitly.
- Build system. CMake for cross-compilation. Separate HAL per target (STM32, ESP32, nRF52). Common application code.
- Error handling. Return codes (not exceptions). Assert in debug, graceful degrade in release. Watchdog for hard faults.
- Documentation. Pin assignments, peripheral mapping, memory map, interrupt priority table.
Example
Firmware Architecture: Environmental Sensor Node
Layers:
Application: DataLogger, AlertManager, ConfigManager
Service: SensorService, NetworkService, StorageService
Driver: BME280, nRF24L01, SPIFlash, UART
HAL: GPIO, SPI, I2C, UART, Timer, ADC (MCU-specific)
Hardware: STM32L4 + BME280 + nRF24L01
Memory Map:
0x08000000: Bootloader (16KB)
0x08004000: Application (240KB)
0x08040000: OTA Slot (240KB)
0x0807C000: Config/NVS (16KB)
1---2name: firmware-architecture3description: Design firmware architecture — HAL abstraction, driver layers, application logic, and cross-platform portability4---56## When to activate78- Designing firmware architecture for a new embedded product9- Creating hardware abstraction layers (HAL)10- Structuring driver and application layers11- Porting firmware across microcontroller families12- Planning memory layout and linker scripts1314## When NOT to use1516- For application-level software architecture17- For hardware PCB design18- For cloud backend architecture1920## Instructions21221. **Define layers.** Hardware → HAL → Driver → Service → Application. Each layer only calls the layer below.232. **HAL design.** Abstract MCU-specific registers behind portable interfaces. `hal_gpio_set(pin, value)` not `GPIOB->BSRR = ...`.243. **Driver pattern.** Init → Configure → Read/Write → Deinit. Non-blocking with callbacks or DMA where possible.254. **Memory layout.** Flash: bootloader + app + OTA slot + config. RAM: stack, heap, static, DMA buffers. Use linker script explicitly.265. **Build system.** CMake for cross-compilation. Separate HAL per target (STM32, ESP32, nRF52). Common application code.276. **Error handling.** Return codes (not exceptions). Assert in debug, graceful degrade in release. Watchdog for hard faults.287. **Documentation.** Pin assignments, peripheral mapping, memory map, interrupt priority table.2930## Example3132```33Firmware Architecture: Environmental Sensor Node3435Layers:36 Application: DataLogger, AlertManager, ConfigManager37 Service: SensorService, NetworkService, StorageService38 Driver: BME280, nRF24L01, SPIFlash, UART39 HAL: GPIO, SPI, I2C, UART, Timer, ADC (MCU-specific)40 Hardware: STM32L4 + BME280 + nRF24L014142Memory Map:43 0x08000000: Bootloader (16KB)44 0x08004000: Application (240KB)45 0x08040000: OTA Slot (240KB)46 0x0807C000: Config/NVS (16KB)47```
UitbreidenOS