State machine versus RTOS for microcontrollers

问题:

I stumbled across a free state machine tool. This appears to be for programming embedded systems graphically. By doing so, the author claims that the resulting code is more maintainable than if an RTOS had been employed. This tool is based on UML, which is nice to know, but has a steep learning curve.

I would like to know what some of the more experienced programmers here think of this tool.

I am developing an embedded application for the LM3S5P36 microcontroller. TI has an IDE called Code Composer Studio (CCS). I have not got into CCS yet, but I doubt it has the cool feature of being able to enter the desired behavior into a state machine chart, turn the crank, and pop out C or C++ code. Then go back and edit the chart to generate corresponding revised code. I have programmed microcontrollers in C, but know almost nothing about UML. In the past I have maintained two files, one of them microcontroller code and the other a flow chart. Each code revision meant maintaining two separate files.

So my dilemma is: having discovered this cool chart-to-code all-in-one-documentation-included tool, I would love to use it, but, more than that, I just want to get my project done. Do I do it the old way, or spend a few weeks learning UML?

回答1:

You may also be interested in Miro Samek's book "Practical UML Statecharts in C/C++". Note that Miro is founder and president of Quantum Leaps, so this book goes hand-in-hand with the tool.

It seems that Miro has a lot invested in state-chart development over RTOS development, having written the book and blogged on the subject extensively. He started the thread on LinkedIn's Real-Time Embedded Engineering group titled "Is an RTOS really the best way to design embedded systems?" - plenty of opinions on the subject there!.

I am not sure that the two are necessarily distinct; it is often useful (and frequently done) to implement individual RTOS threads as state-machines. He makes some good points in his blog "I Hate RTOSes, but his reasoning is largely based around poor application design than RTOS technology itself. Just as C or C++ can be dangerous when used ill-advisedly, so to can an RTOS. What I typically see is applications with too few threads with poor cohesion and tight coupling, but I am sure that Miro will be tearing his hair out at the thought that the solution is more threads!

UML 2.2 specified 14 types of diagram, state-machine being just one, so there is no need to learn UML in its entirety. It is used in this case because it is a well defined model with clear syntax and semantics, suitable for defining behavioural detail. State-machine diagrams (or state-charts) are probably the easiest UML behavioural diagrams to understand, and have the most clearly defined semantics of any UML diagram.

回答2:

I did not try the tool but if you get UML diagrams then it is always better for your project documentation. Code generation from UML is now pretty good using Class diagrams and I suppose it could be the same for the other diagrams.

回答3:

One approach which may satisfy your needs is presented on http://www.StateSoft.org It uses very small but functionally complete subset of UML – if you look at the set of graphical API’s at State Machine Gallery, you will learn needed subset of UML SM notation intuitively in matter of minutes. For the efficiency of embedded system memory usage highly optimized table is produces. Depending if you use C or C++, you choose compact table executer.