[{"_1":2,"_114":-5,"_115":-5},"loaderData",{"_3":4,"_89":-5,"_90":91},"root",{"_5":6,"_7":8,"_9":10,"_11":12,"_13":14,"_74":75,"_15":76,"_77":78},"cart",["P",6],"isLoggedIn",["P",8],"footer",["P",10],"footerCustomData",["P",12],"header",{"_15":16,"_34":35},"shop",{"_17":18,"_19":20,"_21":22,"_23":24,"_27":28},"id","gid://shopify/Shop/63092686899","name","SomnusLab","description","Optimal sleep. Powered by science.","primaryDomain",{"_25":26},"url","https://checkout.somnuslab.com","brand",{"_29":30},"logo",{"_31":32},"image",{"_25":33},"https://cdn.shopify.com/s/files/1/0630/9268/6899/files/logo-circle-b.png?v=1765437474","menu",{"_17":36,"_37":38},"gid://shopify/Menu/205641809971","items",[39,50,58,66],{"_17":40,"_41":-5,"_42":43,"_44":45,"_46":47,"_25":48,"_37":49},"gid://shopify/MenuItem/488273707059","resourceId","tags",[],"title","Home","type","FRONTPAGE","https://checkout.somnuslab.com/",[],{"_17":51,"_41":52,"_42":53,"_44":54,"_46":55,"_25":56,"_37":57},"gid://shopify/MenuItem/506275561523","gid://shopify/Product/7592254734387",[],"Sleep Pad","PRODUCT","https://checkout.somnuslab.com/products/somnus-lab-sleep-pad-us-version",[],{"_17":59,"_41":60,"_42":61,"_44":62,"_46":63,"_25":64,"_37":65},"gid://shopify/MenuItem/512561184819","gid://shopify/Blog/88682463283",[],"Blog","BLOG","https://checkout.somnuslab.com/blogs/blog",[],{"_17":67,"_41":68,"_42":69,"_44":70,"_46":71,"_25":72,"_37":73},"gid://shopify/MenuItem/512561217587","gid://shopify/Page/130659811379",[],"About","PAGE","https://checkout.somnuslab.com/pages/about",[],"publicStoreDomain","5zthtm-rd.myshopify.com",["P",76],"consent",{"_79":80,"_81":82,"_83":84,"_85":86,"_87":88},"checkoutDomain","checkout.somnuslab.com","storefrontAccessToken","4f5d6b85a26f3cc97a3b611daa56b7e1","withPrivacyBanner",false,"country","US","language","EN","routes/($locale)","routes/($locale).blogs.$blogHandle.$articleHandle",{"_92":93},"article",{"_94":95,"_44":96,"_97":98,"_99":100,"_101":102,"_31":104,"_112":113},"handle","embedded-firmware-reimagined-bringing-modern-software-architecture-to-microcontrollers","Embedded Firmware, Reimagined: Bringing Modern Software Architecture to Microcontrollers","contentHtml","

This post is written for engineers who have built either embedded systems or modern software systems and have felt the friction when trying to apply the practices of one world to the other.

We briefly mentioned our choice of language - MicroPython on our firmware design. Today I’d like to share a bit more on how we structured our firmware and how MicroPython made it possible.

The limits of hardware-first firmware

Most embedded IoT firmware today is built around a hardware-first model: a C-based main loop tightly coupled to a specific MCU, board layout, and vendor SDK. This approach excels at bringing up hardware efficiently and delivering predictable performance, which is why it remains the industry default.

Coming from backgrounds where software systems are expected to evolve continuously—across features, deployments, and platforms—we found that some practices we had come to rely on were difficult to apply in this model. Clear separation between logic and implementation, repeatable automated testing, and the ability to refactor behavior with confidence are not inherent properties of hardware-centric firmware, and often require significant effort to retrofit.

Many of these ideas are technically possible in C-based firmware, but the cost—in boilerplate, tooling, and iteration speed—often makes them impractical for smaller start-ups.

How we architected our firmware

Rather than trying to incrementally patch the shortcomings of traditional embedded firmware, we took a step back and asked a simpler question: what would embedded firmware look like if we designed it using the same modern software engineering principles we’ve learned from building cloud, web, and application systems?

Our answer wasn’t a collection of fixes or tooling tweaks, but a different way of structuring firmware altogether. What emerged is an IoT firmware architecture centered around clear separation of concerns, deterministic behavior, and testability as a first-class goal. In practice, this shift has dramatically shortened our iteration cycle and made the system easier to reason about as it grows.

Below, we’ll outline the key ideas behind this architecture—not diving too deeply into implementation details yet, but enough to convey how the pieces fit together. At a high level, our firmware architecture is built around five core ideas:

A single explicit application State as the source of truth
Strict unidirectional data flow (inputs → state → hardware)
A controller that defines execution and timing
Pluggable UIs that express intent but never touch hardware
A Hardware Abstraction Layer that isolates all hardware interaction

The state and unidirectional dataflow

At the center of our architecture is the State. As the name suggests, State is a Python class that represents the complete state of the IoT application. At runtime, the system maintains a single instance of this class, which we simply call state.

Changes to physical hardware are performed during a dedicated synchronization phase called commit. In this phase, the current state is translated into concrete hardware operations—turning LEDs on or off, updating fan speeds, adjusting output powers, and so on. This synchronization step is the only place where physical hardware instructions are allowed to be sent.

It’s worth noting that reading from hardware sensors is not considered a hardware instruction in this model. Sensor readings do not mutate hardware state, and therefore do not violate unidirectional data flow. However, all sensor access still goes through the same abstraction boundaries described later, which allows readings to be mocked and simulated in tests.

Crucially, no other code in the application is allowed to interact with hardware directly. Business logic, control logic, and UI components can only modify the state and rely on this synchronization phase to apply those changes to the physical world. This enforces a strict unidirectional data flow: inputs update state, and state is deterministically reflected in hardware.

This idea is not novel. We borrowed it directly from modern JavaScript frameworks such as React. From our experience, having such a clear unidirectional data flow dramatically reduces system complexity. It encourages better separation of concerns, makes business logic easier to structure, and keeps hardware side effects explicit and predictable.

This approach also makes debugging far more practical. To reproduce a bug, we can initialize the system with a known state and observe how the system behaves—without relying on fragile timing, manual interaction, or specific hardware conditions.

Finally, by modeling the state as a plain Python class, we can take advantage of Python’s static type checking. Many classes of basic errors can be caught early, long before code is flashed onto a device.

UI as plug-ins

In our architecture, we treat user interfaces as first-class but interchangeable components. A UI is any boundary where intent enters the system—it doesn’t have to be a physical interface. Traditional buttons and displays are UIs, but so are network-based interfaces such as MQTT.

All UIs implement a shared interface by inheriting from a common BaseUI. This gives them a consistent lifecycle and behavior, regardless of how input is delivered. Once implemented, UIs can be plugged into the application without requiring changes to the core logic.

Just as importantly, UIs are intentionally constrained in what they are allowed to do. As described earlier, UI code is never permitted to interact with hardware directly. Instead, UIs can only observe the current state and express intent by mutating that state. The responsibility for translating state into hardware behavior is handled elsewhere.

This design makes adding new control mechanisms straightforward. A physical button, a mobile app, or an automation service publishing MQTT messages all integrate the same way: by updating state. None of them need special privileges or bespoke code paths.

By treating UIs as plug-ins rather than hard-coded features, we can evolve how the device is controlled without destabilizing the rest of the system.

An MVC-Inspired Architecture

At this point, some familiar patterns may start to emerge. Our firmware architecture draws inspiration from classic MVC frameworks such as Ruby on Rails—but with adaptations for the realities of embedded systems.

In our design, the State plays the role of the model: it represents the single-source-of-truth of the system at any given moment. UIs act as the view layer, translating external events into state changes.

Sitting between them is the controller, which serves as the central orchestrator of the application. The controller is responsible for wiring the system together and defining its execution model. Concretely, it:

Maintains a reference to the application state
Manages the set of active UIs
Holds references to the hardware abstraction layer (discussed in the next section)
Implements the commit step that synchronizes state to hardware
Drives the main application flow via a periodic tick, similar to the main loop in a traditional embedded system

Unlike many embedded designs where logic, hardware access, and control flow are interwoven throughout the codebase, our controller provides clearly defined places where each type of logic is expected to live. Periodic control logic is centralized in the tick() method, while all hardware side effects are explicitly confined to the commit step. By giving these responsibilities well-defined boundaries, the overall system becomes easier to reason about, test, and evolve.

The result is an architecture that feels familiar to developers coming from application or web backgrounds, while remaining explicit, deterministic, and well-suited to resource-constrained devices. But there are still a few more things we want to discuss.

$\"\"$

Figure: Overview of the state-driven firmware architecture

Hardware abstraction layer (HAL) and simulation mode

We’ve mentioned earlier that the commit() step—implemented by the controller—is the only place where application state is translated into physical hardware behavior. But that translation does not happen against raw hardware APIs directly. Between the controller and the hardware sits another layer: the Hardware Abstraction Layer (HAL). The HAL is responsible for both commanding hardware and reading sensor data, providing a consistent interface for all hardware interaction.

In theory, the controller could call device drivers or peripheral APIs directly during commit(). In practice, introducing a HAL provides several important benefits.

First, it allows the same firmware codebase to run across multiple hardware variants. When a component is swapped—for example, replacing an expensive chip with a more cost-effective alternative that exposes a slightly different interface—the differences are absorbed entirely within the HAL. From the perspective of the rest of the system, nothing changes. Business logic continues to operate against the same abstract capabilities, without knowing which specific hardware implementation is present.\n
- While hardware mutations are strictly confined to the commit() step, sensor reads are handled differently. Reading sensors has no side effects and can occur as part of control logic or state updates. Even so, these reads still go through the HAL, which allows them to be mocked, recorded, or simulated just like any other hardware interaction.
\n
Second, the HAL makes it possible to mock hardware. By substituting real hardware APIs with mocked ones, the application can run in a simulation mode. Combined with the unidirectional data flow described earlier, this dramatically accelerates development and debugging. Most business logic can be developed and tested on a simple development board—or even on a desktop machine running a local MicroPython build—without requiring access to the full hardware setup.
Third, not all hardware interfaces are idempotent. Repeating the same operation does not always result in the same physical outcome. The HAL provides a well-defined place to handle these quirks: caching state, normalizing behavior, or guarding against unintended side effects. This prevents such concerns from leaking into higher-level logic.

In practice, our HAL is intentionally thin for most components. But despite its simplicity, we’ve found it essential for portability, testability, and long-term maintainability as the system evolves.

Unit Tests, Acceptance Tests, and Beyond

With the architecture in place, we can now discuss how testing fits into our development process. A key realization early on was that the HAL boundary naturally defines how—and where—we test the system.

Testing Above the HAL

Everything above the HAL is, from a testing perspective, just software. This includes business logic, state transitions, control flow, UI behavior, and even sensor-driven logic when sensor inputs are mocked through the HAL.

For these layers, we rely on unit tests and acceptance tests written in Python. We intentionally avoid existing Python testing frameworks, as they are too heavy for MicroPython and unnecessary for our use case. Instead, we built a small, purpose-built test framework that provides just enough structure to express our tests clearly while remaining lightweight and fast.

One particularly important aspect of our acceptance tests is time control. Many embedded behaviors depend on time—timeouts, retries, stabilization periods, and long-running control loops. Rather than monkey-patching time.time() (which we found impractical in MicroPython), we introduced a thin abstraction around time and used it consistently throughout the application. This allows us to simulate the passage of time in tests, so scenarios that would normally take minutes or hours can be covered in seconds.

Combined with unidirectional data flow and a mockable HAL, this approach enables rapid, repeatable testing of complex behaviors without hardware in the loop.

Testing the HAL and Below

The HAL itself—and the hardware beneath it—is a different story. While software can be tested automatically and deterministically, hardware inevitably requires physical observation.

During development, we ensure that the HAL is exercised by dedicated test scripts that cover a range of expected and edge-case scenarios. Verifying the results, however, often involves manual bench work using tools such as multimeters and oscilloscopes. While slower than pure software testing, this process is focused and localized to a well-defined layer.

Later, when preparing for mass production, we went a step further and built dedicated test hardware that interfaces directly with exposed test points on the product. This allowed us to automate much of the hardware validation process—but that’s a story for another post.

Torture Testing

Every device we ship also goes through a torture test. Internally, this is implemented as a TortureTestUI—just another UI component that plugs into the controller when the device enters a special test mode.

The TortureTestUI systematically drives the system through a wide range of states, stresses actuators, and collects sensor data to verify correct behavior under sustained and extreme conditions. Because it operates through the same state-driven mechanisms as any other UI, it requires no special-case logic elsewhere in the system.

This reuse of existing abstractions allows us to build robust production tests without compromising the clarity or integrity of the core firmware.

Closing Thoughts

Overall, this architecture represents our attempt to apply familiar software engineering principles to the constraints of embedded firmware. By organizing the system around explicit state, unidirectional data flow, and clear boundaries between logic and hardware, we’ve found it easier to reason about behavior, test changes, and iterate as the product evolves.

MicroPython plays an important role in making this approach practical. Its expressiveness, dynamic nature, and compatibility with static type checking tools allow us to develop embedded IoT firmware while still benefiting from modern software engineering practices. While many of these ideas are not inherently tied to a specific language, MicroPython significantly lowers the cost of adopting them in day-to-day embedded development.

This framework is still a work in progress, shaped by practical needs rather than theory. We’re continuing to refine it internally, and we’re actively considering open-sourcing it once it stabilizes and the rough edges are addressed. Before that, there’s one remaining question to settle—arguably the hardest problem in software engineering: what should we call it? If you’ve made it this far and have a name suggestion, we’d love to hear it.

","publishedAt","2025-12-19T08:03:10Z","author",{"_19":103},"weiyan shao",{"_17":105,"_106":-5,"_25":107,"_108":109,"_110":111},"gid://shopify/ArticleImage/129153400883","altText","https://cdn.shopify.com/s/files/1/0630/9268/6899/articles/6dcf8f37-de65-4924-aa5c-9a8a0974a0df_1382x1166_c11c5a59-2289-4471-9406-16f3ca8d709c.webp?v=1766133172","width",1382,"height",1166,"seo",{"_21":-5,"_44":-5},"actionData","errors"]