Firmware vs hardware vs software roles

Key takeaways

When someone says "we need to update the device," do they mean a hardware change, a firmware update, or a software fix? These three terms are used constantly in IoT, but their boundaries are often blurred, especially for people from pure software or pure hardware backgrounds. This page clarifies the distinct roles of firmware, hardware, and software, where the boundaries lie, and why those boundaries matter for design, maintenance, and security.

What you'll learn

Hardware: the physical foundation

Hardware is everything you can physically touch: the printed circuit board (PCB), the microcontroller chip, the sensors, the cellular modem, the antenna, the battery, the connectors, and the enclosure. It is designed with electrical engineering tools, manufactured in factories, and critically cannot be changed after deployment without physically accessing the device. Key considerations include:

• Component selection sets the capabilities and constraints of the whole system. A MCU with too little RAM cannot run a complex firmware stack no matter how clever the code.
• PCB layout affects antenna performance, power efficiency, and electromagnetic compatibility; poor layout can cause interference between the modem and sensitive analog sensors.
• Environmental protection includes IP ratings, conformal coating, and ruggedized enclosures matter for outdoor or industrial deployments.
• Manufacturing design includes test points, programming headers, and QA procedures are built into the hardware for efficient assembly and testing at scale.

Hardware changes are expensive: a new PCB revision means re-design, re-manufacturing, and re-certification. That is why getting hardware right before mass production is critical. It is also why firmware and software provide flexibility on top of fixed hardware.

Firmware: the embedded intelligence

Firmware is the low-level software that runs directly on the microcontroller. It is stored in the MCU's flash memory, executes as soon as the device powers on, and sits between the hardware and higher-level application logic. It typically includes:

• Bootloader: The first code to run; it initializes hardware, verifies the main firmware image (secure boot), and loads the application. A good bootloader supports over-the-air (OTA) updates by managing two firmware slots so the device can safely roll back a failed update.
• Hardware Abstraction Layer (HAL): Functions that give higher-level code a consistent interface to peripherals (GPIO, SPI, I2C, UART, ADC, timers) without needing specific register addresses.
• Device drivers: Code that manages specific components: the cellular modem (AT commands, network connection), sensors (initializing, reading, calibrating), and power management ICs.
• RTOS or bare-metal scheduler: Manages task execution, timing, and resource sharing.
• Communication stack: Implements the cellular protocol stack, TLS/DTLS security, and application-layer protocols (MQTT, CoAP, HTTP).

Firmware is written in C or C++ (occasionally Rust), compiled for the specific MCU, and flashed during manufacturing. Unlike hardware, it can be updated after deployment through OTA updates, making it the primary way to fix bugs, add features, and patch security issues. Secure boot should verify the firmware signature before execution, and flash encryption should keep firmware unreadable even with physical access.

Application software: the business logic

In many simpler IoT devices, firmware and application software blur together where the application runs on the same MCU, compiled into the same binary. Conceptually, though, the application layer is distinct: it holds the business-specific logic that defines what the device actually does. It includes:

• Business logic: The rules for device behavior: when readings are taken, what thresholds trigger alerts, how data is aggregated before transmission.
• Data processing: Filtering, averaging, anomaly detection, and edge analytics performed before transmitting to the cloud.
• Cloud API client: Code that formats payloads, manages cloud connections, handles retries, and processes downlink commands.
• OTA update manager: Application-level logic that checks for updates, downloads new firmware images, validates them, and triggers the bootloader to apply them.
• Configuration management: Handling remotely changeable settings (reporting intervals, thresholds, network parameters) without a full firmware update.

In more capable devices running Linux on a microprocessor (MPU) rather than an RTOS on an MCU, the separation is clearer: firmware is effectively the operating system and kernel drivers, while application software runs as user-space processes.

Why the boundaries matter across the product lifecycle

• During development: Hardware, firmware, and application teams work in parallel and need clear interface contracts. The HAL defines the hardware/firmware boundary, and the API between firmware services and application logic defines the upper boundary.
• During deployment: Hardware is fixed, firmware can be updated via OTA, and application configuration can sometimes change via lightweight remote commands.
• During maintenance: An application-logic bug might be fixed with a configuration change, a device-driver bug needs a firmware update, and a hardware defect requires a physical recall or field replacement.
• For security: Each layer has its own attack surface. Hardware attacks (physical probing, side-channel analysis) are mitigated by features like a tamper-resistant element, firmware attacks (malicious code injection) by secure boot and code signing, and application attacks (man-in-the-middle, unauthorized access) by TLS, certificate pinning, and mutual authentication.

Lesson 3.4 Self-assessment

Frequently asked questions