Skip to content

How react.o can improve firmware design

Felipe Lavratti edited this page Apr 20, 2017 · 2 revisions

react.o is a framework to the event-driven firmware (or reactive, or async firmware), and it provide a foundation with some impositions to the firmware design.

Follow the main characteristics of the design imposed and recommended:

1. Concurrency gets solved

That's the main goal of the reactive paradigm in a firmware, to eliminate concurrency between functionalities, and yet, keep a sort of parallelism and availability. But race conditions may still happen on interrupt routines, so the recommended design is to build interrupt routines that process the hard real time features and then create events and push into react.o's queues to be later processed, concurrency free. So, ideally, every ISR will push events into queues. react.o's queues are single consumer and single producer FIFOs to solve the concurrency.

2. It will increase modularity

The reactive paradigm inhibit a lot of the entanglement due to the fact the code is organized in callbacks, turning more natural to explode firmware functionalities in many small SRP functions.

The best architectural model suggested is to build every system part as a generic (maybe reusable) and SRP module without business logic, that will provide an API that will be used by the business modules. In instance, a UART should only do buffering and debuffering or User interface input module should only process GPIOs and generate events, while a control module that will do event processing and carry business logic.

This is actually a generally good advice for firmware architecture.

3. More testability

Since the code is modularized, it gets easier to test. You can also run react.o machine into a test harness to test integration between callbacks and the event flow.

4. Legibility gets a penalty

Since you will have a possible linear code broken into callbacks it may get harder to read it, compared to a single linear function with all in it. Also, the framework will impose its own syntax that is different from a RTOS or other frameworks, and the reactive paradigm itself is verbose when done in C.