5.2Device drivers & firmware

Embedded software is tightly coupled to hardware, but if application-layer code keeps directly tracking individual register bit positions, maintainability suffers. The device driver is the layer that mediates this, and the bootloader is the foundation that carries the system from the moment of power-on to a state where the application can run. Furthermore, in recent years OTA updates, which update shipped devices over a network, have become common, and designing so that a failed update does not "brick" the device has become a critical practical concern.

5.2.1Device drivers (register operations / interrupt integration)

• A device driver is a software layer that directly manipulates the registers of specific hardware (a sensor, a communication IC, a timer, etc.) and exposes that hardware's device-specific procedures (initialization sequence, data send/receive procedure, etc.) to the application layer as a uniform interface (function calls). This improves portability and maintainability, since the application layer's calling convention need not change even if the underlying hardware changes.
• Many drivers work in coordination with interrupts. For example, a communication-IC driver typically writes to a register to start transmission upon a send request, detects transmission completion via an interrupt handler (ISR), and has the ISR notify the layer above of completion. In driver design, whether to "wait for completion via polling" or "receive notification via an interrupt" is a trade-off between CPU utilization and real-time responsiveness.

5.2.2Bootloader

• A bootloader is a small program executed first immediately after power-on or reset. It performs minimal hardware initialization (clock, memory controller, etc.) and is responsible for verifying and launching the main application (firmware) on flash. The standard practice is to keep the bootloader itself rewritten infrequently and design it with robustness as the top priority.

Suppose an IoT device manufacturer is designing a mechanism to update firmware over-the-air (OTA) across tens of thousands of already-shipped devices. They first consider a simple design of "download the new firmware and overwrite it immediately," but judge this carries the fatal risk that a communication or power failure partway through the update could leave the device unable to boot (bricked). So instead, they split flash memory into a region for the current firmware (bank A) and a region for the new firmware (bank B), write the new firmware to bank B, verify its integrity via a checksum or digital signature after the write completes, and only then have the bootloader switch which bank it loads on the next boot—a dual-bank scheme. They further build in a failsafe mechanism whereby, if normal operation (e.g., successful sensor communication) cannot be confirmed within a set time immediately after booting into the new firmware, the bootloader automatically rolls back to the previous bank (bank A). With this design, bank A remains intact even if the update is interrupted by a communication failure, and if the new firmware has a defect the device automatically reverts to the previous version, preventing a remotely deployed device from becoming completely unresponsive due to a failed update. Rather than simply "overwriting with new code," the core judgment in OTA design is to anticipate failure at every stage of the update and build in verification, switching, and automatic recovery mechanisms.

5.2.3Section summary

• A device driver abstracts hardware-specific processing to improve portability/maintainability, and many coordinate with interrupts
• The bootloader handles minimal initialization right after power-on and application verification/launch, kept low-churn with robustness as the top priority
• OTA updates standardly use dual bank plus integrity verification plus automatic rollback to prevent bricking on a failed update