Simulink2ARM7
Contents
Overview
This page describes the user interaction with the SimulinkTarget tool. Every step needed in order to get from Simulink Model to the Executable file is described in this page. The first step before getting the model to run in the ARM7 Board is to generate the code that implements the Simulink Model. This process is described here Simulink settings for generating code.
Create (or load) a project configuration file
The SimulinkTarget tool creates a configuration file where all the decisions made during the conversion process are saved. Doing so enables the user to load the configuration file and avoids the overhead of going through all of the steps every time new code is generated. The first step is to either load or create a configuration file.
After loading/creating a configuration file, new tabs are enabled and the user may proceed to the next steps.
As the user can easily note, the tab Simulink Model has been enabled and is intuitively the next step to be taken.
Load the simulink model
The tool needs to load a Simulink Model in order to obtain model specific information, such as port names, model name, etc. After parsing the model necessary information is collected and the tool can go further. The first image shows the select model screen.
The user then selects the MDL file that contains the model that will be executed on the ARM7 platform.
Once again after completing the required steps inside the tab, new tabs are enabled and the user can continue to enter information required to achieve the final executable file.
Load the RTW generated code
In order to complete this step, the user must first execute the Simulink settings for generating code and generate code with the Matlab Simulink Real-Time Workshop.
After the folder containing the RTW generated code is specified, the tool will merge the model code together with the base system code. The base system code is selected in the next step.
Select the base stub code used
The stub code contains both the base system functionality and the main system loop. The main system loop is responsible for the execution of the model. The main loop execution is described in Simulink Execution on the ARM7 target.
The screenshot above presents the user two options. One of them is to use the code provided with the SimulinkTarget tool. In this case the code used is related to a specific SVN release and will contain a version number. The user must be sure to use compatible combinations of software, that is, bootloader version should be the same as the stub code used with the SimulinkTarget.
In case the user has a copy of a newer code that either does not match the version provided by the tool or that is not yet a release, it is possible to select the second option. If this option is chosen, the user must provide the address of the folder containing the stub code.
After selecting one of the two options two tabs are enabled. The user can thereafter walk through the final steps in the process of setting up the configuration for generating a binary executable. The figure below differs from the above regarding the status of the configuration file. After clicking the Save button the tool removes the asterisks from the tittle bar.
The base stub code provided by the tool or the user will be used together with the RTW generated code to compose the final source code, which will then be compiled into an application loaded by the ARM7 board bootloader.
Define CAN binding and marshaling
This part of the work flow defines the CAN port binding. Since in the Concept Car there is a CAN bus responsible for supplying a communication means to all of the boards in the network, all data is transmitted through it. When modeling functionality in a Simulink Data-Flow model, there is only reference to IN ports and OUT ports. The model does not describe how data is input and output to the ports. They are an open link to the environment where the model executes.
For this reason the user must provide a binding of the ports from the model to the Car's communication mechanism, which is a CAN bus. This is done by assigning CAN ids to can messages that will carry the data to and from the model (more specifically, to/from the model ports).
The user is able to define an ID, which will be automatically converted to a Hexadecimal value by the tool. A gradient, which is used to transform the value that the message carries (e.g. to transform a floating point number into an integer number). And a y-intersect parameter used to determine a scaling factor for the message value. These three fields are user configurable and the last two are optional. The optional fields are enabled by the checkboxes.
