First: As I’m the product manager of the IAR visualSTATE product I would like to add a bit of information to the paragraph about our code generation. The user has the option to choose between table-based code generation(which is obviously a bit ‘difficult’ to decipher…) and what we call “readable code” which is a straight translation of the state charts into switch and if-statements. What is a bit surprising is that a large majority of our users stick to the table-based code…
When asked about this they often answer that they don’t care about the generated code because they never have a need to change the code. Further, the code size needed for the ‘driver’ code to interpret the tables are well below 1k if compiled with a modern compiler. Typical numbers are more in the 400-600 bytes range and can be as low as <300 bytes under certain circumstances.

Second: The question about generating C/C++ or directly to assembly language has a quite obvious answer, at least for me: Who would ever want to support a modeling tool with code generation capabilities if the generated code should be optimized for speed or size for several target CPU's. (Or even just one?)
I actually came across a customer a few years ago that had their own tooling for translating UML to assembly language for an 8-bit controller; but I see that as a rare exception and the company was not too happy about the situation due to the lock-in effects on hardware choices, the maintenance costs etc.

Currently, QM supports packages, classes, class inheritance, class attributes, class methods, and state machines associated with classes. State machines are supported in graphical way, and I believe that drawing hierarchical state machines in QM is a lot easier than in Rhapsody and they look better in QM. A lot of thinking and work has been done in QM to respect the designer’s preferences on attachment points and routing of transitions, placement of labels, and even sensitivity of the background in nested states. You simply need to try both QM and Rhapsody to appreciate that in QM you don’t need to “fight the tool” every step of the way.

Also, with QM you are much closer to the code. Any code that you enter into the QM model (and every model regardless of the tool has a lot of textual information, such as actions executed by state machines) is in C or C++, depending on your initial choice of the framework. No indirections of an “Action Language” is used.

The code organization and generation in QM is also fundamentally different than Rhapsody (Please see my previous post “Turning Automatic Code Generation Upside Down”). Again, the main goal in designing this feature was to minimize “fighting the tool”. In QM, you ask the tool to generate elements of your code, where you believe that the tool can help. But otherwise you can keep the tool out of your way in places that it does not add value. You don’t need to tweak hundreds of parameters of code generation.

Regarding safety standards, QM provides no formal, built-in support for IEC 61508, the various SILs, or IEC 26262. But, at the same time there is nothing, which would prevent you from developing compliant designs and code with QM. The strength of the QM tool relies to a large degree on the underlying QP frameworks, which very favorably compare with the frameworks supported by Rhapsody. The QP frameworks have been recently updated to very high level of compliance with MISRA-C:2004 (QP/C and QP-nano) and MISRA-C++:2008 (QP/C++). The Application Notes and MISRA Compliance Matrices (http://www.state-machine.com/resources/appnotes.php) provide the ready-to-use quality system with automated rule checking and test–a huge time saver for anyone interested. The QP frameworks provide also strong support for testing through the built-in QS (Quantum Spy) tracing instrumentation.

In summary, the right choice of a tool for you depends on the features you actually end up using. If you only end up using diagramming, you don’t need Rhapsody or even QM–you need a “simple drawing tool”. If you seriously think of code generation, QM will provide you exactly this at much lower cost than Rhapsody. Only if you seriously think you will use more than this, Rhapsody could be the right choice. From my experience, however, very few teams reach that level of sophistication.

I’m really new to Rhapsody and haven’t had a training course, so I’m quite lost at the moment and end up fighting with the tool (it’s not intuitive is it?). I currently don’t feel as productive as I could be without Rhapsody.

So at the moment I’m really asking myself how efficient can you get with Rhapsody and is it really worth it. Maybe I should buy a copy of your book to get a different view on UML and the benefits of it…

Also if I want to start to argue against the use of Rhapsody I should probably create a not so simple project and demonstrate the benefits of a different way like your QM/QP. Are you familiar with SIL (IEC 61508) and can you comment on how well the requirements can be covered with QM? (actually I’m not very familiar with it so I can’t really spell out what I’m looking for, probably a bad place to start)

In future I see the complete program as an abstract syntax that is displayed as state machine, c-source, graphs or what ever representation is best suited for the current task.

As long as the involved tools preserve the hierarchy of abstraction of the program one can create state machine templates, HTML handlers/generators, DSL , documentation etc.

But, these are early days yet and model-to-code generation follows pretty much exactly the same trajectory as all other code generation technologies in the past. For example, most early C compilers generated assembly code (in fact, many embedded compilers still do). The early C++ compilers were all based on “cfront”, which compiled C++ to C. And so on.

Such gradual, stepwise approach has many obvious advantages. It allows people to get used to the “new” by seeing how it turns into the old and familiar first. It allows leveraging the existing tools. A young technology cannot cover all the bases at once. For example, by generating portable C/C++ the code generator can address many more processor types than by generating specific machine code.

The intermediate step of C/C++ also allows the developers to use the existing debuggers. This is not quite ideal, because debugging at the C/C++ level is below the model level. But in practice the inconvenience depends very strongly on the type of the generated code. For example, if such code uses compressed hexadecimal state-tables to represent state machines (e.g., IAR visualSTATE), you obviously have no chance of bridging the semantic levels.

But if the code is designed upfront to be human-readable, you can quite easy see the model structure from the code. This is exactly the approach taken in the QM tool, which is based on the QP framework. QP has been originally designed for manual coding without “big tools” (see my first book “Practical Statecharts in C/C++”, published in 2002). But it turns out that QP makes also an excellent target for automatic code generation. On top of this, QM adds special comments to the generated code, which cross-reference the code snippets to the model. While debugging the application, you can simply copy the closest such comment to the Clipborad and paste it to QM. QM then will immediately locate the corresponding model element, open the diagram and highlight the class method, state, transitions, guard, or whatever that is. With this simple method you almost debug at the model level.

Have you tested also the Unity framwork?
in VC++ and some other embedded compiler?

I have problems with the macro’s in the unity_fixture.h

The problem is the macro construction that generates a function declaration followed by the call to it, see code snippet below, strangely it compiles in GCC

TEST_GROUP_RUNNER(LedDriver)
{
// RUN_TEST_CASE(LedDriver, LedsOffAfterCreate);
void TEST_LedDriver_LedsOffAfterCreate_run();
TEST_LedDriver_LedsOffAfterCreate_run();

// RUN_TEST_CASE(LedDriver, TurnOnLedOne);
void TEST_LedDriver_TurnOnLedOne_run(); // this is row 30 that the compiler reports an error for
TEST_LedDriver_TurnOnLedOne_run();
}

—-—– compile error in VC++ 2008 express –—-
code/unity/LedDriver/LedDriverTestRunner.c(30) : error C2143: syntax error : missing ’;’ before ‘type’
-—-—-—-—-—-—-—-—-—-—-—-

I want an automatic tool that could convert a nested code such kind of:

(C / C++)

if (q1 && q2 || ….)
{
do_1();
if (q3 …)
{
do_3();
if (q4 …)
{
do_4();
…
}
else
{
do_e4();
…
}
else
{
do_e3();
…
}
}

To the type of linear code:

if (q1 && q2 || ….)
do_1();

if ((q1 && q2 || ….) && q3)
do_3();

if ((q1 && q2 || ….) && q3 && q4)
do_4();

if ((q1 && q2 || ….) && q3 && !q4)
do_e4();

if ((q1 && q2 || ….) && !q3)
do_e3();

Do you know of such a tool?

Thank you

Uri.

just a side-note: Locking interrupts on ColdFire is very costly: The lock/unlock pair needs up to 15cycle (including preserving the old state).

Cheers,
42Bastian