Embedded Firmware Implementation
8 weeks · 0 milestones
Implement firmware for a real or simulated embedded system, demonstrating correct hardware control and documented test coverage. The firmware must: control at least 2 distinct hardware peripherals (e.g. read a sensor over I2C and drive an actuator over PWM), handle at least one interrupt-driven event (timer, external interrupt, or serial receive) with documented rationale for the interrupt strategy, implement a defined state machine with at least 4 states and documented transition conditions, and include a documented unit test or hardware-in-the-loop test for each peripheral driver with pass/fail criteria. Code must be readable and documented — variable names, function names, and inline comments must enable a reviewer to follow the logic without running the code. Preferred proof: firmware running on physical hardware (Arduino, ESP32, STM32, or equivalent) with oscilloscope or serial monitor evidence of correct operation. Accessible alternative: firmware implementation and simulation in Wokwi (free, browser-based) with simulation waveform or serial output evidence of correct operation; GitHub public repository with commit history. Proof artifacts: the firmware source code with state machine implementation (design artifact) and the test results or simulation evidence (analysis artifact). Verification: an embedded firmware engineer reviews 'what happens if this interrupt fires while the state machine is in state X?' and 'how does this driver behave if the hardware does not respond to the I2C address?' — requiring you to reason about your own interrupt and error-handling logic.
Milestone map
Milestone map
3 milestones
Set up a working embedded development environment for a real microcontroller board or a free online simulator. Acceptable platforms: Arduino Uno/Nano/Mega (free Arduino IDE), Raspberry Pi Pico (free MicroPython or C SDK), STM32 Nucleo (free STM32CubeIDE), ESP32/ESP8266 (free Arduino IDE or ESP-IDF), or — with no hardware available — Wokwi (free browser-based simulator supporting Arduino, ESP32, and Raspberry Pi Pico). Implement a hardware abstraction layer (HAL) for at least two peripherals required by the firmware system you plan to build in M2: write driver functions for the peripheral (e.g. `led_init()`, `led_set(state)`, `uart_send(byte)`, `sensor_read_raw()`) that expose a clean interface hiding the register-level or library-level details. Confirm the HAL works by running a simple test for each peripheral (e.g. LED blinks at 1 Hz, UART sends a known byte sequence, sensor returns a value in the expected range).
Proof required
Submit: (1) a brief system overview (100–150 words) stating the target platform, the two peripherals your HAL covers, and the firmware system you plan to build in M2; (2) the HAL source code for both peripherals (in a public GitHub repository or Wokwi project link); (3) a short video or GIF (30–60 seconds) or Wokwi simulation link showing the HAL test running — each peripheral demonstrating its expected behaviour; (4) a confirmation that the development environment compiles and uploads without errors (screenshot of the IDE/terminal with a clean build output).
What gets checked
- HAL functions expose a clean interface with no hardware-specific constants or register names visible to the caller — a function called `sensor_read_raw()` that returns an integer is a valid HAL function; a function that requires the caller to pass a GPIO pin number and an ADC channel number is register-level code exposed to the caller, not a HAL
- Each peripheral has at least two HAL functions (init and at least one operation function) — a HAL with only one function per peripheral has not separated initialisation from operation
- The test proof shows the expected behaviour in real time — a static photo of the hardware is not sufficient; video, GIF, or Wokwi simulation link showing the peripheral operating is required