visualSTATE®ftp.indes.com/pub/mirrors/ftp.iar.se/€¦ · This guide is intended as a step-by-step tutorial on how you get started using the visualSTATE software. It is intended

visualSTATE®

Quick Start Tutorial

2visualSTATE®Quick Start Tutorial

COPYRIGHT NOTICE© Copyright 2002–2013 IAR Systems. All rights reserved.

No part of this document may be reproduced without the prior written consent of IAR Systems. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such a license.

DISCLAIMERThe information in this document is subject to change without notice and does not represent a commitment on any part of IAR Systems. While the information contained herein is assumed to be accurate, IAR Systems assumes no responsibility for any errors or omissions.

In no event shall IAR Systems, its employees, its contractors, or the authors of this document be liable for special, direct, indirect, or consequential damage, losses, costs, charges, claims, demands, claim for lost profits, fees, or expenses of any nature or kind.

TRADEMARKSIAR Systems, IAR Embedded Workbench, C-SPY, visualSTATE, The Code to Success, IAR KickStart Kit, I-jet, I-scope, IAR, and the logotype of IAR Systems are trademarks or registered trademarks owned by IAR Systems AB.

Microsoft and Windows are registered trademarks of Microsoft Corporation.

Unified Modeling Language and UML are registered trademarks or trademarks of the Object Management Group, Inc.

Borland is a registered trademark, and Delphi is a trademark of Borland Software Corporation.

All other product names are trademarks or registered trademarks of their respective owners.

EDITION NOTICESecond edition: December 2013.

Part number: TVS-2.

This document applies to version 5 and later of the IAR visualSTATE software.

3

Contents

Figures .................................................................................................................................... 5Tables ...................................................................................................................................... 9

Preface ................................................................................................................................. 11

About this guide .................................................................................................. 11

Assumptions .......................................................................................................... 12

Conventions ........................................................................................................... 12

Short forms ..................................................................................................... 12

Introduction .................................................................................................................. 15

State machines ..................................................................................................... 15

Control logic vs. data manipulation and device drivers .......... 15

Hierarchical representation ....................................................................... 17

Documentation .................................................................................................... 18

visualSTATE user documentation ............................................................. 18

UML notation ................................................................................................ 19

Terminology applied in visualSTATE .................................................. 20

Getting started .......................................................................................................... 23

visualSTATE Project examples ................................................................ 23

Get going with visualSTATE ...................................................................... 23

Designing your visualSTATE model ................................................... 29

Start using the Designer ............................................................................... 29

Create your first visualSTATE statechart ........................................ 32

Testing your visualSTATE model .......................................................... 45

Step-by-step to validate your model .................................................... 45

Testing your model in the target application ................................ 48

Step-by-step to verify your model .......................................................... 48

4

Contents

visualSTATE®Quick Start Tutorial

Generating code for your visualSTATE model .................... 51

Implementing a visualSTATE application ........................................ 51

Example of code for event handling ......................................................... 53

Example of visualSTATE API code ......................................................... 53

Step-by-step to generate code .................................................................. 55

Completing your visualSTATE application ..................................... 57

Additional features ................................................................................................ 61

Documenting your Project .......................................................................... 61

Prototyping ............................................................................................................. 63

Appendix A:Source code example ........................................................................................ 65

Code example for LED application ....................................................... 66

main.c file ....................................................................................................... 67

Actions_to_Outputs.c file ............................................................................ 71

Inputs_to_Events.c file ................................................................................ 72

simpleEventHandler.c file .......................................................................... 73

Appendix B:Frequently asked questions ........................................................................ 77

Appendix C:Understanding visualSTATE control logic code ................. 81

Background ............................................................................................................. 81

visualSTATE code generation technology explained ............... 82

Appendix D:Sample statechart diagrams ....................................................................... 85

Transition triggered by external events ............................................ 85

Transition guarded by a Boolean condition .................................... 86

Entry and exit reactions ................................................................................ 87

History states ........................................................................................................ 88

Index ...................................................................................................................................... 89

5

FiguresFigure 1: visualSTATE engine.................................................................................. 16

Figure 2: Embedded application based on visualSTATE ......................................... 16

Figure 3: Example of a visualSTATE hierarchy....................................................... 17

Figure 4: Example of a visualSTATE hierarchy....................................................... 18

Figure 5: visualSTATE Documentation menu folder ............................................... 19

Figure 6: visualSTATE Examples menu folder ........................................................ 23

Figure 7: visualSTATE Navigator menu folder........................................................ 23

Figure 8: New Workspace dialog.............................................................................. 24

Figure 9: New Workspace dialog, System(s) page ................................................... 25

Figure 10: New Wizard Information dialog.............................................................. 26

Figure 11: Coder Options dialog box, File Output tab.............................................. 27

Figure 12: Navigator Project menu ........................................................................... 29

Figure 13: Designer Project browser......................................................................... 29

Figure 14: Example of topstate in Designer System view ........................................ 30

Figure 15: Designer Statechart Diagram window..................................................... 31

Figure 16: Designer Diagram toolbar ....................................................................... 32

Figure 17: Add Simple State button.......................................................................... 32

Figure 18: Examples of newly drawn states ............................................................. 33

Figure 19: Example of state with name text field ..................................................... 33

Figure 20: Compose State dialog box ....................................................................... 34

Figure 21: Example of named states ......................................................................... 34

Figure 22: Add Transition button.............................................................................. 35

Figure 23: Drawing transitions between states ......................................................... 35

Figure 24: Add Transition buttons ............................................................................ 35

Figure 25: Named states with transitions drawn ....................................................... 36

Figure 26: Element Browser ..................................................................................... 36

Figure 27: Element Browser, event definition .......................................................... 37

Figure 28: Compose Transition dialog box, adding events....................................... 38

Figure 29: New button .............................................................................................. 38

Figure 30: New Event dialog box ............................................................................. 39

Figure 31: Example of statechart diagram with events defined................................ 39


Figure 32: Initial State button ................................................................................... 40

Figure 33: Example of initial state ............................................................................ 40

Figure 34: Local Elements view, pop-up menu of Action Function tab................... 40

Figure 35: Action Function Name and Explanation fields........................................ 41

Figure 36: Compose Transition dialog box, adding action functions ....................... 42

Figure 37: Example of statechart diagram with events and action functions ........... 43

Figure 38: Designer File menu.................................................................................. 43

Figure 39: Navigator reload dialog ........................................................................... 44


Figure 41: Validator windows................................................................................... 46

Figure 42: Debug menu............................................................................................. 46

Figure 43: Validator and Designer Simulation Mode windows................................ 47


Figure 45: Verify warning......................................................................................... 48

Figure 46: Verificator Output window showing verification results. ....................... 49

Figure 47: Interface between mainloop.c and simpleEventHandler.c ...................... 52

Figure 48: Event queue handling .............................................................................. 55


Figure 50: Navigator displaying coder report file..................................................... 56

Figure 51: Example of directory structure for visualSTATE application files ......... 57

Figure 52: Example of project file created using IAR Embedded Workbench ........ 58

Figure 53: Header files to be included in user-written code ..................................... 59


Figure 55: Documenter options dialog, Configuration tab ....................................... 62

Figure 56: Navigator output window, Documentation tab........................................ 62

Figure 57: Prototype for an air conditioner............................................................... 63

Figure A.1: Overview of a visualSTATE application............................................... 65

Figure A.2: Statechart diagram for LED application ................................................ 66

Figure C.1: From visual description to logical rules................................................. 82

Figure C.2: Example of visualSTATE transition syntax .......................................... 83

Figure C.3: Code generated by visualSTATE........................................................... 84

Figure D.1: Simple states with transitions triggered by external events................... 85

Figure D.2: Transition guarded by a Boolean condition........................................... 86

Figure D.3: Entry and exit reactions ......................................................................... 87

7

Figures

Figure D.4: Example of use of history state.............................................................. 88


9

Tables1: Typographical conventions used in this guide .................................................... 12

2: Short forms used in this guide ............................................................................. 12

C.1: Comparison of implementation approaches .................................................... 81


11

PrefaceThis guide is intended as a step-by-step tutorial on how you get started using the visualSTATE software. It is intended for software developers who have not previously applied visualSTATE.

visualSTATE is a Windows-based software package of integrated tools for developing, testing and implementing embedded applications based on statechart diagrams.

The guide demonstrates how you design, test, implement and complete an embedded application by means of visualSTATE.

About this guideThis guide consists of the following:

● Introduction, page 15 gives an introduction to visualSTATE and state machines, including a general description of control logic, data manipulation and device drivers. The chapter also describes documentation and terminology related to visualSTATE.

● Getting started, page 23 describes how you get going with visualSTATE, and how you get access to the visualSTATE Project examples.

● Designing your visualSTATE model, page 29 describes how you create your first visualSTATE statechart by means of the visualSTATE Designer.

● Testing your visualSTATE model, page 45 gives a step-by-step description of how to test and debug the application model you have designed with the Designer.

● Generating code for your visualSTATE model, page 51 describes how to automatically generate code for the statechart designs you have created and tested in the preceding chapters. It also describes how to implement a visualSTATE application in your final application.

● Additional features, page 61 describes how to document your visualSTATE Projects, and create prototypes of visualSTATE models.

● Appendix A: Source code example, page 65.

● Appendix B: Frequently asked questions, page 77.

● Appendix C: Understanding visualSTATE control logic code, page 81.

● Appendix D: Sample statechart diagrams, page 85.

12

Assumptions


AssumptionsThis guide assumes that you are familiar with

● The use of Windows-based applications● Basic principles of state/event modeling● Programming in C.

ConventionsThis guide uses the following typographical conventions:

Note: There may be minor differences between the title bars of the screen pictures shown in this document and those of the current version of the visualSTATE software.

SHORT FORMSIn this guide the following short forms apply:

Style Used for

Italic Used for emphasis of particular words.

Bold Refers to menu commands, for example File > Save As, and window buttons, for example OK.

CAPITALS Refer to keys, for example ENTER.

Courier Used for examples.

TIP Used for highlighting, for example shortcuts.

Note Used for drawing attention to special issues.

<Xxx>.<ext> This syntax is used for referring to files generated by visualSTATE Coder.

Table 1: Typographical conventions used in this guide

Short form Refers to

visualSTATE visualSTATE

Navigator visualSTATE Navigator

Designer visualSTATE Designer

Verificator visualSTATE Verificator

Validator visualSTATE Validator

Coder visualSTATE Coder

Documenter visualSTATE Documenter

Basic API visualSTATE Basic API

Table 2: Short forms used in this guide

13

Preface

Expert API visualSTATE Expert API

VS Project visualSTATE Project

VS System visualSTATE System

Short form Refers to

Table 2: Short forms used in this guide (Continued)

14

Conventions


15

IntroductionThis chapter gives an introduction to visualSTATE and the visualSTATE approach. It describes

● State machines

● Control logic vs. data manipulation and device drivers

● Hierarchical representation by means of visualSTATE

● Documentation

● Terminology applied in visualSTATE.

State machinesFinite state machine models are an important tool for expressing software specifications in abstract form. Representing a state machine abstraction of an application by drawing statechart diagrams has several important design advantages. Such a visual representation is easy to create, understand, communicate, and change.

Using statecharts allows the embedded systems developer to develop applications in a natural, iterative fashion.

visualSTATE is a complete software development package that enables rapid application development through the use of a powerful suite of design, test, and code generation tools. These can be used to translate ideas into working applications much more quickly than with the traditional software development tools.

Control logic vs. data manipulation and device driversEvery embedded application is a combination of control logic and data manipulation and device drivers setup.

Typically, device drivers are written only once. They may then become part of a library which remains more or less constant from project to project. The control logic part of an embedded application that implements the features and specification of a given product may change dramatically.

16

Control logic vs. data manipulation and device drivers


visualSTATE is a software development package that can be used when developing state machine-based control logic for event-driven systems. Implementations based on sequential finite state machines where inputs from external devices send events into the control logic are easily developed using the visualSTATE engine. Events generate some actions which ultimately result in interaction between the system and the external environment.

Figure 1: visualSTATE engine

The externally generated inputs are processed first by the device driver which recognizes the hardware pattern and subsequently informs the visualSTATE engine, which acts according to the state machine model (changes states, executes actions etc.). Actions to be executed are converted in the output part of the device driver.

With visualSTATE you can design state machines using the UML™ notation (see UML notation, page 19).

Figure 2 summarizes the parts that visualSTATE handles in an embedded application.

Figure 2: Embedded application based on visualSTATE

visualSTATEengine

Device driverconverts inputs

to events

Environment

x=port(0); port(1) = 1;

Environment

Device driverconverts actions

to outputs

CONTROL LOGICIAR visualSTATE

code

USERCODE

Convertsinputs toEVENTS

(write once)

Inputbutton_pressed

Inputsensor_triggered

Inputtemperature_gauge

Inputstop_button

Inputkey_pressed

ENVIRONMENT

UsingvisualSTATE

API

ENVIRONMENT

UsingvisualSTATE

API

USERCODE

ConvertsACTIONSto outputs

(write once)

Outputturn_on_LED

Outputstep_motor

Outputclose_valve

Outputdisplay_LCD

Outputshut_down

USER CODE chip initialization(write once)

17

Introduction

Hierarchical representationvisualSTATE offers multiple levels of hierarchical representation. Each level can be used to help software developers structure their application for better management of the overall design.

A visualSTATE session consists of:

● Navigator workspace (vnw file): May contain any number of Projects.● visualSTATE Project (vsp file): May contain any number of Systems. ● visualSTATE System (no file is generated): May contain any number of

topstates.● visualSTATE Statechart file (vsr file): May contain any number of states.

Figure 3: Example of a visualSTATE hierarchy

The visualSTATE hierarchy can further be visualized as shown in Figure 4.

WorkspaceProject

System

18

Documentation


Figure 4: Example of a visualSTATE hierarchy

Explanation to Figure 4

● Each Project has one Global Elements section. ● Each topstate has one Local Elements section.

Element sections contain the names of events, actions, variables, etc.

DocumentationvisualSTATE user documentation

This document provides only the most basic information needed to get up and running using visualSTATE. However, further details on using visualSTATE and its many features can be found in the user documentation, which is included with the visualSTATE software as PDF files. The individual guides can be opened from the Documentation menu folder. See Figure 5.

SystemN

System2Global elements

State1

State2

StateN

Localelements

Topstate1

Topstate2

TopstateN

System1

Workspace

ProjectN

Project2

Project1

19

Introduction

Figure 5: visualSTATE Documentation menu folder

A PDF reader such as Adobe Acrobat Reader is needed to view the documents.

Guide to visualSTATE user documentation

The visualSTATE user documentation includes the following in addition to this guide:

● visualSTATE User Guide describes how to use the visualSTATE tools for designing, testing, code generating and documenting visualSTATE Projects.

● visualSTATE API Guide describes the visualSTATE standard APIs and how to use them.

● visualSTATE Reference Guide describes the constructs, elements and principles of state machine modeling that are available in visualSTATE. For example it explains concepts such as states, transitions, state reactions, action functions, guard expressions, visualSTATE Projects, Systems and Statechart files, etc.

UML notation

The UML (Unified Modeling Language) is a language for specifying, visualizing, constructing and documenting, for example software systems. It specifies a modeling language that incorporates basic object-oriented modeling concepts.

The UML notation also includes a notation for state machines, which is used in visualSTATE version 5 and later. Contrary to the Mealy and Moore notations this notation is based on hierarchical state machines, and concurrency can be used at any level in the state hierarchy. Variables are introduced and can be used as conditions or modified within the design. Actions can be used on transitions and as entry and exit reactions. It is possible to apply some memory to the state machines.

You can read more about the UML concepts in the following:

● OMG Unified Modeling Language Specificationversion 2.4.1, August 2011.

20

Terminology applied in visualSTATE


Terminology applied in visualSTATEBefore we get going with visualSTATE, it is important to get familiar with some of the most commonly used terms in visualSTATE. These terms are listed in the table below. You can read more about the individual concepts in visualSTATE Reference Guide.

Term Explanation

Navigator workspace The Navigator workspace is a graphical environment for handling a collection of visualSTATE Projects, Systems and Statechart files. The workspace contains session-specific information, which is included only in that environment.

Project / visualSTATE Project:

A collection of visualSTATE Systems. Each visualSTATE Project is capable of containing several statecharts. The visualSTATE Project also contains global elements. The visualSTATE Project data is stored in a visualSTATE Project file which has the name extension vsp.

System / visualSTATE System

A collection of one or more Statechart files (name extensionvsr). If state/event models are grouped in the same visualSTATE System, they can be synchronized to each other via state conditions. Thus their behavior can be affected by the behavior of the other state/event models within the same visualSTATE System.

Statechart file / visualSTATE Statechart file

A file that contains the logic information about the designed model, for example states and transitions. The Statechart file represents a way of modularizing a visualSTATE System. When a visualSTATE System is split into more than one visualSTATE Statechart file, it ispossible to gain the benefits of team development on the same System. File name extension is vsr.

Topstate The topmost state in a state hierarchy.

Topstate region A region within the topmost concurrent state.

Device driver A program that controls a device. A driver acts like a translator between the device and programs that use the device. Each device has its own set of specialized commands that only its driver knows. In contrast, most programs access devices by using generic commands. The driver, therefore, accepts generic commands from a program and then translates them into specialized commands for the specific device, and vice versa.

Low-level device driver A device driver written to control a chip’s on-board peripherals, such as A/D, timers etc.

High-level device driver A device driver written to control external peripherals, such as LCDs, LEDs etc.

API calls Function calls to routines contained in the API (application programming interface) provided with visualSTATE.

21

Introduction

Local elements Events, actions, variables, signals etc. that are defined at topstate level. They normally have the scope of the topstate itself.

Global elements Events, actions, variables, signals etc. that are defined at Project level. Thus they have the scope of the visualSTATE Project, including all visualSTATE Systems contained in it.

vnw file Navigator workspace file.

vsp file visualSTATE Project file.

vsr file visualSTATE statechart file.

vws file Validator workspace file.

Term Explanation

22

Terminology applied in visualSTATE


23

Getting started● When you have installed visualSTATE, you are ready to get started using it.

This chapter describes how you

● Get access to the visualSTATE Project examples

● Get going with visualSTATE.

For installation, refer to the relevant installation documentation.

visualSTATE Project examplesThe visualSTATE software package includes examples of application designs created with visualSTATE.

The examples can be opened via the Start menu (see Figure 6), or the Navigator (File > Open); see Get going with visualSTATE, page 23.

Figure 6: visualSTATE Examples menu folder

Click on the desired example in the Examples menu folder. The examples can be used to help fuel your own design as well as provide a reference for design techniques.

Get going with visualSTATE1 Go to the Start menu, and launch visualSTATE Navigator. See Figure 7.

Figure 7: visualSTATE Navigator menu folder

24

Get going with visualSTATE


2 Click on Create A New Workspace and subsequently click OK. In the dialog box displayed, select Workspace Wizard and type the file name of your Navigator workspace. Then select a directory to save it to. See Figure 8.

Figure 8: New Workspace dialog

When you have filled in the dialog box, click OK.

3 In the System(s) dialog box that appears, type the name of your System. See Figure 9.

25

Getting started

Figure 9: New Workspace dialog, System(s) page

When you have filled in the dialog box, click Finish. You will get a status window showing which files will be created (see Figure 10).

26



Figure 10: New Wizard Information dialog.

Click OK. The Designer will now be started and you can start editing your Project. This is further described in the Designing your visualSTATE model.

4 You have now created a workspace with a Project Project containing one System MY_System containing a topstate Topstate1.

5 In the Workspace window, right-click on Project and select Options > Code generation.... On the File Output tab of the Coder Options dialog select the output directory where you want visualSTATE to place the generated C code. The default location is the directory coder in the directory containing the project file (.vsp file). See Figure 11. On the Code tab select Generate digital signature by clicking the option.

27

Getting started

Figure 11: Coder Options dialog box, File Output tab

When you have filled in the dialog box, click OK.

You have now completed configuring your visualSTATE workspace and Project. You can now proceed to draw the model of your application in the Designer.

28



29

Designing your visualSTATE modelThis chapter describes how you

● Start using the Designer

● Create your first visualSTATE statechart.

Start using the Designer1 In the Navigator Project browser, single-click on your Project (see Get going with

visualSTATE, page 23). Then go to the menu bar and select Project > Designer. This launches the Designer application. See Figure 12.

Figure 12: Navigator Project menu

2 In the Designer Project browser, double-click on your topstate (see Figure 13). This opens the System View window.

Figure 13: Designer Project browser

30

Start using the Designer


TIP: Close the Property and Output window and maximize the Statechart Diagram window to give you the largest drawing space.

3 There are several levels of hierarchy in your Project. Double-click on the topstate rectangle in the System View, and the Statechart Diagram window opens. See Figure 14.

Figure 14: Example of topstate in Designer System view

This will bring you to the Statechart Diagram window where you can draw your statechart diagram (see Figure 15).

31

Designing your visualSTATE model

Figure 15: Designer Statechart Diagram window

Almost all of the tools on the Diagram toolbar should now be available. See Figure 16.

32

Create your first visualSTATE statechart


Figure 16: Designer Diagram toolbar

If you hold your mouse pointer over any of the tool icons, a ToolTip box will appear explaining what the tool is.

You are now ready to create your first statechart.

Create your first visualSTATE statechart1 Click on the Add Simple State button on the Diagram toolbar. See Figure 17.

Figure 17: Add Simple State button

Go to the diagram, and click on it. A state will be created. Deactivate the Add Simple State tool by right-clicking the mouse. The state you have drawn can be resized and moved as necessary.

33


Figure 18: Examples of newly drawn states

2 Use either of the following methods to name your states:

A) Single-click on the state name you wish to rename. This will open up a text field where you can type the name of the state (for example Select_LED).

Figure 19: Example of state with name text field

B) Double-click on the state you wish to name. This will display the Compose State dialog box (see Figure 20). Type the name of the state in the Name field (for example Select_LED).

34



Figure 20: Compose State dialog box

Figure 21 shows examples of named states.

Figure 21: Example of named states

3 Click the Add Transition button on the Diagram toolbar. See Figure 22.

35


Figure 22: Add Transition button

Go to the Statechart Diagram window, and

A) Single-click on the desired source state.B) Move the pointer to the destination state. C) Single-click to complete the transition.

Figure 23: Drawing transitions between states

TIP: There are three different Add Transition tools that allow you to draw straight, curved and orthogonal lines. Click on the appropriate Add Transition tool to make your selection. See Figure 24.

Figure 24: Add Transition buttons

TIP: It is possible to move a transition by moving its end points. To do this, click the transition, and move the cursor to one of its end points. When an ellipse appears, click the left mouse button and drag the point to move it. When the point is in the right position, release the mouse button, and click the left mouse button again.

To add a route point to a transition:

1 Single-click on the desired transition.

2 Move the pointer to an existing route point or end point. Then click the left mouse button and press the ctrl key.

3 Move the pointer to the desired location, and release the mouse button and the ctrl key.

A

B C

36



Figure 25 shows states with transitions drawn.

Figure 25: Named states with transitions drawn

4 To add an event to a transition, do the following:

From the View menu, select Element Browser. In the Element Browser select MY_TopState as the element location. Use the Event tab to define the events for your state machine. Press the New button in the left-most sub-window of the Element Browser. See Figure 26.

Figure 26: Element Browser

37


Activate the event Name field in the right-most sub-window of the Element Browser. Type the name of your event, and maybe an explanation in the Explanation field, for example eButton1. See Figure 27.

Figure 27: Element Browser, event definition

Return to the Statechart Diagram window, for example by double-clicking on one of the states shown in the Project browser. Double-click on the text box accompanying the transition you wish to compose. This will display the Compose Transition dialog box. Single-click on Trigger in the Rule section. Then in the right pane, double-click the desired event to add it to the trigger. See Figure 28.

38



Figure 28: Compose Transition dialog box, adding events

When you have completed composing the transition, click OK.

TIP: You can also create a new event via the Compose Transition dialog box. Click the New button on the Element toolbar. See Figure 29.

Figure 29: New button

Fill in the New Event dialog box that is displayed. See Figure 30.

39


Figure 30: New Event dialog box

An example of a statechart diagram with named states and defined transitions is shown in Figure 31.

Figure 31: Example of statechart diagram with events defined

5 On the Diagram toolbar, click the Initial State button (see Figure 32). Add an initial state to the state chart. Also add an empty transition from the initial state to one of the simple states (for example the state Select_LED as initial).

40



Figure 32: Initial State button

Figure 33: Example of initial state

6 Open the Element Browser from the View menu. Click the Action Function tab to go to the page where you can define the action functions for your state machine. Press the New button. See Figure 34.

Figure 34: Local Elements view, pop-up menu of Action Function tab

Activate the Name field in the right-most sub-window of the Element Browser. Type the name of your action function, and maybe an explanation in the Explanation field. See Figure 35.

41


Figure 35: Action Function Name and Explanation fields

Return to the Statechart Diagram window, for example by double-clicking on one of the states displayed in the Project browser. Double-click on the text box accompanying the transition you wish to compose. This will display the Compose Transition dialog box. Single-click on Action Expression in the Rule section. Then in the right pane, double-click the desired action function to add it to the transition. See Figure 36.

42



Figure 36: Compose Transition dialog box, adding action functions

When you have completed composing the transition, click OK.

An example of a complete statechart diagram with action functions is shown in Figure 37.

43


Figure 37: Example of statechart diagram with events and action functions

7 When you have completed designing your statechart, select File > Save Project on the menu. Then exit the Designer, for example via File > Exit. See Figure 38.

Figure 38: Designer File menu

Click Yes when prompted to reload files in the Navigator. See Figure 39.

Select_LED

Blue_LED

Red_LED

/

eButton1() /Red_LED_ON()


eButton3() /LEDs_OFF()

eButton2() /Blue_LED_ON()

44



Figure 39: Navigator reload dialog

TIP: Check the Do not show this message again and select Reload files silently if you wish to hide the save details in the future.

45

Testing your visualSTATE modelThis chapter describes how you test and debug the visualSTATE model you created in the Designer. For testing you use the Validator and Verificator tools.

You use the Validator for simulating, analyzing and debugging the visualSTATE model. With the RealLink facility you can also use the Validator to monitor and control the run-time behavior of visualSTATE models in a target application.

With the Verificator you can check the logic consistency of your visualSTATE model. The Verificator can be used to check whether the design contains any dead ends, unreachable transitions and conflicting behavior of transitions.

Step-by-step to validate your model1 In the Navigator, select Project > Validator. See Figure 40. This will launch the

Validator.


2 To start the debug process, double-click on SE_RESET in the Event window. This places your System in its initial state.

Step through your System by double-clicking on events in the Validator Event window. In the System window you can see the resulting state combination. In the Action window you can see which actions were generated by the event (see Figure 41).

46

Step-by-step to validate your model


Figure 41: Validator windows

3 On the Validator menu, select Debug > Initialize System to reset your simulation session. See Figure 42.

Figure 42: Debug menu

4 On the Validator menu, select Debug > Graphical Animation (Figure 42) to step through your System graphically. This will open the Designer in simulation mode. Resize or reposition the Validator window in order to see the Designer Simulation Mode window (see Figure 43).

47

Testing your visualSTATE model

Figure 43: Validator and Designer Simulation Mode windows

When you double-click events in the Event window, the resulting state combination will be shown with red borders in your statechart. Blue borders are used for the states that were last active.

48

Testing your model in the target application


5 When you have debugged your state machine design, exit the Validator and return to the Navigator.

Testing your model in the target application With the Validator RealLink feature it is possible to monitor and control the run-time behavior of your visualSTATE model in the target application.

For detailed information on how to use RealLink, refer to visualSTATE User Guide which is included as a PDF file in the visualSTATE software.

Step-by-step to verify your model 1 After you have exited the Validator select Project > Verify System on the menu. See

Figure 44. This will activate the Verificator.


If the Verify Warning dialog box appears, select the option Code generate and verify. See Figure 45.

Figure 45: Verify warning

In the Verificator window you can view the results of the verification (see Figure 46).

49

Testing your visualSTATE model

Figure 46: Verificator Output window showing verification results. All bold checks are checked indicating that no errors were found. Check for ambiguity is written in non-bold text because that check is not performed in the standard verification mode.

If there are any errors or warnings in the verification message, return to the Designer and make the necessary changes. You go to the Designer by selecting Project > Designer on the Navigator menu. See Figure 44.

For detailed information about the visualSTATE verification facility, refer to the visualSTATE User Guide.

50

Step-by-step to verify your model


51

Generating code for your visualSTATE modelThis chapter describes how to automatically generate code for the statechart designs you have created with visualSTATE Designer and how to implement it.

Implementing a visualSTATE applicationTo put your entire application together with visualSTATE as your main control logic engine is easy. Basically, you still have full control over the structure of your application code. You integrate the code created by visualSTATE into the application by calling the appropriate visualSTATE API functions (this will be demonstrated in the example given in this chapter). The rest of your application is business as usual.

For example, you need to create:

● A main.c file● Code to initialize your chip● Code to process inputs● Code to handle your I/O devices● Code that you normally need to write that is not related to the logic of handling a

certain event.

In other words, you still need to create all the “write-once” code. In this way, you keep full control over the structure of your application and need not adopt a new rigid code structure.

When it comes to handling a certain input/event, you need to call ready-made visualSTATE functions and pass your event as a “parameter” to the visualSTATE System.

In a typical real-time embedded application, many events may happen at different times. Therefore it is highly recommended to create a FIFO queue handler so that you can better process your events in a sequential fashion, and in the same order as the one in which they were received. Thus queue handler code is needed (or recommended) to process your events one at a time. A queue handler is just an array of “event types” that can store the event names.

TIP: Ready-made FIFO Queue Handling C Code routines are included with the visualSTATE software. The files can be found in the SampleCode directory under Examples.

Thus an event could be handled in the following way (see Figure 47):

52

Implementing a visualSTATE application


● You create a loop that keeps on checking your queue for any event to be processed.

● Once you receive an input (which could be the result of an interrupt or manual polling/checking), you add the input as an event to your queue. See Example of code for event handling, page 53.

Figure 47 shows the interface between the mainloop.c file and the SimpleEventHandler.c file.

Figure 47: Interface between mainloop.c and simpleEventHandler.c

Note to Figure 47: The items marked with *) are included in the visualSTATE sample code.

*) simpleEventHandler.c

SE

_RE

SE

T

E_P

LAY

_KE

Y

E_C

D_K

EY

E_P

OW

ER

_KE

Y

eventQueue

1st e

vent

Last

eve

nt

* ) DEQ_AddEvent(event)

*) DEQ_RetrieveEvent(&Event)

*) mainloop.c

53

Generating code for your visualSTATE model

Example of code for event handling

1 The next time your while loop checks your queue, it will find an event if there is one.

2 Upon detecting an event in your queue you then call the visualSTATE System (using the SEM_Deduct() API function) and let visualSTATE get back with a list of actions to take (using SEM_GetOuput). For example by using function pointer tables.

3 Call these action functions one at a time.

4 Then change state by calling the API function SEM_NextState.

5 When the state combination has been updated, you go back to the while loop to check your queue for other events to be processed, or perform any other steps required.

Note: When initializing a loop, always supply the reset event as the first event into the queue. The reset event changes the system to the reset state. The default name of the visualSTATE reset event is SE_RESET.

TIP: It is also possible to generate C++ code. This can be an advantage if RealLink is not used and several instances of a system is needed.

Example of visualSTATE API code

void scanInputs (void){ switch (PIND) { case BTN1: SEQ_AddEvent( eButton1 ); /* Add EVENT: eButton1 to the queue */ break; case BTN2: SEQ_AddEvent( eButton2 ); /* Add EVENT:eButton2 to the queue */ break; default: break; }}

/* Define action expression variable. */ SEM_ACTION_EXPRESSION_TYPE actionExpressNo;

/* Define and initialize. In this case the reset event is SE_RESET. */ SEM_EVENT_TYPE eventNo = SE_RESET;

/* Initialize the VS System. */ SEM_Init();

54

Implementing a visualSTATE application


The code shown in Example of code for event handling, page 53, and Example of visualSTATE API code, page 53, is all that must be inserted into your application to process your events. In other words, the above few lines of user-written code constitute your entire control logic code with error handling.

The visualSTATE API calling sequence shown in Example of visualSTATE API code, page 53 is ready-made and available for you to use. You can find it in the SampleCode directory, which is found below the Examples directory of the visualSTATE software.

This methodology of placing your events in a queue, then retrieving them one by one from the queue for handling, is not a new approach (see Figure 48). Actually, it is a normal programming technique used by many sequential processes. It offers a number

/* Initialize external variables if used */ /*SEM_InitExternalVariables();*/

/* Initialize internal variables if used */ /*SEM_InitInternalVariables();*/

/* Initialize signal queue if signals are used */ SEM_InitSignalQueue();

if ((cc = DEQ_Initialize()) != UCC_OK) HandleError(cc);

/* Do forever */ for(;;) { /* Deduct the event. */ if ((cc = SEM_Deduct(eventNo)) != SES_OKAY) HandleError(cc);

/* Get resulting action expressions and execute them. */ while ((cc = SEM_GetOutput(&actionExpressNo)) == SES_FOUND) SEM_Action(actionExpressNo); if (cc != SES_OKAY) HandleError(cc);

/* Change the next state vector. */ if ((cc = SEM_NextState()) != SES_OKAY) HandleError(cc);

/* Get next event from queue */ while (DEQ_RetrieveEvent(&eventNo) == UCC_QUEUE_EMPTY) OS_Wait (OS_VS_EVENT_PENDING, INFINITE); }

55


of advantages to the user and helps create a well-structured, more organized application.

Figure 48: Event queue handling

Step-by-step to generate code1 Start the Navigator and open the visualSTATE Project for which to generate code. In

the Project browser, click the Project. On the Navigator menu, select Project > Code generate. See Figure 49. This will activate the Coder.


2 The Navigator will popup a window with the coder report file where you can see the names of the generated files and their location. This file also contains statistics on the various elements contained in the generated code. See Figure 50.

Eventpre-processing

Actionprocessing

(device drivers)

IARvisualSTATE

APIE1E2E3

Event queue

SEM_Deduct() SEM_GetOutput()

Actionsequence

A1

A2

A3

56

Step-by-step to generate code


Figure 50: Navigator displaying coder report file

57


Completing your visualSTATE applicationTo complete your application you need the following:

1) An ANSI C compiler (for the specific target processor being used)

2) visualSTATE generated code, and

3) User-written code.

1 Create an appropriate directory structure to collect all the source files needed for your application.

Figure 51: Example of directory structure for visualSTATE application files

\Coder-generated:The files created by the visualSTATE Coder.

Note: You should never modify the Coder-generated files. If changes are desired, modify the statechart diagram in the Designer and code generate the visualSTATE Project again.

In this case, the following Coder-generated files are located in the directory:

MY_System.cMY_System.hMY_SystemAction.hMY_SystemData.cMY_SystemData.hSEMBDef.hSEMTypes.h

TIP: You can direct the Coder to place the generated files in this directory:

1 Go to the Navigator.

2 Select Project > Options > Code generation....

3 On the File output tab for the Project click the Output Directory field and specify the Coder-generated directory (see Figure 11, page 27).

\Selected APIs: Copy of the appropriate API files from the visualSTATE \lib directory. In this case these files are from \SEMLibBasic and \SEMLibCommon. The files are the following:

SEMLibB.c

58

Completing your visualSTATE application


SEMLibB.c

\User-written code: You must supply the target-specific code (also known as device drivers) which handles the translation of hardware inputs to visualSTATE events, and likewise visualSTATE actions to hardware outputs. You must also supply a main loop routine that processes the events that occur in the System (see Appendix A: Source code example, page 65).

The files are the following:

Actions_to_Outputs.cInputs_to_Events.cmain.csimpleEventHandler.ceventHandler.hLEDsys_Drivers.hsimpleEventHandler.h

See also Appendix A: Source code example, page 65.

2 Using an appropriate C compiler for your target processor, create a project that includes all the necessary C files. See Figure 52.

Figure 52: Example of project file created using IAR Embedded Workbench

59


Figure 53 shows the header files that must be included in the user-written code.

Figure 53: Header files to be included in user-written code

3 Finally, compile and link your files together.

Selected APIs User-written code Coder-generated files

SEMLibB.c

SEMLibB.h

VSTypes.h

simpleEventHandler.c

Actions_to_Outputs.c

MY_SystemAction.h

Inputs_to_Events.c

main.c

eventHandler.h

ledsys_drivers.h

simpleEventHandler.h

MY_System.c

MY_SystemData.c

MY_System.h

MY_SystemData.h

SEMBDef.h

SEMTypes.h

COMPILE & LINK

Target Executable

60

Completing your visualSTATE application


61

Additional featuresThis chapter describes how you can use visualSTATE for documenting and prototyping your visualSTATE Project.

Documenting your ProjectYou can create an up-to-date documentation report of your entire visualSTATE Project using the Documenter.

1 In the Navigator, open the visualSTATE Project you want to document. On the menu, select Project > Options > Documentation (see Figure 54). This will show the Documenter Options dialog box.


2 On the Configuration tab, select the section(s) you want to include in your documentation report. See Figure 55.

62

Documenting your Project


Figure 55: Documenter options dialog, Configuration tab

You can modify other options of the Documenter by clicking the various tabs (for example collecting other files into the generated report, formatting the margins, inserting headers, footers, etc.).

3 When you are done modifying options, press the OK button. From the Project menu, select Document, and Documenter will generate the documentation report. When it has completed report generation, a completion message will be written to the output window (see Figure 56).

Figure 56: Navigator output window, Documentation tab

63

Additional features

4 The generated documentation report is either in Rich Text Format (rtf) or Hypertext Markup Language (html), and is by default located in sub-directory doc relative to the location of your visualSTATE Project. By default Navigator will try to launch the application associated with the generated file(s), for example Microsoft Word for RTF output.

PrototypingUsing visualSTATE, it is possible to create a graphical prototype of your final product. In the early stages of designing a new product, the prototype allows you to experiment with the user interface before going into detailed (and costly) implementation. An example of a prototype is shown in Figure 57.

Figure 57: Prototype for an air conditioner

Note: An MS-Windows application such as VisualBasic, Delphi or Visual C++ must be used to create the GUI application.

TIP: visualSTATE also offers an integration with Altia FacePlate for making virtual prototypes.

64

Prototyping


65

Appendix A: Source code exampleFigure A.1 provides an overview of a typical visualSTATE application. You can use it as a guide to comprehend the program flow of the source code presented here.

Figure A.1: Overview of a visualSTATE application

SEQRetrieveEvent() /DEQRetrieveEvent()

Is the event queue empty?

SEM_Deduct()Is the current event in the

queue valid?

SE_RESETMust be sent as the first eventin order to place the System inits initial state.

SEM_Init() andSEQ_Initialize()SEM_Init initializes thevisualSTATE System.SEQ_Initialize initializes thequeue.

main()Initializes hardware.

BeginOS_VS_Proces()

SEMGetOutput() / SEM_Action()Process the action(s) associatedwith the transition trigggered bythe event.

YesActions_to_Outputs.cC module containing allpossible actionfunctions.

No

HandleError()Force programtermination.

Are there anyremaining actions to

be executed?

Yes

SEM_NextState()Advance thesystem to the nextstate.

No

No

Function prefixes:SE: State/eventSEM: State/event machineSEQ: Static event queueDEQ: Dynamic event queue

Yes

66

Code example for LED application


Code example for LED applicationThe code shown below was used for a simple LED application with the statechart design shown in Figure A.2.

Figure A.2: Statechart diagram for LED application

The files shown in the following are included with the visualSTATE software. They can be found in the SampleCode directory under the Examples directory.

Select_LED

Blue_LED

Red_LED

/



eButton3() /LEDs_OFF()

eButton2() /Blue_LED_ON()

67

Appendix A: Source code example

main.c file

/****************************************************************************** visualSTATE Main Loop Source File (sample code) targeted for an Atmel* AVR Mega103 microcontroller.** The file contains an implementation for a main loop using the visualSTATE* basic API. ** The code uses a static queue for storing events. The functions for inter-* facing to the queue are described in the sample code file * simpleEventHandler.h.** The file contains calls which uses stdin and stdout. If these streams do* not exist on a specific target, replace such calls with appropriate code.*****************************************************************************/

/* *** include directives *** */

#include <stdio.h>#include <stdlib.h>

#include <semlibb.h>

/* The below include directives contains declarations for a visualSTATE project/system called MY_System. To use a different visualSTATE project, just replace the includes. */

#include "MY_SystemAction.h"#include "MY_SystemData.h"

/* This file is included in order to use an event queue with static size. In order to use a queue with dynamic size, include the header file advancedEventHandler.h and replace 'SEQ_' with 'DEQ_' in all calls to functions with prefix 'SEQ_'. Also, the call to function DEQ_Uninitialize should be uncommented. */

#include "simpleEventHandler.h"

/* User include directives for an Atmel Mega103 target and the LED system drivers */

#include <iom103.h>#include "LEDsys_Drivers.h"

68



/* *** macro definitions *** */

/** Macro value used in call to OS_Wait. Specifies an infinite duration. */#define INFINITE -1

/** Macro value used in call to OS_Wait. Specifies a condition which is true when one or more events are pending. */#define OS_VS_EVENT_PENDING 0

/* *** function declarations *** */

/** Uninitialize all. This function must be called just before program exit in order to free allocated resources (in this case the memory allocated by the dynamic event handler). */void UninitializeAll(void);

/** Handle error. Whenever an error is detected, this function must be called. In this implementation it forces a program exit, which might not be the best solution in all cases. The value returned by exit is the value of the detected error. */void HandleError(unsigned char ccArg); /** Operating system wait. The function mimics an operating system call, which is used by processes entering the wait state. The parameter waitArg informs the OS of a condition to be fulfilled before putting the calling process back into the active state. The parameter duration informs the OS how long the calling process is prepared to wait for the condition to come true. In this implementation both parameters are ignored. */void OS_Wait(unsigned char waitArg, int duration);

/** Operating system visualSTATE process. Mimics a OS process for a visualSTATE system. In this implementation this is the mainloop inter- facing to the visualSTATE basic API. */void OS_VS_Process(void);

69


/* *** variable definitions *** */

/* Define completion code variable. */unsigned char cc;

/* *** function definitions *** */

void UninitializeAll(void){// DEQ_Uninitialize();}

void HandleError(unsigned char ccArg){ printf("Error code %i detected, exiting application.\n", ccArg); UninitializeAll(); exit(ccArg);}

#if 0/* Use OS_Wait to simulate your system using the IAR C-SPY simulator or other source level simulator */void OS_Wait(unsigned char waitArg, int duration){ /* Ignore the parameters; just retrieve events from the keyboard and put them into the queue. When EVENT_UNDEFINED is read from the keyboard, return to the calling process. */ SEM_EVENT_TYPE event;

printf("Putting the OS_VS_Process into the wait state.\n"); printf("Type in event numbers and press return for each one.\n"); printf("Typing %i will end the input sequence.\n", EVENT_UNDEFINED);

do { printf(":"); scanf("%i", &event); if (event != EVENT_UNDEFINED) { if ((cc = SEQ_AddEvent(event)) != UCC_OK) HandleError(cc); } } while (event != EVENT_UNDEFINED || !SEQ_EventPendingP()); printf("Putting the OS_VS_Process into the active state.\n");}#endif

70



void OS_VS_Process(void){ /* Define action expression variable. */ SEM_ACTION_EXPRESSION_TYPE actionExpressNo;

/* Define and initialize. In this case the reset event is SE_RESET. */ SEM_EVENT_TYPE eventNo = SE_RESET;

/* Initialize the VS System. */ SEM_Init();

/* Initialize external variables if used */ /*SEM_InitExternalVariables();*/

/* Initialize internal variables if used */ /*SEM_InitInternalVariables();*/

/* Initialize signal queue if signals are used */ /*SEM_InitSignalQueue();*/

/* Initialize event queue */ SEQ_Initialize();

/* Send SE_RESET event */ SEQ_AddEvent( SE_RESET ); /* Do forever */ for(;;) { /* Deduct the event. */ if ((cc = SEM_Deduct(eventNo)) != SES_OKAY) HandleError(cc);

/* Get resulting action expressions and execute them. */ while ((cc = SEM_GetOutput(&actionExpressNo)) == SES_FOUND) SEM_Action(actionExpressNo); if (cc != SES_OKAY) HandleError(cc);

/* Change the next state vector. */ if ((cc = SEM_NextState()) != SES_OKAY) HandleError(cc); /* Get next event from queue */ while (SEQ_RetrieveEvent(&eventNo) == UCC_QUEUE_EMPTY) { #if 0 /* Use OS_Wait to simulate events occuring in your system */ OS_Wait (OS_VS_EVENT_PENDING, INFINITE); #else /* Use scanInputs if program running on the actual hardware */ scanInputs(); #endif } }}

71


Actions_to_Outputs.c file

/****** ACTIONS TO OUTPUTS ********/

#include "MY_SystemAction.h"#include <iom103.h>

VS_VOID Red_LED_ON (VS_VOID){ PORTB = 0x7F; // LEDS are active-low}

VS_VOID Blue_LED_ON (VS_VOID){ PORTB = 0xBF; // LEDS are active-low}

VS_VOID LEDs_OFF (VS_VOID){ PORTB = 0xFF; // LEDS are active-low}

int main(void){ /* User hardware initialization */ DDRB = 0xff; /* All PORTB pins as outputs */ DDRD = 0x00; /* All PORTD pins as input */

OS_VS_Process();

/* This code is never reached. */ return 0;}

72



Inputs_to_Events.c file

/****** INPUTS TO EVENTS ********/

#include <iom103.h>#include "LEDsys_Drivers.h"

#include "MY_SystemData.h"#include "simpleEventHandler.h"

void scanInputs (void){ switch (PIND) { case BTN1: SEQ_AddEvent( eButton1 ); // Send eButton1 to the queue break;

case BTN2: SEQ_AddEvent( eButton2 ); // Send eButton2 to the queue break;

case BTN3: SEQ_AddEvent( eButton3 ); // Send eButton3 to the queue break; default: break; }}

73


simpleEventHandler.c file

/****************************************************************************** visualSTATE Static Event Handler Source File (sample code)** The file implements an event queue with a static size, specified by the* value of the macro EVENT_QUEUE_SIZE.** Whenever the queue runs full (by a call to SEQ_AddEvent), the event is ig-* nored and an error is returned.** A function is provided for initializing the queue, as well as functions for* adding and retrieving events from the queue. See the associated header file* for descriptions and use of those functions.** The queue is a static variable in this file. If multiple queues are to be* used, the static variable must be removed and the queue handling functions* must be modified to take a parameter identifying a particular queue, for* example a pointer to a queue.*****************************************************************************/

/* *** include directives *** */

#include "simpleEventHandler.h"

/* *** macro definitions *** */

/** Event queue size. Defines the size of the event queue. */#define EVENT_QUEUE_SIZE 20

/* *** type definitions *** */

/** Event queue size type. Defines the type for indexes into the event queue. The type must be an unsigned ordinal type, capable of holding values in the range [0;EVENT_QUEUE_SIZE[. */#if (EVENT_QUEUE_SIZE <= 0x0100)typedef VS_UINT8 SEQ_SIZE_TYPE;#elif (EVENT_QUEUE_SIZE <= 0x010000)typedef VS_UINT16 SEQ_SIZE_TYPE;#elif (EVENT_QUEUE_SIZE <= 0x01000000)typedef VS_UINT32 SEQ_SIZE_TYPE;#else#error Cannot determine type of SEQ_SIZE_TYPE#endif

74



/** Event queue type. Defines the internal structure of the event queue. */struct StaticEventQueue{ /** Event queue. The array stores events in the queue. */ SEM_EVENT_TYPE queue[EVENT_QUEUE_SIZE];

/** Front index into the queue. The front index specifies the index into the array, where the next event will be retrieved from. */ SEQ_SIZE_TYPE front;

/** Back index into the queue. The back index specifies the index into the array, where the next event will be stored. */ SEQ_SIZE_TYPE back;};typedef struct StaticEventQueue StaticEventQueue;

/* *** variable definitions *** */

/** The event queue. If more than one event queue is needed (for example when a visualSTATE project contains more than one system), the event queue must be a parameter for all event queue handling functions instead of being a static variable. */static StaticEventQueue eventQueue;

/* *** function definitions *** */

void SEQ_Initialize(void){ eventQueue.front = eventQueue.back = 0; eventQueue.queue[0] = EVENT_UNDEFINED;}

UCC_TYPE SEQ_AddEvent(SEM_EVENT_TYPE event){ /* If the queue indexes equals and the 'current' event is not undefined, the queue is full. */ if (eventQueue.front == eventQueue.back && eventQueue.queue[eventQueue.back] != EVENT_UNDEFINED) return UCC_QUEUE_FULL;

/* Store the event in the queue. */ eventQueue.queue[eventQueue.back] = event;

/* Increment the back queue index. */ eventQueue.back = (eventQueue.back + 1) % EVENT_QUEUE_SIZE;

return UCC_OK;}

75


UCC_TYPE SEQ_RetrieveEvent(SEM_EVENT_TYPE* pEvent){ /* Retrieve event from queue. */ if ((*pEvent = eventQueue.queue[eventQueue.front]) == EVENT_UNDEFINED) return UCC_QUEUE_EMPTY; /* Increment the front queue index. */ eventQueue.front = (eventQueue.front + 1) % EVENT_QUEUE_SIZE;

/* If queue is empty, indicate this by setting the 'current' event to the undefined value. */ if (eventQueue.back == eventQueue.front) eventQueue.queue[eventQueue.back] = EVENT_UNDEFINED;

return UCC_OK;}

void SEQ_Clear(void){ eventQueue.front = eventQueue.back = 0; eventQueue.queue[0] = EVENT_UNDEFINED;}

VS_BOOL SEQ_EventPendingP(void){ return (eventQueue.front != eventQueue.back || eventQueue.queue[eventQueue.front] != EVENT_UNDEFINED);}

76



77

Appendix B: Frequently asked questionsQ: How can I use visualSTATE with my interrupts?

A: You write your own interrupt service routines (ISRs). Your ISRs should be short. The body of the ISR should contain code that sets and clears flags, increments counters etc. The main job of the ISR will be to forward events to the visualSTATE engine for processing.

In other words, you can use visualSTATE and interrupts the same way you use it with any other C code. Either you just process your interrupt and return to visualSTATE, or you let the interrupt generate an event and put this event in your event queue.

Q: How can I use visualSTATE with my RTOS?

A: 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 have to split the visualSTATE statecharts in different visualSTATE Systems. A visualSTATE System is a collection of statecharts that can run independently. You can change between the different visualSTATE Systems as you change between the different tasks in your RTOS. If you want visualSTATE to handle more than one System you must use the visualSTATE Expert API, which also supports preemption. If you only want to use visualSTATE in one task then you just handle the visualSTATE code as “ordinary handwritten” C code.

Q: Can I modify the generated code?

A: There is no reason to modify the code generated by visualSTATE. The developer should restrict his/her attention to device drivers, initialization code and API calls.

If the functionality must be modified, you should always use the Designer. If you want to make some kind of workaround, you should be aware that all automatically generated files are overwritten.


Q: Can I prototype my design before having the hardware?

A: The code generated by visualSTATE can be integrated easily with an application developed using a RAD tool like Microsoft® Visual Basic®, Microsoft® Visual C++®, or Borland® Delphi™. Have the application call the visualSTATE API functions as you would in the embedded application. You must ensure that events are forwarded to the visualSTATE engine from the front end emulator just as you would forward them from external devices such as switches, keypads etc. in the real world.

Q: How can I handle asynchronous events?

A: 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.

Q: Can I use visualSTATE to create applications that can run on a PC?

A: Yes. In fact, visualSTATE works fine for PC applications as well, especially when you are generating a custom interface.

Q: Is the code generated by visualSTATE really portable?

A: The code generated by visualSTATE mainly consists of two elements: the core model logic and the API. There are no portability issues if you use an ANSI C compliant compiler. The core model logic is readily portable across platforms.

Q: What is the learning curve like for UML and visualSTATE?

A: 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 productively using visualSTATE in real world applications within one week.

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

Q: I have two sites using visualSTATE. Can I send a Project from one site to another?

A: Yes. All you need to do is send the files with the following extensions:

vnw Navigator workspace file

79

Appendix B: Frequently asked questions

vsp visualSTATE Project file

vsr visualSTATE Statechart file

vws Validator workspace file

vtg Project options file

This will allow both sites to operate off the same state machine model and the same visualSTATE settings.


81

Appendix C: Understanding visualSTATE control logic codevisualSTATE generates table-based C code which is different from ordinary C code. Here you can read about the characteristics of the code generated by visualSTATE and its advantages.

BackgroundControl logic development in most embedded applications is an important phase of the application.

This logic can be implemented using a long sequence of IF..ELSE and Switch/Case statements or using a table-driven pointers to functions. Table-driven control logic is best suited for expert embedded systems. Table C.1 shows a comparison between the two approaches.

Novice control logic using "IF…ELSE and

SWITCH/CASE" statements

Expert control logic using table-driven

pointers to functions

Long sequences of C code. Compact and short sequence of C code.

Blow up the size of the final generated code. Final code size is tight and compact.

Novice approach - easy to read by inexperienced developers.

Expert approach - requires development experience to easily read.

May generate faster code due to in line expansion of code (compiler dependent).

May generate slightly slower code due to indirect calling (also compiler dependent).

Minor changes can be easily done while major changes are very difficult to implement.

Minor and major changes can be easily implemented.

It can be difficult to port code from one platform to another.

Portable and platform-independent.

Difficult to predict which external stimuli the system will react to at a certain point of execution.

Easy to predict which external stimuli the system will react to at a certain point of execution.

Table C.1: Comparison of implementation approaches

82

visualSTATE code generation technology explained


visualSTATE code generation technology explainedvisualSTATE generates expert control logic code for embedded systems by translating your state machine model into table-based C code. This table is applied by the visualSTATE API to conduct all events, guard expressions, variables, signals and actions. How is this translation possible?

This translation is possible because state machines can be expressed in Boolean equations using established mathematical notations.

For instance, see Figure C.1.

Figure C.1: From visual description to logical rules

If we are in state S1 and the event E1 occurs, then the action A1 is executed and the system moves to state S2. In other words IF (E1 & S1) THEN (S2 & A1).

ConcurrentRegionsRegion1 Region2

S1

S2

S3

S4

S5E2() !S4 / A2() A3()

E3() / A4() A5()

E1() / A1()

E5() / E4() /

E1 AND S1 -> S2 AND A1

E2 AND S2 AND NOT S4 -> S3 AND A2 AND A3

E3 AND S3 -> S1 AND A4 AND A5

E4 AND S4 -> S5

E5 AND S5 -> S4

83

Appendix C: Understanding visualSTATE control logic code

Even more complex transitions can be expressed. For instance, if we are in state S2 and event E2 occurs, and state S4 is not active, then the actions A2 and A3 are executed and the system moves to S3. In other words IF (E2 & S2 & !S4) THEN (S3 & A2 & A3). This ability to take state machines from a visual description to logical rules allows us to establish the visualSTATE transition syntax.

Figure C.2 shows the transition syntax. This syntax is used by visualSTATE to generate its table-based code using hexadecimal numbers to represent your state machine. Embedded in each hexadecimal number are the four components of the model logic: the event, the current state vector, the next state vector and the action vector.

Figure C.2: Example of visualSTATE transition syntax

The final result of applying the transition syntax is an ANSI C structure of hexadecimal arrays as shown in Figure C.3.

E CSV : NSV AV Example: E1 S1 !S4 : S2 A2 A3

Conditionside

Actionside

Event Currentstate

vector

Nextstate

vector

Actionvector

84

visualSTATE code generation technology explained


Figure C.3: Code generated by visualSTATE

The content of the constant data table is interpreted by the visualSTATE API by which it becomes executable C code.

The table represents all the transitions, the list of actions to execute; in other words, your entire control logic. Once more, this patented, breakthrough technology allows very tight code generation, ideal for any memory-strapped microcontroller.

VSDATA const VS ={ { 0X000, 0X000, 0X001, 0X001, 0X002, 0X002, 0X003, 0X003, 0X003, 0X004, 0X004, 0X005, 0X005 }, { 0X000, 0X060, 0X000, 0X002, 0X009, 0X00C, 0X004, 0X008, 0X001, 0X003, 0X010, 0X001, 0X000, 0X003, 0X00C, 0X001, 0X008, 0X001, 0X010, 0X001, 0X000, 0X001, 0X004, 0X001, 0X030, 0X001, 0X001, 0X000, 0X002, 0X009, 0X005, 0X002, 0X010, 0X000, 0X001, 0X004, 0X004, 0X002, 0X010, 0X000, 0X001, 0X005, 0X005, 0X002, 0X010, 0X000, 0X001, 0X006, 0X006, 0X002, 0X010, 0X000, 0X001, 0X007, 0X007, 0X002, 0X031, 0X002, 0X003, 0X000, 0X00C, 0X005, 0X002, 0X000, 0X009, 0X008, 0X00E, 0X003, 0X031, 0X001, 0X00C, 0X003, 0X000, 0X006, 0X00B, 0X003, 0X000, 0X008 }, { 0X00000, 0X000A8, 0X000B2, 0X0003D, 0X00044, 0X0004B, 0X00092, 0X0009C, 0X0006B, 0X00075, 0X000E5, 0X000EF, 0X00088, 0X000BE, 0X00009, 0X00011, 0X00017, 0X0001F, 0X00031, 0X00037, 0X000CB, 0X000D4, 0X000DD, 0X000F9, 0X0011B }, { 0X000, 0X001, 0X003, 0X006, 0X008, 0X00A, 0X00E, 0X012, 0X01A, 0X01D, 0X021 }};

Table of constant data representing the logic of the visualSTATE model

85

Appendix D: Sample statechart diagramsIn order to help you visualize how state machines can represent your control logic, here are multiple samples of statecharts that represent diverse control logic typically used in embedded applications. Each sample includes a description of what the chart represents.

Transition triggered by external eventsFigure D.1 shows an example of simple states with transitions triggered by external events.

Figure D.1: Simple states with transitions triggered by external events

The transition from state LED3TurnedOff to LED3TurnedOn is triggered by pressing the LEFT button and is accompanied by the action LED3_On. Then, if the LEFT button is pressed again, the transition from LED3TurnedOn to LED3TurnedOff is triggered and LED3 is turned off.

LED3TurnedOff

LED3TurnedOn

/

BTN_LEFT_DOWN() /LED3_ON()

BTN_LEFT_DOWN() /LED3_OFF()

86

Transition guarded by a Boolean condition


Transition guarded by a Boolean conditionFigure D.2 shows an example of a transition guarded by a Boolean condition.

Figure D.2: Transition guarded by a Boolean condition

The transition from state T1 to T2 is triggered by pressing the RED button and is accompanied by two actions. LED0 is turned on, and the variable 'a' is incremented. This transition is also guarded by the condition a<3. That expression must evaluate to TRUE in order for the transition to occur. In this case, the LED0 will only be turned on three times. After that, the condition a<3 evaluates to FALSE and the transition will not fire when the RED button is pressed.

T2

T1

/

BTN_RED_DOWN() /LED0_OFF()

BTN_RED_DOWN() [a < 3] /[a = a + 1] LED0_ON()

87

Appendix D: Sample statechart diagrams

Entry and exit reactionsFigure D.3 shows an example of the use of entry and exit reactions.

Figure D.3: Entry and exit reactions

Pressing the middle button (BTN_MID_DOWN) causes a transition from state R1 to R2. This transition causes two entry reactions to be executed. Upon entering superstate R2, the timer action function TMR1_set is initialized to count down 50 system ticks. At the same time this occurs, the default substate b1 is activated and its entry reaction LED1_ON is also executed.

After 50 ticks, TMR1_set times out and the event T_BLINK is sent. This causes two transitions to fire. First the internal reaction of R2 is triggered resulting in TMR1_set again beginning a 50-tick countdown. Second, T_BLINK triggers the transition from b1 to b2 and the exit reaction, LED1_OFF(), is executed. After the next 50 ticks, T_BLINK again causes a transition from b2 to b1, and the entry reaction LED1_ON is executed. Thus, LED1 blinks with a period of 50 system tick units.

TIP: You can find more detailed information about entry and exit reactions and internal reactions in visualSTATE Reference Guide.

R1

R2T_BLINK() / TMR1_set(T_BLINK, 50)Entry / TMR1_set(T_BLINK, 50)

b1Entry / LED1_ON()Exit / LED1_OFF()

.b2

.

/

BTN_MID_DOWN() /LED2_ON()

BTN_RIGHT_DOWN() /LED2_OFF()

/

T_BLINK() /T_BLINK() /

Internal reaction

Entry reactions

Exit reaction

88

History states


History statesFigure D.4 shows an example of the use of history state.

Figure D.4: Example of use of history state

In this example, state S1 encloses substates S1_1, S1_2, S1_3. When S1 is entered, the system will be in S1_3 because the history state acts as the initial state the first time its superstate is activated. However, the next time S1 is entered, the last state that was active will be remembered and applied as the current state.

For instance, if state S1_2 is active and Leave_S1 occurs, the current state combination changes from S1 to InitialState. Then, when Enter_S1 occurs, the state changes back to S1, where S1_2 will again be the current state. A history state remembers states entered at its own superstate level. A deep history state remembers states entered at levels below the superstate level of the history state.

InitialState

S1

H*

S1_1

S1_3

S1_2

/

Enter_S1() /

Leave_S1() /

/

Event1() /[Internal_Variable = 1]

Event3() /Event2() /Action4()

Index

89

Aabbreviations in this guide . . . . . . . . . . . . . . . . . . . . . . . . . 12action functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43action functions, adding . . . . . . . . . . . . . . . . . . . . . . . . . . . 42action vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 19, 58actions generated by events, viewing . . . . . . . . . . . . . . . . . 45Actions_to_Outputs.c file example . . . . . . . . . . . . . . . . . . 71actions, conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16activating Coder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55activating Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29activating Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23activating Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45activating Verificator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48adding action functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 42adding events to transitions . . . . . . . . . . . . . . . . . . . . . 36, 38adding explanations . . . . . . . . . . . . . . . . . . . . . . . . . . . 37, 40adding states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32adding transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Adobe Acrobat Reader. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19ANSI C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 83ANSI C compliant compilers . . . . . . . . . . . . . . . . . . . . . . . 78API. See visualSTATE APIapplication prototyping, GUIs . . . . . . . . . . . . . . . . . . . . . . 63applications, completing . . . . . . . . . . . . . . . . . . . . . . . . . . 57applications, embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . 16arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 83asynchronous events, handling. . . . . . . . . . . . . . . . . . . . . . 78

Bblue borders, Graphical Animation . . . . . . . . . . . . . . . . . . 47Boolean conditions, guarding transitions. . . . . . . . . . . . . . 86Boolean equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82buttons

New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Ccalling visualSTATE Systems . . . . . . . . . . . . . . . . . . . . . . 53changing Coder-generated files . . . . . . . . . . . . . . . . . . 57, 77changing control logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81changing states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53changing System, to reset state . . . . . . . . . . . . . . . . . . . . . 53checking event queues . . . . . . . . . . . . . . . . . . . . . . . . . 52–53clearing flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58, 72

elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55table-based. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82–83user-written . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

code examplesActions_to_Outputs.c . . . . . . . . . . . . . . . . . . . . . . . . . . 71event handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53main.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67simpleEventHandler.c . . . . . . . . . . . . . . . . . . . . . . . . . . 73visualSTATE API code . . . . . . . . . . . . . . . . . . . . . . . . . 53

Code generate and verify option . . . . . . . . . . . . . . . . . . . . 48code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55code generation statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 55code running in different tasks . . . . . . . . . . . . . . . . . . . . . . 77Coder-generated files

location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55modifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57, 77names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55specifying location . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Coder, activating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55completing visualSTATE applications . . . . . . . . . . . . . . . . 57composing states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34composing transitions . . . . . . . . . . . . . . . . . . . . . . . . . 36–38concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19constant data table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84constant data table, interpretation . . . . . . . . . . . . . . . . . . . 84control logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15–16, 81

changing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81table-driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Index


control logic code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81control logic engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51controlling run-time behavior in target applications . . . . . 48conventions in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . 12conversion of actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16counters, incrementing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77creating action functions . . . . . . . . . . . . . . . . . . . . . . . . . . 40creating events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 38–39creating GUI applications, prototyping . . . . . . . . . . . . . . . 63creating Navigator workspace . . . . . . . . . . . . . . . . . . . . . . 24creating statechart diagrams. . . . . . . . . . . . . . . . . . . . . . . . 32creating states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32creating transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34current state vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Ddebugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45defining action functions . . . . . . . . . . . . . . . . . . . . . . . . . . 40defining events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 39defining transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Designer

Diagram toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32File menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43launching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Project browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Simulation Mode window . . . . . . . . . . . . . . . . . . . . . . . 47Statechart diagram window. . . . . . . . . . . . . . . . . . . . . . 31

designing statechart diagrams . . . . . . . . . . . . . . . . . . . . . . 32device drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15–16, 58device drivers, output part . . . . . . . . . . . . . . . . . . . . . . . . . 16Diagram toolbar, Designer . . . . . . . . . . . . . . . . . . . . . . . . . 32directory structure for VS application files . . . . . . . . . . . . 57documentation reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

including sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

documentation, visualSTATE. . . . . . . . . . . . . . . . . . . . 18–19documenting visualSTATE Projects. . . . . . . . . . . . . . . . . . 61drawing states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32–33

drawing transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34–35

Eediting Coder-generated files . . . . . . . . . . . . . . . . . . . . 57, 77elements contained in generated code . . . . . . . . . . . . . . . . 55elements, global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 20elements, local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18embedded applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81embedded applications based on visualSTATE . . . . . . . . . 16embedded systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16entry and exit reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 87entry reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82errors, verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49event handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 54event handling code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53event handling queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54event handling, sequential . . . . . . . . . . . . . . . . . . . . . . . . . 51event names, storing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51event processing, sequential . . . . . . . . . . . . . . . . . . . . . . . . 51event queue handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55event queues . . . . . . . . . . . . . . . . . . . . . . . . . . . 54–55, 77–78event queues, checking. . . . . . . . . . . . . . . . . . . . . . . . . 52–53events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 43, 58

adding to transitions . . . . . . . . . . . . . . . . . . . . . . . . 36, 38asynchronous. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78creating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39finding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53forwarding to visualSTATE for processing . . . . . . . . . . 77generating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77triggering transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

event-driven systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16event-generated actions, viewing . . . . . . . . . . . . . . . . . . . . 45exit reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Expert API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77explanations, adding. . . . . . . . . . . . . . . . . . . . . . . . . . . 37, 40expressing transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Index

91

extensionsnwp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17vsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17vsr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 20vws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

external devices, inputs from . . . . . . . . . . . . . . . . . . . . . . . 16external environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16external stimuli, predicting. . . . . . . . . . . . . . . . . . . . . . . . . 81externally generated inputs, processing . . . . . . . . . . . . . . . 16

FFIFO queue handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51FIFO Queue Handling C Code routines. . . . . . . . . . . . . . . 51file examples

Actions_to_Outputs.c . . . . . . . . . . . . . . . . . . . . . . . . . . 71event handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Inputs_to_Events.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72main.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67simpleEventHandler.c . . . . . . . . . . . . . . . . . . . . . . . . . . 73visualSTATE API code . . . . . . . . . . . . . . . . . . . . . . . . . 53

finding events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53finite state machines, sequential. . . . . . . . . . . . . . . . . . . . . 16flags

clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Ggenerated code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55modifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57, 77

generated documentation reportslocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

generated fileslocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

generating code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55generating events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

global elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 20Graphical Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

blue borders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47red borders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

graphical prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63guarded transitions, by Boolean conditions . . . . . . . . . . . . 86

Hhandling asynchronous events . . . . . . . . . . . . . . . . . . . . . . 78handling events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 54handling multiple visualSTATE Systems. . . . . . . . . . . . . . 77hardware inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58hardware outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58header files in user-written code . . . . . . . . . . . . . . . . . . . . 59hexadecimal arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83hierarchical representation . . . . . . . . . . . . . . . . . . . . . . . . . 17hierarchical state machines . . . . . . . . . . . . . . . . . . . . . . . . 19hierarchy of states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19hierarchy, visualSTATE . . . . . . . . . . . . . . . . . . . . . . . . 17–18history state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

IIF...ELSE statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81implementation approaches, compared . . . . . . . . . . . . . . . 81implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16implementing visualSTATE applications . . . . . . . . . . . . . . 51including sections in documentation report . . . . . . . . . . . . 61incrementing counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77initial states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40, 45initializing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46inputs from external devices . . . . . . . . . . . . . . . . . . . . . . . 16inputs (externally generated), processing. . . . . . . . . . . . . . 16inputs (hardware) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Inputs_to_Events.c file example . . . . . . . . . . . . . . . . . . . . 72installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23internal reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87interpretation of constant data table . . . . . . . . . . . . . . . . . . 84interrupt service routines . . . . . . . . . . . . . . . . . . . . . . . . . . 77


interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77ISRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Llaunching Coder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55launching Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29launching Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23launching Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45launching Verificator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48learning curve for UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 78learning curve for visualSTATE. . . . . . . . . . . . . . . . . . . . . 78LED application example. . . . . . . . . . . . . . . . . . . . . . . . . . 66local elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18locations

Coder-generated files . . . . . . . . . . . . . . . . . . . . . . . 26, 55generated documentation reports . . . . . . . . . . . . . . . . . 63

logical rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82–83

Mmain loop routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58main.c file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Mealy notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19modifying Coder-generated files . . . . . . . . . . . . . . . . . 57, 77monitoring run-time behavior in target applications . . . . . 48Moore notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Nname of visualSTATE reset event . . . . . . . . . . . . . . . . . . . 53named states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34names of generated files. . . . . . . . . . . . . . . . . . . . . . . . . . . 55naming states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33–34Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

launching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 20workspace, creating. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

New button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38next state vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

notations in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12notations, state machines . . . . . . . . . . . . . . . . . . . . . . . . . . 19nwp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Ooptions

Code generate and verify . . . . . . . . . . . . . . . . . . . . . . . 48output part of device drivers. . . . . . . . . . . . . . . . . . . . . . . . 16outputs (hardware) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58overview of visualSTATE application . . . . . . . . . . . . . . . . 65

Pparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78PDF reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19platform-independence. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81pointers to functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 81predicting external stimuli . . . . . . . . . . . . . . . . . . . . . . . . . 81preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77processing events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54processing externally generated inputs . . . . . . . . . . . . . . . 16Project browser, Designer . . . . . . . . . . . . . . . . . . . . . . . . . 29Project data. See visualSTATE Project dataProjects. See visualSTATE Projectsprototype example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63, 78prototyping, GUI applications . . . . . . . . . . . . . . . . . . . . . . 63

Qqueue handler code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51queue handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51queues of events . . . . . . . . . . . . . . . . . . . . . . . . 54–55, 77–78queues of events, checking. . . . . . . . . . . . . . . . . . . . . . 52–53queues, event handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Index

93

Rreactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87reactions, internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87reading documentation reports. . . . . . . . . . . . . . . . . . . . . . 63RealLink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48real-time operating system . . . . . . . . . . . . . . . . . . . . . . . . . 77red borders, Graphical Animation . . . . . . . . . . . . . . . . . . . 47reports, Documenter-generated . . . . . . . . . . . . . . . . . . . . . 61

location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63reset event, default name . . . . . . . . . . . . . . . . . . . . . . . . . . 53reset state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53resetting simulation session . . . . . . . . . . . . . . . . . . . . . . . . 46results of verification, viewing. . . . . . . . . . . . . . . . . . . . . . 48Rich Text Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63rtf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77run-time behavior in target applications, controlling . . . . . 48run-time behavior in target applications, monitoring. . . . . 48

Ssections in documentation report, including . . . . . . . . . . . 61sending events to visualSTATE . . . . . . . . . . . . . . . . . . . . . 77sequential event processing . . . . . . . . . . . . . . . . . . . . . . . . 51sequential finite state machines . . . . . . . . . . . . . . . . . . . . . 16sequential processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54session, visualSTATE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17setting flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77SE_RESET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53short forms in this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . 12simpleEventHandler.c file example . . . . . . . . . . . . . . . . . . 73simulation session, resetting . . . . . . . . . . . . . . . . . . . . . . . 46source code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65starting Coder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55starting Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29starting Navigator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23starting Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45starting Verificator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48state combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

state combinations, viewing . . . . . . . . . . . . . . . . . . . . . . . . 45state hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19state machine models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16state machine notations . . . . . . . . . . . . . . . . . . . . . . . . . . . 19state machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

hierarchical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19translating into table-based code. . . . . . . . . . . . . . . . . . 82

state machine-based control logic . . . . . . . . . . . . . . . . . . . 16state reactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87state reactions, internal. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87state vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83statechart descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Statechart Diagram windows . . . . . . . . . . . . . . . . . . . . 30–31statechart diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 43statechart diagrams, creating . . . . . . . . . . . . . . . . . . . . . . . 32Statechart files. See visualSTATE Statechart filesstates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

changing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53composing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32–33names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33–34with blue borders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47with red borders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

stimuli, predicting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81storing event names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51styles in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Switch/Case statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 81syntax, for transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Systems. See visualSTATE Systems

Ttable of constant data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84table of constant data, interpretation . . . . . . . . . . . . . . . . . 84table-based code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82–83table-driven control logic . . . . . . . . . . . . . . . . . . . . . . . . . . 81table-driven pointers to functions. . . . . . . . . . . . . . . . . . . . 81target applications, controlling. . . . . . . . . . . . . . . . . . . . . . 48target applications, monitoring. . . . . . . . . . . . . . . . . . . . . . 48


target-specific code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77tasks, control logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77terminology, visualSTATE . . . . . . . . . . . . . . . . . . . . . . . . . 20testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48topstates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 30transition guarded by Boolean condition . . . . . . . . . . . . . . 86transition syntax, visualSTATE . . . . . . . . . . . . . . . . . . . . . 83transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

adding events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 38composing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37–38drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34–35expressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83guarded by Boolean conditions. . . . . . . . . . . . . . . . . . . 86triggered by external events . . . . . . . . . . . . . . . . . . . . . 85

transitions triggered by external events . . . . . . . . . . . . . . . 85translating state machines into table-based code . . . . . . . . 82translation of hardware inputs . . . . . . . . . . . . . . . . . . . . . . 58typing explanations . . . . . . . . . . . . . . . . . . . . . . . . . . . 37, 40

UUML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19UML notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . . 19user documentation, visualSTATE . . . . . . . . . . . . . . . . 18–19user-written code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58user-written code, header files . . . . . . . . . . . . . . . . . . . . . . 59

Vvalidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Validator RealLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Validator windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Validator workspace file. . . . . . . . . . . . . . . . . . . . . . . . . . . 21Validator, activating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48verification errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49verification results, viewing . . . . . . . . . . . . . . . . . . . . . . . . 48

verification warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Verificator, activating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Verify warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48viewing documentation reports . . . . . . . . . . . . . . . . . . . . . 63viewing verification results . . . . . . . . . . . . . . . . . . . . . . . . 48visual descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82–83visualSTATE API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

code example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53visualSTATE applications . . . . . . . . . . . . . . . . . . . . . . . . . 57

completing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57implementing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65running on PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

visualSTATE Coder. See CodervisualSTATE control logic code. . . . . . . . . . . . . . . . . . . . . 81visualSTATE Designer. See DesignervisualSTATE engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16visualSTATE Expert API. See Expert APIvisualSTATE hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 17–18visualSTATE Navigator. See NavigatorvisualSTATE Project data. . . . . . . . . . . . . . . . . . . . . . . . . . 20visualSTATE Project examples . . . . . . . . . . . . . . . . . . . . . 23visualSTATE Project files . . . . . . . . . . . . . . . . . . . . . . . . . 20visualSTATE Projects. . . . . . . . . . . . . . . . . . . . . . . . . . 17, 20

documenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61visualSTATE session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17visualSTATE Statechart files . . . . . . . . . . . . . . . . . . . . 17, 20visualSTATE Systems . . . . . . . . . . . . . . . . . . . . . . . . . 17, 20

calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77initial state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45initializing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

visualSTATE terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20visualSTATE transition syntax . . . . . . . . . . . . . . . . . . . . . . 83visualSTATE user documentation . . . . . . . . . . . . . . . . 18–19visualSTATE Validator. See ValidatorvisualSTATE Verificator. See VerificatorVS application files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Index

95

vsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 20vsr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 20vws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Wwarnings

verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48–49windows

Designer Simulation Mode . . . . . . . . . . . . . . . . . . . . . . 47Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

workarounds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77workspace. See Navigator workspace

Documents

visualSTATE®ftp.indes.com/pub/mirrors/ftp.iar.se/€¦ · This guide is intended as a step-by-step tutorial on how you get started using the visualSTATE software. It is intended