The example is prepared for three different build configurations. On if these is pre-compiled and can be downloaded and run immediately; see First Test. For further exploration of the example you will need to know a bit more of it's composition and it is the purpose of this section to provide you with this information. The three build configurations are defined in EWARM but also need appropriate code generation settings in visualSTATE. They are:
DEBUG_RAM_REALLINK (the precompiled variant)DEBUG_FLASH_REALLINKDEBUG_RAM_CSPYLINKThe two REALLINK configurations are basically identical and differ only in the way how code is placed and run in the Target by EWARM; see Build for RealLink. These configurations are based on traditional Table Based code generation by visualSTATE and employ the serial RealLink protocol to allow In-Target debug of the StateChart with visuaSTATE Analyzer.
The CSPYLINK configuration employs the new visualSTATE capability to generate Human Readable code. It also uses the CSpyLink plugin of EWARM to allow direct StateChart debugging from within the C-Spy debugger environment of EWARM using the JTAG connection through J-Link. See Build for CSpyLink for more details.
All configurations use exactly the same StateChart and thus the modelled 'User Interface' functionality of the board is entirely identical in all cases. All configurations also use the new Build Integration feature of EWARM and visualSTATE. The EWARM project file does NOT explicitly include the visualSTATE coder output files but rather only the relevant visualSTATE project file. In the current case the EWARM project contains JoyStick.vsp. This is the vS Project file containing one system with a single TopState that is contained in statechart file JoyStick.vsr. The visualSTATE Navigator keep things together in a WorkSpace file called demo_at91sam7x.vnw. The file structure of visualSTATE is explained in it's ReferenceGuide.pdf.
The implementation of this demo is structured in a way that is similar, but not identical, to the one proposed in the visualSTATE Project Setup Guide. There are three subdirectories in the project root directory:
doc contains the documentation you are now reading
vs contains the visualSTATE (vS) project files. Prime entity is the Navigator workspace file demo_at91sam7x.vnw. Two subdirectories of vs are coder and doc containing the output from the visualSTATE Coder and visualSTATE Documenter respectively. The distribution contains pre-built Coder and Documenter outputs that are intended for the Debug_RAM_RealLink configuration of EWARM. The documenter output was configured to use HTML format and you can read this here (you may need to use browser IE to see the included EMF images).
ew contains the IAR Embedded Workbench for ARM (EWARM) project. Prime entity is the demo_at91sam7x.eww file which is the IDE Workspace file for EWARM. In addition ew contains several subdirectories:
at91 contains a complete copy of the Atmel AT91 headers and library of in-line functions for the AT91SAM7X256 processor, together with associated HTML documentation.
vsapi contains example code for an event queue.
board contains files for BoardSupport and DCC channel support (see furtheron)
output contains three other subdirectories; one for each of three different build-configurations. Each of these has again three subdirectries for Obj, List and Exe where the latter hold the final linker output file (ELF format). In the initial prebuilt situation only the output files for the Debug_RAM_RealLink configuration are actually present.
config contains linker configuration files and macro files used for download to the target. Two variants of each are present to support download to RAM or download to FLASH.
settings is for use by EWARM .
application contains the main application code providing a main() function that initializes BoardSupport and then calls the visualSTATE event processor..
The Board Support Package (BSP) in this example is based on the Atmel AT91 library. In order to obtain a desirable level of 'information hiding', the .\ew\board\BoardSupport.C file and associated header are set up such that the main code does not need to 'see' anything of the AT91 library. The main code can call various initialisation routines in the BSP (e.g. for the Timer and UART interrupts) passing pointers to CallBack routines in main code to actually handle these interrups in a more abstracted way.
The main code in .\ew\application\main.c makes use of various C preprocessor #defines to accomodate the differences that arise from different ways of visualSTATE code generation. These #defines are placed in the Project Options (Category C/C++ Compiler, tab Preprocessor) of each Build Configuration.
The Build Configuration for CSpyLink (and only this one) includes the file .\ew\board\DCC_Process.C in the build. It will be called in main code when NOT building for RealLink as specified by a #define. The DCC routines are taken form the EWARM 5.11 distribution under the ARM\src\debugger\DCC subdirectory and are originally by Segger, the manufacturer of the IAR J-Link. Documentation can be found in the EWARM 5.11 distribution under ARM\doc\JLinkARM.pdf, section 4.7 (Using DCC for memory access). DCC stands for Direct Communication Channel and is a feature of certain ARM based processors that allows data exchange over the JTAG link without involving the CPU. It is used by EWARM for the Live Watch feature and in our demo application C-Spy can make use of it to observe details of the In-Target StateChart without the need to frequently stopping the CPU. Please note that the optional DCC_HandleDataAbort.s assembler file (providing additional robustness to DCC) is NOT bound in in the current example.