Build with RealLink

In order to do a new build of the application for RealLink we will check the Coder options of visualSTATE, then check the Build Configuration in EWARM and then generate code and compile from within EWARM. Before continuing, please ensure that EWARM has opened the example project, is in normal Edit mode and that either the build configuartion for Debug_RAM_RealLink or Debug_Flash_RealLink is selected. For the purpose of this discussion we assume that we are going to use Debug_RAM_RealLink. In order to have a fresh start we are going to clean up all existing intermediate and output files. Do this by using Project->Clean. Note that due to the Build Integration also files are deleted that were previously generated by the visualSTATE coder. You can check this by looking in the .\vs\coder directory (with Windows Explorer or any other File Manager) which should now be empty (make it empty if not).

The two RealLink configurations of Embedded Workbench for the example (Debug_RAM_RealLink and Debug_Flash_RealLink) are basically identical and differ only in the way how code is placed and run in/on the Target by EWARM. If you would check the Project Options for both these configurations you would see different linker configuration files under Project->Options->Linker->Config, different startup macro files under Project->Options->Debugger->Setup and that only the FLASH variant on Project->Options->Debugger->Download has option 'Use Flash Loaders' checked. Furthermore, the RAM varant has 'Run to main' checked in the Project->Options->Debugger->Setup whereas the FLASH variant has not to preserve the limited hardware breakpoints in FLASH. Essential for both RealLink based configuartions in Embedded Workbech is that in Project->Options->C/C++ Compiler->Preprocessor two global defines are put in place; VS_IS_EXPERT=0 and VS_REALLINKMODE=1. This has been prepared, but you should check for it; see the following screendump.

EWARM Defines for RealLink based Build Configurations

Now start the visualSTATE Navigator and open the example workspace (if not yet done). Select Project->Options->Code Generation (Alt+F9) to open the Coder Options dialog window. On the left side ensure that the uppermost Project level is selected (JoyStick) and on the right side select the Configuration tab. Make changes as necessary to obtain RealLink mode = Table-based. Then, at the left side, select the LedControl_System, and at the right side select the tab API Functions and UNcheck Use prefix for API. Also Do check Enable SEM_Inquiry and SEM_GetInput. The latter will allow RealLink to establish what events are active in any state. These settings are already made when you have not yet altered anything in the example project.

Clik OK to close the Coder Options dialog and do File->Save Workspace (Ctrl+S) to save the settings in the Navigator Workspace. It is now possible to generate new code from within the Navigator, but we will do that from within EWARM.

Going back to Embedded Workbench, right-click the JoysStick.vsp item in the Workspace tree-view and select Compile. This will invoke the visualSTATE Coder.

The generated files can be seen in the Worspace tree-view under the 'Output' of JoysStick.vsp. The screendump below illustrates this with the file LedControl_System.c opened to show the 'non-readable' Table Based code representing the model.

You can now select Project->Make (F7) and the example will be build, leading to an executable ELF output file (Start_AT91SAM7X256.out).

You can now download the application to the Target board and start it in the same way as illustrated in First Test, then try out the RealLink features as explained in Using RealLink. You may also try your hand at builing the application for Debug_FLASH_RealLink, which is pretty much identical to the proces above with the sole difference that you need to use the appropriate Build Configuration of Embedded Workbench.