I enjoy the “event sourcing” paradigm that is widely used in JS/TS (react/redux) and microservice (CQRS) domains. I am wondering if there is an analogous paradigm, (perhaps different name or terminology) used in embedded C/C++ programming? In both domains, there are parts of the system that create events, and other parts that need to triggered or react to those events. I know some systematic approaches for architecting the program for this in JS/TS but not in C.
In my case, I am developing a mesh network where each node has buttons and an LED output device, and also communicates with other devices wirelessly. So there are a variety of functions and events that need to be managed during operation (responding to button presses, responding to network, driving LEDs). I know how I would implement the system if it were in typescript, but not so sure about C/C++.
That said, I’ve checked out
-
ghsalazar’s Event-driven programming in embedded systems blog post (a general intro), and
-
the article Redux in C++: Reducer and Action
-
JSchaenzle’s cedux library “A Redux-like model for C” [1]
-
and in particular, arkhipenko’s TaskScheduler - “Cooperative multitasking for Arduino, ESPx, STM32 and other microcontrollers”[2], and reviewed how it’s used in a few popular projects like PainlessMesh[3].
As you can see, I’ve been doing searches for terms like “event sourcing in embedded C” and I’ve found some resources, but I have the idea that I’m probably using the wrong terminology or thinking about this the wrong way.
about “event sourcing” pattern (sometimes elaborated as CQRS in “enterprise” dev): for example, in the popular “redux” state management framework for JS, the developer writes a monolithic “reducer” function which receives and responds to “events” and updates or returns state data from the “store”. The reducer is the API for state and operations on that state. The reducer function is basically one big SWITCH stack with a bunch of CASEs that match incoming events names. It can get more complicated in CQRS and “event sourcing”, but the basic principle is to locate the logic for all state management in one place. Events typically trigger one and only one function in the reducer, but a reducer function can emit another EVENT (aka ACTION) which then potentially triggers a different reducer function.
thanks folks.
p.s. on the other hand, I am reminded of an article by John Carmack I read a few years back expressing his preference for coding monolithic game engines, basically just one really big source code file, and keeping state really simple (no Actor-style paradigms here like other game engines)[4] (archive[5])
[1]: github com/JSchaenzle/cedux
[2]: github com/arkhipenko/TaskScheduler/wiki/Implementation-scenarios-and-ideas/#1-event-driven-programming
[3]: gitlab com/painlessMesh/painlessMesh
[4]: cbarrete com/carmack.html
[5]: archive: web archive org/web/20130301094048/www.altdevblogaday.com/2012/04/26/functional-programming-in-c
