Use Embedded Coder™ Support Package for ARM® Cortex®-R Processors to verify and validate code using PIL and external mode. The hardware used in this example is the Texas Instruments™ Hercules RM57Lx LaunchPad.
In this example, you configure a Simulink model to run processor-in-the-loop (PIL) and external mode simulations. In this PIL simulation example, the generated code runs on a TI RM57L843 Microcontroller, which has an ARM® Cortex-R5F based CPU. The results of the PIL simulation are transferred to Simulink to verify the numerical equivalence of the simulation and the code generation results. The PIL verification process is a crucial part of the design cycle to ensure that the behavior of the deployment code matches the design.
You can use the Simulink external mode feature to accelerate calibration by changing certain parameter values while the model is still running on the hardware board. When you change parameter values from within Simulink, the modified parameter values are communicated to the target hardware immediately. To monitor the parameter tuning effects, you can view the algorithm signals on scopes or displays in Simulink, or using the Simulation Data Inspector.
This example introduces the Simulink code generation and verification workflow by showing you how to:
Configure a Simulink model to run PIL simulations on the TI Hercules RM57Lx LaunchPad
Configure a Simulink model to run external mode simulations on the TI Hercules RM57Lx LaunchPad
Complete the Getting Started with Embedded Coder Support Package for ARM Cortex-R Processors example.
You should connect the Hercules RM57Lx LaunchPad to the host.
This example shows you how to use the automatically generated PIL block for verification. With this approach:
You can verify code generated for subsystems.
You must provide a test harness model to supply test vector or stimulus inputs.
You must swap your original subsystem with an automatically generated PIL block. To avoid losing your original subsystem, do not save your model in this state.
1. Open the PIL Block model. This model is configured to run on the TI Hercules RM57Lx LaunchPad hardware board, and uses the TI ARM Code Generation Tools | gmake toolchain. The objective here is to create a PIL block out of the Controller subsystem, and simulate the model with the algorithm for the Controller subsystem running on the RM57Lx Microcontroller.
2. Configure the model to create PIL block by following the steps shown.
3. Create a PIL block for the Controller subsystem by following these steps.
4. Run the PIL simulation.
5. After you start simulating the model, a cross-compiled executable containing the generated code from the subsystem is deployed to the hardware. The PIL block communicates with the deployed executable and relays signal and state information to Simulink at every time step. Execution is not in real time.
You can switch between the original and PIL block subsystems by double-clicking the Manual Switch block. Open the Numerical Differences block to see the difference between the simulated Controller subsystem and the PIL block running on the Hercules RM57Lx LaunchPad.
This example shows you how to verify the automatically generated code for a referenced model by running a PIL simulation. With this approach:
You can verify code generated for referenced models.
You must provide a test harness model to provide test vector or stimulus inputs.
You can easily switch a Model block between normal and PIL simulation mode.
1. Open the Model Block PIL model. This model is configured to run on the TI Hercules RM57Lx LaunchPad hardware board and uses the TI ARM Code Generation Tools | gmake toolchain.
The model contains two Model blocks that both point to the same referenced model. In this task, you configure one Model block to run in PIL simulation mode and the other in normal mode.
2. Configure and run the CounterA Model block in PIL simulation mode by following these steps.
3. When the model starts running, Scope1 displays the PIL simulation output running on the RM57Lx microcontroller, and Scope2 shows the normal mode simulation output.
This example shows you how to verify the automatically generated code for a top model by running a PIL simulation. With this approach:
You can verify code generated for a top model.
You must configure the model to load test vectors or stimulus inputs from the MATLAB workspace.
You can easily switch the entire model between normal and PIL simulation mode.
1. Open the Top Model PIL model. This model is configured to run on the TI Hercules RM57Lx LaunchPad hardware board, and uses the TI ARM Code Generation Tools | gmake toolchain.
2. Run the entire model in PIL simulation mode by following these steps.
3. When the PIL simulation is completed, a logsOut variable is created in the base workspace. The logsOut data contains PIL simulation results. You can access the logged data for signals count_a and count_b using the following commands:
count_a = get(logsOut,'count_a'); count_a.Values.Data count_b = get(logsOut,'count_b'); count_b.Values.Data
In this task, you run a Simulink model in external simulation mode. When you are prototyping and developing an algorithm, it is useful to monitor and tune the algorithm while it runs on hardware. The external mode feature in Simulink enables this capability.
1. Open the External Mode model. This model is configured to run on the TI Hercules RM57Lx LaunchPad hardware board, and uses the TI ARM Code Generation Tools | gmake toolchain.
2. Select the signals that you want to instrument. It is recommended that you instrument signals by streaming them to the Simulation Data Inspector rather than by using Scope blocks, because:
Streaming does not store data in memory, and therefore makes more efficient use of the memory available on the hardware. Scope blocks store data in buffers before sending the data to the host.
You can stream signals from top models and reference models simultaneously. Scope blocks can only log signals from a top-level model.
Note: Data streamed to the Simulation Data Inspector is unaffected by external mode triggers. As a result, external mode parameters such as Duration (ExtModeTrigDuration) and Delay (ExtModeTrigDelay) will have no effect on the data from signals being streamed to the Simulation Data Inspector. For more information, see
Upload Target Program Signal Data to Host.
3. Start external mode simulation.
In this step, the simulation stop time is set to
inf to run the simulation until you explicitly pause or stop the model.
Wait for the model to finish getting built and downloaded onto the hardware. Once this is done, the executable starts running automatically on the RM57Lx microcontroller.
Open the Manual Switch block while simulation is running to change the input source. Open the Gain block to change the signal gain. Finally, open the Scope block to view the external mode simulation results. Note that the entire model is running on the emulator.
If a signal had been selected for streaming to the Simulation Data Inspector, a new simulation run appears in the Runs pane of the Simulation Data Inspector. During simulation, the Simulation Data Inspector button appears highlighted to indicate that new simulation output is available in the Simulation Data Inspector.
4. Stop external mode simulation.
Note: At any point during the external mode simulation, you can open the External Mode Control Panel in order to perform tasks such as connecting or disconnecting from a running target, by using following steps:
This example introduced the workflow for code verification using target connectivity features PIL and external mode.