FAQ about visualSTATE

visualSTATE is an excellent tool for many design tasks dealing with functional safety. For example, the IEC-61508 standard on functional safety explicitly recommends state machines as one design method to meet higher SIL levels.

By designing a system of state machines in visualSTATE, you are able to take advantage of the formal verification to find issues in your design that are virtually impossible to write full coverage test suites for. Examples of what can be found are dead lock situations, unreachable parts of the design, never consumed input etc. See Formal verification in visualSTATE.

The state machine subset of UML is easy to learn, clean and with well-defined semantics. UML is also a part of many software engineers' toolbox and is widely taught at schools and universities, which flattens the learning curve even more.

The well-defined semantics makes it suitable for tight automatic code generation, without the need for the designer to guide the code generation to resolve ambiguities etc. See Code size considerations.

visualSTATE is a pure state machine tool. The added benefits of integrated formal verification, testing and validation tools together with a well-proven code generator, means that for many applications you do not really need anything else.

On the other hand, if you are already using a full UML tool for your general design activities, you will still benefit from visualSTATE if you have parts of the design expressed as complex state machine systems. Thanks to the powerful testing and verification facilities of visualSTATE, you will gain in productivity and quality from day one.

Assuming you are an experienced C developer, and you know how to write ISRs and device drivers, you should be able to pick up UML syntax and basic visualSTATE operation in one day. On day two you will have command of basic Validator operations such as stepping through states, setting breakpoints, animation, scripting. You will be using visualSTATE productively in real world applications in just a few days. If you already have some familiarity with UML and automatic code generation, you will be up and running even faster!

To help you become an even more efficient user of visualSTATE, IAR Systems offers training courses.

Yes. visualSTATE is a good choice for all state machine oriented problems, regardless of hardware platform.

If only parts of your application consists of state machines, it is easy to integrate the generated code into the surrounding application. For moderately complex to very complex state machine systems, you will notice a tremendous increase in productivity and a decrease of quality issues. In fact, visualSTATE is used as an internal development tool in the development of the tool itself!

Two options are available: One table based mode that is extremely compact and a mode for generating a straight forward translation of the state machine into readable C code. Which representation you choose depend on your specific application requirements regarding speed and size tradeoffs and the need to examine the generated code manually.

Yes. The generated code make no assumptions about any compiler specific features or use any construct that is not fully ISO/ANSI conformant.

Yes. The code generator can be configured to use compiler specific keywords to place state machine code and data in memory areas of your choosing. Size of data entities can be forced to 16- or 32-bit to match your target architecture for speed purposes, even if the model only requires 8-bit representation. There are numerous choices to configure the code generator to balance the needs of the MCU target, the compiler and coding standards.

The visualSTATE engine deals with events and an event can be seen as an abstraction of something that happens in the environment. This makes it natural to map an interrupt to a visualSTATE event, if the interrupt should have influence on the state machine.

A typical visualSTATE application runs the state machine engine as part of the main loop, if there is an event to process.

Exactly how the interrupt routine communicates with the state machine engine is up to you. But implementation methods range from letting the interrupt routine set a flag that the main loop can detect, to using a fully featured RTOS queue or semaphore.

The structure of your application is the same as usual. If an interrupt service routine generates input to the system of state machines, the routine simply puts an appropriate event into the state machine event queue and returns.

Yes you can. If you are a user of IAR Embedded Workbench you can choose to use the C-SPYLink facility to get high-level design model feedback directly in IAR C-SPY debugger. The functionality includes graphical animation in the state diagram when executing, the possibility to set breakpoints at the state machine level instead of the C level and trace and log functionality.

If you are using a non-IAR build chain or cannot use a hardware debug solution with C-SPY, you can use the RealLink facility to communicate state machine data over a separate communication channel.

Use visualSTATE to design the control logic of a task, or part of a task. Integrate your tasks with respective priorities into the system with the RTOS in the same manner you would if you were coding the application by hand.

To be able to split visualSTATE code to run in different tasks you split the visualSTATE state machines into different visualSTATE systems. A visualSTATE system is a collection of state machines that are designed as a unit and can run as a unit and that possibly have rather tight coupling to each other. An RTOS application can contain any number of systems and systems can communicate on task level using the available RTOS primitives.

Systems can be assigned arbitrarily to RTOS tasks, so that a task can actually house more than one system at a time.

The code generated by visualSTATE can be integrated easily with an application developed using a RAD tool like Altia Design, Microsoft® Visual Basic®, Microsoft® Visual C++®, Borland® DelphiTM or any other GUI toolkit of your choosing.

A simplified example for Windows® can be found in application note #10743 "Implementing a prototype in visualSTATE and Visual C++”. A screenshot of the interaction between the visualSTATE environment and Altia Design can be found here.

Asynchronous events are handled if they are forwarded to the visualSTATE engine. This is usually done by putting them into the event queue. As long as an event is in the event queue, it will eventually be processed by the visualSTATE control logic. (See the question about interrupts.)

The code generated by visualSTATE focuses on the control logic of a state machine system. This part of the code should not be modified by hand, for a number of reasons of which the most important one is that the design is always the only explicit representation of the control logic. In that way, the model and the executing code always stay in sync.

Modifying state machine code by hand always carry the risk of introducing hard-to-find errors in the internal book keeping of states and conditions, regardless of the original design and implementation method.