The challenge
The project involved the central controller of a building automation platform, where electronics, field protocols, local logic and remote services had to work as parts of the same product.
The challenge was keeping layers with very different constraints aligned: a real-time microcontroller, embedded Linux, edge services, protocols, deployment and production tools.
The product also needed repeatable ways to diagnose, update, program and verify it throughout its lifecycle.
As the sole embedded developer, I worked across this chain from STM32 firmware to production test tools, collaborating with the cloud backend, frontend, UX/UI and system integration teams.
From microcontroller to product
The microcontroller handled the functions closest to the hardware: data acquisition, GPIO, buses, non-volatile memory, watchdogs, diagnostics and system supervision.
Linux handled protocols, application services, persistence, APIs, real-time communication and integration with remote services.
I also worked on the embedded Linux platform, customising the operating system and integrating the product’s hardware interfaces and services.
The key was maintaining explicit interfaces between the layers, so that states, errors and diagnostic functions could also be reused during integration and production.
Three design decisions
Each function at the right level
The microcontroller handled functions requiring direct hardware access and predictable behaviour; Linux hosted those requiring more processing capacity and integration capabilities.
Decision: give the MCU and Linux edge distinct responsibilities, with a clear interface between them.
Diagnostics built into the architecture
The firmware exposed a diagnostic interface used by both the Linux software and automated test tools.
The same functions could identify the device, check peripherals and communications, read hardware measurements and exercise interfaces during development and production testing.
Decision: make diagnostics part of the product architecture from the start.
Design for testing
Production required more than flashing firmware: power supplies, buses, peripherals, firmware, the Linux host and physical functions all had to be exercised and verified together.
Testability and production test tools were therefore developed alongside the product.
Decision: treat production testing as part of the architecture and industrialisation process.
From product to production
I developed an automated production test platform coordinating fixtures, communication interfaces, test firmware, measurements, flashing and software.
Test sequences were defined as data, allowing checks, thresholds and workflows to change without rewriting the test engine.
Dedicated fixtures, with firmware developed for production testing, enabled automated checks of hardware and interfaces.
The process also integrated flashing, communication tests, computer vision for visual checks, reporting, serial number assignment and label printing.
The platform brought electrical, firmware and software checks together in a repeatable production test process managed by the same infrastructure.
Deployment and maintenance
Edge services were deployed as multi-architecture stacks, with automated builds and publishing.
I also developed provisioning, diagnostic and update tools that worked with both Linux and the microcontroller.
The aim was to avoid fragmented manual procedures and undocumented knowledge for configuration, updates and maintenance.
The outcome
The result is an embedded platform where firmware, Linux, edge software and production tools share interfaces and diagnostics designed throughout the same development cycle.
The product can be monitored across its layers, updated and configured with dedicated tools, and programmed and verified through a repeatable production test process.
Mechanisms introduced during development are reused during integration and production, reducing gaps between firmware, Linux, application software and manufacturing.
The value of the project lies in following the product across layers usually handled by separate specialists, from microcontroller behaviour through to programming and hardware verification in production.
Technologies
Firmware & real-time
C · STM32 · FreeRTOS · HAL / LL · ADC · GPIO · I²C · UART · USB CDC · CAN · Watchdog · Non-volatile memory
Protocols & interfaces
CAN · KNX · Modbus · RS-485 · UART · I²C · USB · Ethernet · REST · WebSocket / Socket.IO
Embedded Linux
Embedded Linux · Custom Linux platform · Hardware interface integration · systemd · Provisioning
Edge software
Node.js · TypeScript · NestJS · MongoDB · REST APIs · Real-time events · Device orchestration
Deployment & maintenance
Docker · Docker Compose · CI/CD · Containerized deployment · Multi-architecture builds · Update tooling
Production test
Python · Flask · PySerial · OpenCV · Configurable test sequences · Fixture firmware · Electrical measurements · Automated flashing · Reporting · Serialisation · Label printing
Integration & industrialisation
System architecture · HW/FW/SW integration · Design for Test · Diagnostics · Troubleshooting · Provisioning · Test automation · Production readiness