Why state diagrams are important - part 2
in the first part we showed why state diagrams are very useful for embedded programmers. In this second part we present how the codegenerator can support you during debugging and testing of your application.
Whats going on in the robot?
Debugging an application that is based on generated code from a state diagram is a bit different compared to debugging hand written state machine code. Why? Because you can assume that the generated code is correct. You don’t have to worry about all the nitty gritty details of the realisation of a state machine in C (e.g. handling history, handling hierarchical designs, placement of entry/exit ...). If the machine does not what it should do then most probably the model is not correct. To track down the problem - especially in deeply embedded real-time systems - typically means to add a tracing mechanism which allows you see which events do fire etc. Here the code generator can support you.

Automatic generation of trace code
The code generator can add trace code automatically. You only have to call the generator with the -Trace command line switch. In this case calls to a trace function are inserted in the generated code. The argument of the trace function is the processed event. A part of the ASURO state machine is displayed below. For every handled event the trace function is called (e.g. xxxTraceEvent(2U)). If the trace code is not anymore needed just call the codegenerator again without the -Trace option.

If tracing is enabled an additional header file is generated which provides a table to map event ids to event strings. E.g. the argument 2U from above corresponds to the second entry in the table. This allows you to easily display the event as text.

The trace function must be provided by yourself. Within the trace function you can decide now what to do with this trace information.
-store it in a ring buffer and read it out later (post mortem)
-display it somehow
-forward it to a monitoring station
-...
The following code was used on the ASURO robot and simply sends the processed event to a monitoring PC.

On the PC it is now possible to watch the event flow in a terminal window.

Watching events in a terminal is not good enough
Watching events in a terminal window is not bad but sinelaboreRT can do even better. When starting the codegen.jar with the -S command line switch an interactive graphical simulation window pops up. The status of the state machine after startup is displayed. The events that can be handled presently are shown in blue and are also listed in left window. The output window shows the executed statemachine code. You can now send events to the machine by clicking on an event. The display is updated accordingly and shows the new status.
Beside the interactive mode it is possible to send events via an UPD port. This is what we show next. A small application receives the events sent from the ASURO robot over a wireless serial link and translates it into a UDP message (see diagram below). The UDP message is received from the simulator and the display is updated accordingly. Click on the simulation image above and watch how the state diagram is updated while ASURO is exploring its environment.


Summary
The sinelaboreRT code generator provides several mechanisms to support you during debugging and testing of your state machine design.
-It can automatically add trace code to the state machine
-It provides an interactive simulation window which can display the status of your
embedded target in real-time.
-With the UPD/IP interface a flexible mechanism is available to use the communication interface your hardware offers. A simple “event forwarder” is all what you need.
Copyright © 2008/2009 Peter Mueller. All Rights reserved. See Trademarks and Terms of Use.