3/16/2023 0 Comments Graphviz state machineWhere threads excel in software is providing a narrative in the code that shows the writer / maintainer how the code works very explicitly, but that is kind of useless if there really isn't a narrative, but a few dozen actions that get taken in this mode but not that mode based on button presses. Seperate threads then lead to mutexes because the code can swap out in various ways, and this is not the case in statemachines because they can run multiple thread like operations sequentially without interruption off of the same thread. Having that many threads requires too much overhead in embedded software, it takes up memory and requires context swaps. In embedded systems often each sensor (of dozens) have a different narrative of a procedure to make a reading or setup the sensor. They are generally the preferred way of doing embedded software, but what is the real advantage? A thread always provides a better narrative of how one thread of execution of a procedure needs to work. They are also ideal when you can segment the behavior of different parts of the system as a state. Statemachines are often the best solution when you can't have the overhead of a thread, or enough threads. The author has done a fair bit of both Desktop and Embedded development. Maintaining, fixing, documenting, and testing software is often more than half the total cost. I use a napkin or scrap paper, then I spend a few minutes to write it, and an initial hour debugging it, then a few days trying to figure out why it doesn't work when combined with this or that corner case. There are plenty of tools for sketching state diagrams, and software engineers know how to write code. The author feels that simplifies the easy and not very expensive part of development. Most frameworks in recent years seem to focus on making design, and framework adoption easier by allowing users to draw states and then generate the code automatically. In practice software engineering is largely about what is practical in terms of achieving quality goals quickly with maintainable code that can be documented and tested cheaply. State machines are a good alternative to threads for complex problems because: they split behaviors into groups by state allow re-entrance at numerous steps that would be less practical with a thread and they can transition to different and even concurrent sets of behaviors as needed. Doxygen is particularly great, and the graphviz project by AT&T research was groundbreaking.įor embedded systems the code presented here can have the strings stripped out when not testing or debugging to cut down on the overhead, or they can be replaced with 4 letter symbols (that can be logged as 32 bit numbers). The author has also used SVG, and other sequence diagram from text tools, but felt that for this example. The framework here uses a feature built into Doxygen which allows the code to write (at creation or as a log) text that can describe a statemachine graph. Roughly 20 years ago, this kind of solution worked by recording state numbers, and event transitions with timestamps and then automating a graph that described the system. The solution presented here the author has used on may projects: have the code tell you what it could do, and when run, tell you what it did do, and do it graphically. How do you prove that the code meets the requirements and was exercised correctly in that scenario? How do you maintain it / make changes to the code? Then "fixing" the problem often chases the problem from one state to the next.įor complex statemachines the problem is: the paralell behavior of another statemachine becomes far to complex. Very often the concurrent behavior of one state vs. When a statemachine is being used to handle dozens of events and sensors in 10-12 different modes of operation it gets to a point where the individual statemachine components are easy to describe and code but the system as a whole can't quite be pictured. Simple statemachines (debouncing a button, managing an SQL transaction) are relatively easy to do in just about any framework. The article tries to show how you can solve the major problem with using statemachines, debugging and testing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |