Microcontroller firmware: what to define before development
Inputs, outputs, communications and connection failures: a practical starting point for a firmware specification.
Describe the device in actual use
Firmware is the program running on a device that connects electronics to the required behaviour. Naming a microcontroller alone is not a specification. Describe what the device reads, what it controls and where commands come from. In my Cronics project I develop firmware for the ESP32-C6 Smart Hub; other boards have their own requirements.
List inputs, outputs and constraints
- Inputs: sensor models, interface, sampling interval and behaviour when a sensor is missing.
- Outputs: what is switched or transmitted, the initial state after power-up and allowed command ranges.
- Electronics: schematic, pin assignment, power supply and board revision.
- Communication: local application, server or other interface, and how access is assigned.
Define behaviour when something fails
For a device receiving network commands, define what happens without Wi-Fi, without the server and after restarting. An “on” command is different from confirmation that the output is on. Specify feedback and handling of duplicate or stale commands.
Example acceptance check: during a network outage the device keeps its agreed state; after reconnecting it reports the actual status. Reconnection timing and acceptable behaviour depend on the device. This describes a test, not a measured prototype result.
Plan updates and acceptance tests
If OTA updates are needed, define version delivery, authenticity checks and recovery after a failed update. ESP-IDF for ESP32-C6 supports application rollback, but it must be configured and tested. Having an OTA function alone does not prove reliable recovery.
For an inquiry, prepare the schematic or board model, purpose, sensor list and expected scenarios. If code exists, describe the technology and project status. Repository access is arranged separately.
Microcontroller programming and firmware development