Thanks! A quick glance at the book and it seems like it's focused on event-driven. Also seems kind of aligned with Lee's "actor model" stuff. I will read it more.
I am ok-but-not-great programmer, hence trying this project to get better. It seems like I should learn UML proper and this book looks like a good way to start; my "architecture" diagrams are pretty laughable. I bounce between trying to be formal and learn what "proper architecture diagrams" are vs. thinking I'm spending way too much time not coding.
I'm on a dirty and probably not-so-great hybrid of timer + event (mqtt) right now. I really want to try fully event-driven but it's a big change and I'm not very familiar with what it would entail. My original goal with this project was to implement MPC from scratch. V0 was mostly learning esp32 stuff and very basic bang-bang and timer control + FSMs that probably matched no formal specification. I've finished(or at least froze) the V1 microcontroller am starting the basic control/"driver" layer now, which is FSM based, so this reference is perfect timing. Thanks again!
Yes, very event/message-oriented. The state machines exchange messages and process them to completion. I'm not sure who Lee is (Actor Model proper is Carl Hewitt, Gul Agha) but it's interesting that you make the connection, I agree. Erlang, the actor language that never heard of the actor model, has an FSM class that is also interesting to look at.
UML is a standardisation of a bunch of different techniques for drawing pictures about systems. Drawing pictures can be useful for thinking about things, especially if you're a visual thinker. But statecharts are really the star of the show I think, they represent something that is easier to understand as a picture (hygraph) than as code.