What is a board support package?
A BSP is the software layer that makes an operating system run on a specific board: platform initialisation, clock and pin configuration, memory map, device tree and the drivers for the peripherals actually fitted.
SYSTEM INTEGRATION
Embedded Software
Embedded software is where hardware becomes a product. Faststream covers bootloaders, board support packages, device drivers, RTOS and embedded Linux, middleware, connectivity stacks and the update mechanism — with the update mechanism designed first, because it cannot be retrofitted into a product that has already shipped.
SCOPE
The software stack.
- Bootloader — secure boot chain, update mechanism, partition layout and rollback, designed before the first prototype.
- Board support package — platform initialisation, clock and pin configuration, memory map and device tree.
- Device drivers — peripheral and sensor drivers, kernel modules and user-space interfaces.
- RTOS — task architecture, scheduling, synchronisation and interrupt design where determinism is required.
- Embedded Linux — kernel configuration, Yocto or Buildroot distributions, and a maintainable build.
- Middleware — protocol stacks, data models, local storage and application frameworks.
- Connectivity — cellular, Wi-Fi, BLE, LoRaWAN and NFC stacks with reconnection and failure handling that survives real networks.
- Power management — sleep states, wake sources and duty cycling, where the battery specification is actually met or missed.
DESIGN FIRST
Update, provisioning and diagnostics.
Three things determine the lifetime support cost of a connected product, and all three are architectural decisions made in the first weeks.
Update. Partition layout, bootloader design, signing and rollback have to exist before the first unit ships. Retrofitting a safe update path into a deployed fleet ranges from painful to impossible.
Provisioning. Identity and credentials applied in a factory flow that is auditable and does not depend on a technician doing it correctly every time.
Diagnostics. A device that reports its own health — connectivity quality, reset causes, battery state, firmware version — can be supported remotely. One that reports only its payload generates site visits.
RTOS OR LINUX
Choosing the software architecture.
| Consideration | RTOS | Embedded Linux |
|---|---|---|
| Determinism | Hard real-time achievable | Soft real-time; hard requires additional measures |
| Memory footprint | Kilobytes to low megabytes | Tens of megabytes upward |
| Boot time | Milliseconds | Seconds, reducible with effort |
| Power | Deep sleep with fast wake | Higher floor; suspend and resume are heavier |
| Connectivity and ecosystem | Stack per protocol, often vendor-supplied | Mature networking and a large package ecosystem |
| Update | Custom mechanism | Established A/B and image-based schemes |
| Typical fit | Sensors, controllers, battery devices | Gateways, vision nodes, connected appliances |
COMMON QUESTIONS
What engineers ask before they call.
Should we use an RTOS or embedded Linux?
Determinism, memory footprint, power budget and connectivity needs decide it. Battery-powered sensors and controllers with hard timing requirements suit an RTOS; gateways, vision nodes and anything needing a rich networking stack suit embedded Linux.
Why does over-the-air update need designing early?
Because it depends on partition layout, bootloader design, signing infrastructure and rollback capability, none of which can be added to a fleet that has already shipped without a physical intervention.
KEEP READING
Related work.
BUILD WITH FASTSTREAM
Bring us the difficult part.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.