|
|
|
| R2012a Documentation → Embedded Coder | |
Learn more about Embedded Coder |
|
| Contents | Index |
The Embedded Coder software lets you use Simulink Coder software to generate a C language real-time implementation of your Simulink model. You can compile, link, download, and execute the generated code on the C6713 DSP Starter Kit (DSK). The Embedded Coder is ideal for rapid prototyping and developing embedded systems applications for C6713 digital signal processors. The Embedded Coder focuses on developing real-time digital signal processing (DSP) applications for C6000 hardware. Additional hardware that we support is listed in Hardware Issues.
Although the tutorials in this chapter focus on the C6713 DSK, the techniques and processes apply to any supported hardware, with minor adjustments for the processor involved.
This chapter describes how to use the Embedded Coder to create and execute applications on Texas Instruments C6000 development boards. To use the targeting software, you should be familiar with using Simulink software to create models and with the basic concepts of Simulink Coder software automatic code generation. To read more about Simulink Coder software, refer to your Simulink Coder documentation.
In most cases, this chapter deals with the C6713 DSK targets. Fortunately, all members of the C6000 family of processors that we support work in a manner similar to the C6713 DSK. While you review the contents of this chapter, and follow the tutorials, recall that the concepts and techniques or development processes apply, with a few adjustments, to all supported C6000 processors and boards.
Later sections discuss the Embedded Coder software and targeting custom hardware.
Texas Instruments (TI) markets a complete set of software tools to use when you develop applications for your C6000 hardware boards. This section provides a brief example of how Embedded Coder software uses Code Composer Studio (CCS) Integrated Development Environment (IDE) with the Simulink Coder software and the c6000lib blockset.
Executing code generated from Simulink Coder software on a particular target in real time requires that Simulink Coder software generate target code that is tailored to the specific hardware target. Target-specific code includes I/O device drivers and an interrupt service routine (ISR). Since these device drivers and ISRs are specific to particular hardware targets, you must check that the target-specific components are compatible with the target hardware.
To allow you to build an executable, TI C6000 uses the MATLAB links in Embedded Coder software to invoke the code building process within the CCSv3 IDE. After you download your executable to your target and run it, the code runs wholly on the target; you can access the running process only from the CCS IDE debugging tools. Otherwise the running process is not accessible.
Used in combination with your Embedded Coder and Simulink Coder software, TI products provide an integrated development environment that, once installed, needs no additional coding.
The CCS IDE offers simulators for the C6000 processors in the CCS IDE Setup utility. Much of your model and algorithm development efforts work with the simulators, such as code generation. And, since the Embedded Coder provides a software-based scheduler, your models and generated code run on the simulators just as they do on your hardware. For more information about the simulators in CCS IDE, refer to your CCS online help system.
When you set up a simulator, match the processor on your target exactly to simulate your target hardware. For example, to target a C6713DSK board, your simulator must contain a C6713 processor, not just a C6xxx simulator. Simulators must match the target processor because the codecs on the board are not the same and the simulator needs to identify the codec. Choosing the accurate simulator for your hardware matches the memory maps and registers with your target processor.
To use a simulator. Open the Target Preferences block. On the Board pane, under IDE Support, use the Get from IDE button to get a list of simulators installed with your IDE. Then use Board Name to select one of the installed simulators.
In general, use the device cycle accurate simulators provided by CCS Setup to simulate your processor.
The following block diagram represents typical inputs and output for a C6713 DSK development board.
After installing a supported development board, start MATLAB software. At the command prompt, type c6000lib. This opens a Simulink blockset named c6000lib that includes libraries that contain blocks predefined for C6000 input and output devices.
The board-based block library for the C6713 DSK contains these blocks:
ADC block
DAC block
DIP Switch block (optional, refer to the reference page for the DIP Switch block for your target)
LED block
Reset block
Blocks from these libraries are associated with your boards and hardware. As required, add the devices to your model. If you choose not to include either an ADC or DAC block in your model (they are available in the target specific libraries), the Embedded Coder provides a timer that produces the interrupts required for timing and running your model, either on your hardware target or on a simulator.
In this tutorial you create and build a model that simulates audio reverberation applied to an input signal. Reverberation is similar to the echo effect you can hear when you shout across an open valley or canyon, or in a large empty room.
You can choose to create the Simulink model for this tutorial from blocks in DSP System Toolbox software and Simulink block libraries, or you can find the model in Embedded Coder demos. For this example, you see the model as it appears in the demonstration program. The demonstration model name is c6713dskafxr.mdl as shown in the next figure. Open this model by entering c6713dskafxr at the MATLAB prompt.
To run this model you need a microphone connected to the Mic In connector on your C6713 DSK, and speakers and an oscilloscope connected to the Line Out connector on your C6713 DSK. To test the model, speak into the microphone and listen to the output from the speakers. You can observe the output on the oscilloscope as well.
To download and run your model on your C6713 DSK, complete the following tasks:
Use Simulink blocks, DSP System Toolbox software blocks, and blocks from other blocksets to create your model application.
Add Embedded Coder blocks that let your signal sources and output devices communicate with your C6713 DSK—the C6713 DSK ADC and C6713 DSK DAC blocks that you find in Embedded Coder c6000lib blockset.
Add the Target Preferences block to your model. Verify and set the block parameters for your hardware. In most cases, the default settings work fine.
If you are using a C6713 simulator, use the Get from IDE button on the Board pane of the Target Preferences block. Then set Board Name under IDE Support to C6713 Device Cycle Accurate Simulator.
Set the Configuration Parameters for your model, including
Solver parameters such as simulation start and solver options
Software options such as target configuration and target compiler selection
Test your model running on the target by changing the input to the target and observing the output from the target processor.
Your target for this tutorial is your C6713 DSK installed on your PC. Be sure to configure and test your board as directed in Configuring Your C6713DSK in this guide before continuing this tutorial.
To build the model for audio reverberation, follow these steps:
Create a new model by selecting File > New > Model from the Simulink menu bar.
Use Simulink blocks and DSP System Toolbox software blocks to create the following model.
Look for the Delay block in the Signal Operations library of the DSP System Toolbox software. You do not need to add the input and output signal lines at this time. When you add the C6713 DSK blocks in the next section, you add the input and output to the sum blocks.
So that you can send signals to your C6713 DSK and get signals back from the board, Embedded Coder software includes a block library containing five blocks designed to work with the codec on your C6713 DSK:
Input block (C6713 DSK ADC)
Output block (C6713 DSK DAC)
Light emitting diode block (C6713 DSK LED)
Software reset block (Reset C6713 DSK)
DIP switch block (C6713 DSK DIP Switch)
Entering c6713dsklib at the MATLAB prompt opens the block library for the C6713 DSK. This block library is included in Embedded Coder c6000lib blockset in the Simulink Library browser.
The C6713 DSK ADC and C6713 DSK DAC blocks generate code that configures the codec on your C6713 DSK to accept input signals from the input connectors on the board, and send the model output to the output connector on the board. Essentially, the C6713 DSK ADC and C6713 DSK DAC blocks add driver software that controls the behavior of the codec for your model.
To add C6713 DSK target blocks to your model, follow these steps:
Double-click Embedded Coder software in the Simulink Library browser to open the c6000lib blockset.
Click the block library for the C6713 DSK to see the blocks available for your C6713 DSK.
Drag and drop C6713 DSK ADC and C6713 DSK DAC blocks to your model as shown in the figure.
Finally, add the Target Preferences block to the model. Notice that it is not connected to any other block in the model.
To configure Embedded Coder blocks in your model, follow these steps:
Set the following parameters for the block:
Clear the Stereo check box.
Select the +20 dB mic gain boost check box.
From the list, set Sample rate to 8000.
Set Codec data format to 16-bit linear.
For Output data type, select Double from the list.
Set Scaling to Normalize.
Set Source gain to 0.0.
Enter 64 for Samples per frame.
Include a signal path directly from the input to the output so you can display both the input signal and the modified output signal on the oscilloscope for comparison.
Now set the options for the C6713 DSK DAC block.
Set Codec data format to 16-bit linear.
Set Scaling to Normalize.
For DAC attenuation, enter 0.0.
Set Overflow mode to Saturate.
Verify that the settings in the Target Preferences block match the ones in the following figures.
Board Info
Memory
Sections
You have completed the model. Now configure the Simulink Coder software options to build and download your new model to your C6713 DSK.
The following sections describe how to build and run real-time digital signal processing models on your C6713 DSK. Running a model on the target starts with configuring and building your model from the Configuration Parameters dialog box in Simulink software.
Setting Simulink Configuration Parameters. After you have designed and implemented your digital signal processing model in Simulink software, complete the following steps to set the Configuration Parameters for the model:
Open the Configuration Parameters dialog box and set the right options on the Solver category for your model and for Embedded Coder software.
Set Start time to 0.0 and Stop time to inf (model runs without stopping). Generated code does not honor this setting if you set a stop time. Set this to inf for completeness.
Under Solver options, set Type to fixed-step and set Solver to discrete (no continuous states). For PIL, set Type and Solver to any setting.
For Fixed step size (fundamental sample time), enter Auto, and set Tasking mode for periodic sample times to SingleTasking.
Note Generated code does not honor Simulink stop time from the simulation. Stop time is interpreted as inf. To implement a stop in generated code, you must put a Stop Simulation block in your model. |
Ignore the Data Import/Export, Diagnostics, and Optimization panes in the Configuration Parameters dialog box. The default settings are right for your new model.
Setting Simulink Coder Target Build Options. Configure Simulink Coder software to generate and build code for the C6713 DSK:
Open the Configuration Parameters dialog box by entering Ctrl+E or by selecting the Simulation menu item and then Configuration Parameters.
Select the Code Generation pane.
Verify that the system target file is set to idelink_grt.tlc.
Expand the node for the Code Generation pane. Then select the IDE Link pane.
Among the Run-Time options, set Build action to Build_and_execute, and set Interrupt overrun notification method to Print_message.
Among the Vendor Tool Chain, keep the default settings.
Among the Code Generation options, clear Profile real-time execution.
Among the Link Automation options, verify that Export IDE link handle to base workspace is selected and that IDE link handle name has a name (e.g., IDE_Obj).
In the Configuration Parameters dialog box, select the Hardware Implementation pane.
When you have completed these steps, you have configured the Configuration Parameters for the C6713 DSK target. Some of the panes under the Code Generation pane, such as Comments and Symbols, do not require configuration. The default values for the options in these panes are already right for your new model. For other models, you may want to set the options in these panes to provide information during the build and to run TLC debugging when you generate code.
Building and Executing Your Model on Your C6713 DSK. After you set the Configuration Parameters and configure Simulink Coder software to create the files you need, you direct Simulink Coder software to build, download, and run your model executable on your target:
Change the category to Code Generation on the Configuration Parameters dialog box.
Clear Generate code only and click Build to generate and build an executable file targeted to your C6713 DSK.
When you click Build with Build_and_execute selected for Build action, the automatic build process creates an executable file that can be run by the C6713 DSP on your C6713 DSK, and then downloads the executable file to the target and runs the file.
To stop-model execution, click the Reset C6713 DSK block or use the Halt option in CCS IDE. You could type halt from the MATLAB command prompt as well.
Testing Your Audio Reverb Model. With your model running on your C6713 DSK, speak into the microphone you connected to the board. The model should generate a reverberation effect out of the speakers, delaying and echoing the words you speak into the mike. If you built the model yourself, rather than using the supplied model c6713dskafxr, try running the demonstration model to compare the results.
Code generated for periodic tasks, both single- and multitasking, runs out of the context of a timer interrupt. The generated code that represents model blocks for periodic tasks runs periodically, clocked by the periodic interrupt whose period is equal to the base sample time of the model. This description of scheduling and timing applies both to generated code operation that incorporates DSP/BIOS real-time operating system (RTOS) and basic code generation mode where DSP/BIOS RTOS is not included.
Note In timer-based models, the timer counts through one full base-sample-time before it creates an interrupt. When the model is finally executed, it is for time 0. |
This execution scheduling scheme is not flexible enough for some systems, such as control and communication systems that must respond to asynchronous events in real time. Such systems may need to handle a variety of hardware interrupts in an asynchronous, or aperiodic, fashion.
When you plan your project or algorithm, select your scheduling technique based on your application needs.
If your application processes hardware interrupts asynchronously, add the right asynchronous scheduling blocks from the Texas Instruments C6000 DSP/BIOS and Scheduling block libraries to your model. See DSP/BIOS (dspbioslib) and Scheduling
If your application does not service asynchronous interrupts, your model should include only the algorithm and device driver blocks that specify the periodic sample times. Generating code from a model like this automatically enables and manages a timer interrupt. The periodic timer interrupt clocks the entire model.
For code that runs synchronously in the context of the timer interrupt, each iteration of the model runs after an interrupt has been posted and serviced by an interrupt service routine (ISR). The code generated for Embedded Coder software uses Timer 1 in DSP/BIOS mode and bare-board mode. Timer 1 is configured so that the base rate sample time for the coded process corresponds to the interrupt rate. The Embedded Coder calculates and configures the timer period to produce the desired sample rate.
The minimum achievable base rate sample time depends on the algorithm complexity and the CPU clock speed. The maximum value depends on the maximum timer period value and the CPU clock speed.
If all the blocks in the model inherit their sample time value, and no sample time is defined explicitly, Simulink assigns a default sample time of 0.2 second.
Note In timer-based models, the timer counts through one full base-sample-time before it creates an interrupt. When the model is finally executed, it is for time 0. |
Embedded Coder software facilitates modeling and automatically generating code for asynchronous systems by using the following scheduling blocks:
Hardware Interrupt and Idle Task blocks for bare-board code generation mode
DSP/BIOS Hardware Interrupt, DSP/BIOS Task, and DSP/BIOS Triggered Task blocks for DSP/BIOS code generation mode
C6000 Hardware Interrupt blocks enable selected hardware interrupts for the TI TMS320C6000 DSP, generate corresponding ISRs, and connect them to the corresponding interrupt service vector table entries.
When you connect the output of the C6000 Hardware Interrupt block to the control input of a function-call subsystem, the generated subsystem code is called from the ISRs each time the interrupt is raised.
The C6000 Idle Task block specifies one or more functions to execute as background tasks in the code generated for the model. The functions are created from the function-call subsystems to which the Idle Task block is connected.
The DSP/BIOS Hardware Interrupt block (in DSP/BIOS code generation mode) has the same functionality as the bare-board C6000 Hardware Interrupt block. The configuration and low-level handling of the hardware interrupts is implemented through DSP/BIOS using DSP/BIOS Hardware Interrupt module and DSP/BIOS dispatcher.
DSP/BIOS Task blocks (DSP/BIOS code generation mode) spawn free-running tasks as separate DSP/BIOS threads. The spawned task runs the function-call subsystem connected to its output. Blocks in the subsystem may use various conditions and techniques to control sharing sources with other tasks.
DSP/BIOS Triggered Task blocks (in DSP/BIOS code generation mode) spawn semaphore-controlled tasks as separate DSP/BIOS threads. The semaphore that enables execution of a single instance of the task is posted by an ISR that is created by a DSP/BIOS Hardware Interrupt block. This block is connected to a DSP/BIOS Triggered Task block.
Now you can use an asynchronous (real-time) scheduler for your target application. Earlier versions of Embedded Coder software used a synchronous CPU timer interrupt-driven scheduler. With the asynchronous scheduler you can define interrupts and tasks to occur when you want them to using blocks in the following libraries:
C6000 Scheduler
DSP/BIOS library (dspbioslib)
Also, you can schedule multiple tasks for asynchronous execution using those blocks libraries.
The following figures show a model updated to use the asynchronous scheduler rather than the synchronous scheduler.
Model Inside the Function Call Subsystem Block.
The V3.0 changes in the real-time scheduler can break some existing multirate models that contain codec blocks such as the ADC and DAC. The models affected contain at least one sample rate that is faster than the codec block rate. You do not run into this problem if all rates in the model are lower than the codec rate.
The new scheduler provides improved control for your processing and improved performance. You should recast all of your models to use the new asynchronous scheduler. To update your models, embed the entire processing algorithm or system in a function-call subsystem driven by a DSP/BIOS Task or Idle Task block from the DSP/BIOS library.
An example of such a model contains a combination of an ADC block and a DAC block, with a processing algorithm between them that executes at the higher rate. If you run code generated for such a model in multitasking or auto solver mode, you might hear occasional audio glitches or your program may overrun. The exact symptom of the problem depends on the run-time overrun action setting in the IDE Link options.
The following model demonstrates one possible model configuration that can demonstrate the audio problems.
This multirate model uses two interrupts to control real-time execution of the generated code:
A DMA interrupt to drive the execution of the code for ADC and DAC blocks
A timer interrupt to drive the execution of the code for the FIR filter at an increased sample rate
In earlier product versions, the generated scheduler constantly synchronized the DMA and timer interrupts so that they remained in sync with one another, despite the possible clock drift with interrupts that are recorded by independent clock sources.
With the new real-time scheduler, the product does not synchronize the ADC and timer interrupts.
One interrupt may get out of sync with the other, with the time difference between them (drift) fluctuating with changes in the independent interrupt clocks. When the drift reaches a critical threshold, processing may skip an instance of a lower-priority task.
At that point, the interrupts are back in sync and the process continues. Losing synchronization between the interrupts can corrupt the audio signal or lead to an interrupt overrun.
To avoid the audio problems in an existing model that you cannot update to the new scheduler, set the run-time overrun action for the model to either None or Notify_and_continue to prevent the program from overrunning.
The following sections present common cases for the scheduling blocks described in the previous sections.
Free-Running DSP/BIOS Task. The following model illustrates a case where a reverberation algorithm runs in the context of a free-running DSP/BIOS task.
Normally, the algorithms in this type of task run in free-running mode, that is, they run repetitively and indefinitely. However, in this function-call subsystem (shown in detail in the following figure), ADC and DAC blocks suspend the execution of the task until the ADC and DAC data is available.
Each instance of the reverberation algorithm is triggered only after the data buffer is available (for both ADC and DAC). An asynchronous ADC/DAC device driver layer separate from the task function manages the triggers condition. This device driver layer uses a direct memory access (DMA) interrupt to signal to the DSP/BIOS task when ADC and DAC data become available for the task function.
This model also illustrates how synchronous and asynchronous tasks can work together. The code generated for C6416 DSK DIP Switch block runs as a periodic task at the rate of 0.01 s. This is the only periodic task in the model. It runs out of the context of a DSP/BIOS task scheduled via a timer interrupt configured to go off every 0.01 second.
In general, Simulink blocks that specify nonzero sample rates, such as the DIP Switch block, are scheduled by the C6000 synchronous scheduler and executed either from the context of a DSP/BIOS task (if you incorporate DSP/BIOS in your project) or a hardware interrupt (when you do not incorporate DSP/BIOS).
For data integrity, Simulink Rate Transition blocks connect the C6416 DSK DIP Switch block with the reverberation algorithm. This transition is required because the blocks belong to different rate groups. If the synchronous and asynchronous parts of the model do not interact, the Rate Transition blocks are not required.
Idle Task. The following model illustrates a case where the reverberation algorithm runs in the context of a background task in bare-board code generation mode.
The function generated for this task normally runs in free-running mode—repetitively and indefinitely. However, the ADC and DAC blocks in this subsystem run in blocking mode. As a result, subsystem execution of the reverberation function is the same as the subsystem described for the Free-Running DSP/BIOS Task. It is data driven via a background DMA interrupt-controlled ISR, shown in the following figure.
Hardware Interrupt Triggered DSP/BIOS Task. The next model illustrates a case where a function (Location Command) runs in the context of a hardware interrupt-triggered DSP/BIOS task.
The DSP/BIOS Hardware Interrupt block installs an ISR function that signals a DSP/BIOS task to run when the ISR detects an RTDX interrupt. Signaling between the ISR and DSP/BIOS triggered task occurs via semaphores. This task receives an RTDX message carrying the location command for the downstream Text Insert block in the Text Overlay from the host computer.
The blocks running inside the Location Command and Text Overlay subsystems are shown in the following figure.
The text overlay subsystem is executed as for the Free-Running DSP/BIOS Task. For data integrity, a Rate Transition block connects the two subsystems that run at two different asynchronous rates. The execution of two asynchronous rates is ordered based on the priority settings for the DSP/BIOS Task blocks.
Hardware Interrupt Triggered Task. In the next figure, you see a case where a function (LED Control) runs in the context of a hardware interrupt triggered task.
In this model, the C6000 Hardware Interrupt block installs a task that runs when it detects an external interrupt. This task then toggles an external C6416DSK LED on or off.
When you use the DSP/BIOS task blocks for scheduling, either the DSP/BIOS Task block or the DSP/BIOS Triggered Task block, you must take care to avoid some common scheduling pitfalls.
First, the DSP/BIOS operating system always executes the task with the highest priority. Contrast this execution scheme with that of some other real-time operating systems (RTOS) where each task gets its fair share of processing time. Therefore, depending on the situation, there may be cases where lower-priority tasks never execute because a higher priority task is never blocked.
A DSP/BIOS task blocks only when a blocking device driver block is included in the function call subsystem the task is executing, such as ADC/DAC blocks and C6000 UDP Receive blocks. If a particular DSP/BIOS task executes a function call subsystem that does not include any device driver blocks, and this particular task has the highest priority, it never releases the CPU, effectively disabling all other lower priority tasks in the application.
For more information about asynchronous schedulers, refer to the Handle Asynchronous Events chapter in your Simulink Coder documentation in the online help system.
Model reference lets your model include other models as modular components. This technique provides useful features because it:
Simplifies working with large models by letting you build large models from smaller ones, or even large ones.
Lets you generate code once for all the modules in the entire model and only regenerate code for modules that change.
Lets you develop the modules independently.
Lets you reuse modules and models by reference, rather than including the model or module multiple times in your model. Also, multiple models can refer to the same model or module.
Your Simulink Coder documentation provides much more information about model reference.
Model reference behaves differently in simulation and in code generation. For this discussion, you need to know the following terms:
Top-model — The root model block or model. It refers to other blocks or models. In the model hierarchy, this is the topmost model.
Referenced models — Blocks or models that other models reference, such as models the top-model refers to. All models or blocks below the top-model in the hierarchy are reference models.
The following sections describe briefly how model reference works. More details are available in your Simulink Coder documentation in the online help system.
Model Reference in Simulation. When you simulate the top-model, Simulink Coder software detects that your model contains referenced models. Simulink generates code for the referenced models and uses the generated code to build shared library files for updating the model diagram and simulation. It also creates an executable (a MEX file, .mex) for each reference model that is used to simulate the top-model.
When you rebuild reference models for simulations or when you run or update a simulation, Simulink software rebuilds the model reference files. Whether reference files or models are rebuilt depends on:
Whether and how you change the models.
The Rebuild parameter on the Model Reference pane in the Configuration Parameters dialog.
Model Reference in Code Generation. Simulink Coder software requires executables to generate code from models. If you have not simulated your model at least once, Simulink Coder software creates a .mex file for simulation.
Now, for each referenced model, the code generation process calls make_rtw and builds each referenced model. This build process creates a library file for each of the referenced models in your model.
After building all the referenced models, Simulink Coder software calls make_rtw on the top-model, linking to all the library files it created for the associated referenced models.
With few limitations or restrictions, the Embedded Coder provides full support for generating code from models that use model reference.
Build Action Setting. The most important requirement for using model reference with the TI targets is that you must set the Build action (go to Configuration Parameters > IDE Link) for all models referred to in the simulation to Archive_library.
To set the build action
Select Simulation > Configuration Parameters from the model menus.
The Configuration Parameters dialog box opens.
Expand the node for the Code Generation pane. Then select the IDE Link pane.
In the right pane, under Run-Time, set Build action to Archive_library.
If your top-model uses a reference model that does not have the build action set to Archive_library, the build process automatically changes the build action to Archive_library and issues a warning about the change.
As a result of selecting the Archive_library setting, other options are disabled:
DSP/BIOS is disabled for all referenced models. Only the top-model supports DSP/BIOS operation.
Overrun action, Overrun notification method, Exporting CCS object to the workspace, and Stack size are all disabled for the referenced models.
Target Preferences Blocks in Reference Models. Each referenced model and the top-model must include a Target Preferences block for the right target processor. You must configure all the Target Preferences blocks for the same target processor.
To obtain information about which compiler to use and which archiver to use to build the referenced models, the referenced models require Target Preferences blocks. Without them, the compile and archive processes do not work.
Other Block Limitations. Model reference with Embedded Coder software does not allow you to use certain blocks or S-functions in reference models:
No blocks from the C62x DSP Library (tic64dsplib) (because these are noninlined S-functions)
No blocks from the C64x DSP Library (tic62dsplib) (because these are noninlined S-functions)
No noninlined S-functions
No driver blocks, such as the ADC or DAC blocks from any Embedded Coder library
Targets that you plan to use in Model Referencing must meet some general requirements.
A model reference compatible target must be derived from the ERT or GRT targets.
When you generate code from a model that references another model, you need to configure both the top-level model and the referenced models for the same code generation target.
The External mode option is not supported in model reference Simulink Coder target builds. Embedded Coder software supports External mode, but not with model reference. If you select this option, it is ignored during code generation. For more information, please see the Host/Target Communication chapter in the Simulink Coder User's Guide.
To support model reference builds, your TMF must support use of the shared utilities folder, as described in Supporting Shared Utility folders in the Build Process.
To use an existing target, or a new target, with Model Reference, you set the ModelReferenceCompliant flag for the target processor. For information on how to set this option, refer to ModelReferenceCompliant in the online help system.
If you start with a model that was created prior to version 2.4 (R14SP3), to make your model compatible with the model reference target, use the following command to set the ModelReferenceCompliant flag to On:
set_param(bdroot,'ModelReferenceCompliant','on')
Models that you target with the Embedded Coder versions 2.4 and later automatically include the model reference capability. You do not need to set the flag.
Texas Instruments markets a complete set of tools for you to use with the a range of development boards, such as the C6713 DSK. These tools are primarily intended for rapid prototyping of control systems and hardware-in-the-loop applications. This section provides a brief example of how to use TI development tools with Simulink Coder software and the C6713 DSK blocks.
Executing code generated from Simulink Coder software on a particular target in real time requires target-specific code. Target-specific code includes I/O device drivers and an interrupt service routine. Other components, such as Embedded Coder software, are required if you need the ability to download parameters on the fly to your target hardware.
Since these components are specific to particular hardware targets (in this case, the C6713 DSK), you must check that the target-specific components are compatible with the target hardware.
To allow you to build an executable, Embedded Coder software provides a target makefile specific to the evaluation module. This target makefile invokes the optimizing compiler, provided as part of TI Code Composer Studio software.
Used in combination with Simulink Coder software, TI products provide an integrated development environment that, once installed, needs no additional coding.
Generally, targeting hardware, or a development environment as some call it, requires that you complete a series of processes that starts with building your model and ends with generating code to suit your target processor.
Build the Simulink model of your algorithm or process to be converted to code for your target processor.
Add target-specific blocks to your model, such as ADC and DAC blocks, and configure the block parameters.
Configure the options on the Target Preferences block to select the target, map memory segments, allocate sections to the memory segments, and configure other target-specific options.
Set the Configuration Parameters for your model. Notice that you do this step after you add the Target Preferences block to your model.
After you install the C6713 DSK development board and supporting TI products on your PC, start the MATLAB software. At the MATLAB command prompt, enter c6713dsklib. This opens a Simulink block library, c6713dsklib, that includes a set of blocks for C6713 DSK I/O devices, as described in the following table.
Block | Description |
|---|---|
C6713 DSK ADC | Configure the analog to digital converter |
C6713 DSK DAC | Configure the digital to analog converter |
C6713 DSK LED | Control the user status LEDs on the C6713 DSK |
C6713 DSK Reset | Reset the processor on the C6713 DSK |
These blocks are associated with your C6713 DSK board. As required, add the blocks to your model.
With your model open, select Simulation > Configuration Parameters. From the Configuration Parameters dialog box, select the Code Generation from pane. Use the Code Generation pane to select the right System target file for your embedded processor. For the C6713 DSK, in the Code Generation pane, specify System target file —idelink_grt.tlc
With this configuration, you can generate a real-time executable and download it to the TI C6713 evaluation board. You generate the executable by clicking Build on the Code Generation pane. The Simulink Coder software automatically generates C code and inserts the I/O device drivers as specified in your block diagram. These device drivers are inserted in the generated C code as inlined S-functions. Inlined S-functions offer speed advantages and simplify the generated code. For more information about inlining S-functions, refer to Target Language Compiler Reference documentation. For a complete discussion of S-functions, refer to your Writing S-Functions documentation.
During the same build operation, the software invokes the TI compiler to build an executable file. If you select the Build_and_execute option, Simulink Coder software automatically downloads the executable to the TI evaluation board via the peripheral component interface (PCI) bus. After downloading the executable file to the C6713 DSK, the build process runs the file on the processor.
Starting and Stopping DSP Applications on the C6713 DSK. When you generate code, build the project, and download the code for your Simulink model to your C6713 DSK, you are running actual machine code corresponding to the block diagram you built in Simulink software. To start running your DSP application on the evaluation module, you must open your Simulink model and rebuild the machine executable by clicking Build. To start the application on the C6713 DSK, you use Simulink Coder software to rebuild the executable from the Simulink model and download the code to the board.
Your model runs until it encounters one of the following actions:
You select Debug > Halt in CCS IDE.
You shut down the host PC.
The process encounters a Stop block in the model code.
The running application encounters an error condition that stops the process.
If you included a Reset C6713 DSK block in your model, clicking the block stops the running application and restores the digital signal processor to its initial state.
Note When you build and execute a model on the C6713 DSK, the Simulink Coder build process resets the evaluation module automatically. You do not need to reset the board before building models. To stop processes that are running on the evaluation module, or to return the board to a known state for any reason, use the Reset C6713 DSK block. |
When you install the C6713DSK, set the dual inline pin (DIP) switches as shown in the following table. If you have installed the board with different settings, reconfigure the board. Refer to your TMS320C6201/6713Evaluation Module User's Guide for details.
DIP Switch | Name | Setting | Effect |
|---|---|---|---|
SW2-1 | BOOTMODE4 | On | Boot mode setting |
SW2-2 | BOOTMODE3 | On | Boot mode setting |
SW2-3 | BOOTMODE2 | Off | Sets memory map = 1 when SW2-5 is off |
SW2-4 | BOOTMODE1 | On | Boot mode setting |
SW2-5 | BOOTMODE0 | Off | Sets memory map =1 when SW2-3 is off |
SW2-6 | CLKMODE | On | Sets multiply-by-4 mode |
SW2-7 | CLKSEL | On | Selects oscillator A |
SW2-8 | ENDIAN | On | Selects little endian mode |
SW2-9 | JTAGSEL | Off | Selects internal Test Bus Controller (TBC) |
SW2-10 | USER2 | On | User-defined option |
SW2-11 | USER1 | On | User-defined option |
SW2-12 | USER0 | On | User-defined option |
Texas Instruments supplies a test utility to verify the operation of the board and its associated software. For complete information about running the test utility and interpreting the results, refer to your TMS320C6201/6713 DSP Starter Kit User's Guide.
To run the C6713 DSK verification test, complete the following steps after you install your board:
Select Start > Programs > Code Composer Studio > DSK Confidence Test. As the test runs, the results appear on your display.
By default, the test utility does not create a log file to store the test results. To specify the name and location of a log file to contain the results of the confidence test, use the command line options in CCS IDE to run the confidence test utility. For further information about running the verification test from a DOS window and using the command line options, refer to TMS320C6201/6713 Evaluation Module User's Guide.
Review the test results to verify that everything works. Check that the options settings match the settings listed in the table above.
If your options settings do not match the configuration shown in the preceding table, reconfigure your C6713 DSK. After you change your board configuration, rerun the verification utility to check your new settings.
You create real-time digital signal processing models the same way you create other Simulink models—by combining standard DSP blocks and C-MEX S-functions.
You add blocks to your model in several ways:
Use blocks from the DSP System Toolbox software
Use blocks from the fixed-point blocks library TI C62x DSPLIB or TI C64x DSPLIB
Use other Simulink discrete-time blocks
Use the blocks provided in the C6000 blockset: ADC, DAC, LED and Reset blocks for specific supported target hardware
Use blocks that provide the functions you need from any blockset installed on your computer
Create and use custom blocks
Once you have designed and built your model, you generate C code and build the real-time executable by clicking Build on the Code Generation pane of the Configuration Parameters dialog box. The automatic build process creates the file modelname.out containing a real-time model image in COFF file format that can run on your target processor.
The file modelname.out is an executable whose format is target-specific. You can load the file to your target and execute it in real time. Refer to your Simulink Coder documentation for more information about the build process.
For this tutorial, we demonstrate an application that uses multiple stages—using wavelets to remove noise from a noisy signal. Open the demo model, c6713dskwdnoisf. As with any model file, you can run this denoising demonstration by typing c6713dskwdnoisf at the MATLAB prompt. The model also appears in the MATLAB demos collection in the Help browser—under Simulink demos, in the Embedded Coder category. Here is a picture of the model as it appears in the demonstration library.
Unlike the audio reverberation demo, this model is difficult to build from blocks in Simulink software. It uses complex subsystems for the Delay Alignment block and the Soft Threshold block. For this tutorial, you work with a copy of the demonstration model, rather than creating the model.
This tutorial takes you through generating C code and building an executable program from the demonstration model. The resulting program runs on your C6713 DSK as an executable COFF file.
It is convenient to work with a local copy of the c6713dskwdnoisf model, stored in its own folder, which you named (something like c6713dnoisfex). This discussion assumes that the c6713dnoisfex folder resides on drive d:. Use the right drive letter for your machine. Set up your working folder as follows:
Create the new model folder from the MATLAB command line by typing
!mkdir d:\c6713dnoisfex (on PC)
Make c6713dnoisfex your working folder.
cd d:/c6713dnoisfex
Open the c6713dskwdnoisf model.
c6713dskwdnoisf
The model appears in the Simulink window.
From the File menu, choose Save As. Save a copy of the c6713dskwdnoisf model as d:/c6713dnoisfex/dnoisfrtw.mdl.
During code generation, Simulink Coder software creates a build folder within your working folder. The build folder name is model_target_rtw, derived from the name of your source model and your chosen target processor. In the build folder, Simulink Coder software stores generated source code and other files created during the build process. You examine the contents of the build folder at the end of this tutorial.
To generate code appropriately from the dnoisfrtw model, you must change some of the Configuration Parameters. In particular, Simulink Coder software uses a fixed-step solver. To set the parameters, use the Configuration Parameters dialog box as follows:
From the Simulation menu, choose Configuration Parameters. The Configuration Parameters dialog box opens.
Click Solver and enter the following parameter values on the Solver pane. Note that Embedded Coder software does not honor a stop time if you set one here.
Start Time: 0.0
Stop Time: inf
Solver options: set Type to Fixed-step. Select the Discrete solver algorithm. (Targeting does not work with continuous time solvers.)
Fixed step size: auto
Tasking mode for periodic sample times: Auto
Save the model. Configuration Parameters persist with the model (as the model configuration set), for you to use in future sessions.
In the next figure you see the Solver pane with the right parameter settings.
To specify the desired target configuration, choose the System target file.
In these tutorials, you do not need to specify these parameters individually. Instead, you use the ready-to-run idelink_grt.tlc target configuration.
Note In the Configuration Parameters dialog box, you can expand the node for the Code Generation pane in order to see other important panes. During this tutorial you change or review options in just a few of those panes. |
To target your C6713 DSK:
From the Simulation menu, choose Configuration Parameters. The Configuration Parameters dialog box opens.
Select the Code Generation pane.
Click Browse next to the System target file field. This opens the System Target File Browser. The browser displays a list of available target configurations. When you select a target configuration, Simulink Coder software automatically chooses the right system target file.
From the list of available configurations, select idelink_grt.tlc, and click OK.
Expand the node for the Code Generation pane and select IDE Link.
Set the Run-Time and Vendor Tool Chain as shown in the preceding figure.
To export the handle (a variable) that CCS IDE creates when you generate code from your model, select Export IDE link handle to base workspace, and enter a name for the handle in IDE link handle name.
Click OK to close the Configuration Parameters dialog box. Save the model to retain your new build settings.
The Simulink Coder build process generates C code from your model, and then compiles and links the generated program.
To build and run your program:
Access the Configuration Parameters dialog box for your model.
Click Build in the Code Generation pane to start the build process.
A number of messages concerning code generation and compilation appear in the MATLAB workspace. The initial messages are
### Starting Simulink Coder build procedure for model: dnoisfrtw ### Generating code into build folder: .\dnoisfrtw_c6000_rtw
The content of the succeeding messages depends on your compiler and operating system. The final message is
### Successful completion of Simulink Coder build procedure for model: dnoisfrtw
The working folder now contains an executable, dnoisfrtw.exe. In addition, Simulink Coder software created a build folder, dnoisfrtw_c6000_rtw.
To review the contents of the working folder after the build, type the dir command at the MATLAB command prompt.
dir . dnoisfrtw.exe dnoisfrtw_c6000_rtw .. dnoisfrtw.mdl
To run the executable from the MATLAB command prompt, type
!dnoisfrtw
The "!" character passes the command that follows it to the operating system, which runs the stand-alone dnoisfrtw program.
The program produces one line of output.
**starting the model**
To see the contents of the build folder, type
dir dnoisfrtw_c6713_rtw
The build process creates a build folder and names it model_target_rtw, concatenating the name of your source model and your chosen target processor. In this example, your build folder is named dnoisfrtw_c6713_rtw.
dnoisfrtw_c6713_rtw contains these generated source code files:
dnoisfrtw.c — The stand-alone C code that implements the model.
dnoisfrtw.h — An include header file containing information about the state variables
dnoisfrtw_export.h — An include header file containing information about exported signals and parameters
The build folder also contains other files used in the build process, such as the object (.obj) files and the generated makefile (dnoisfrtw.mk).
Embedded Coder software lets you use Simulink Coder software to generate, target, and execute Simulink models on the Texas Instruments (TI) C6713 DSP Starter Kit (C6713 DSK). In combination with the C6713 DSK, your the Embedded Coder is the ideal resource for rapidly prototyping and developing embedded systems applications for the TI C6713 Digital Signal Processor. The Embedded Coder focuses on developing real-time digital signal processing (DSP) applications for the C6713 DSK.
This chapter describes how to use the Embedded Coder to create and execute applications on the C6713 DSK. To use the targeting software, you should be familiar with using Simulink to create models and with the basic concepts of Simulink Coder software automatic code generation. To read more about Simulink Coder software, refer to your Simulink Coder documentation.
Texas Instruments supplies a test utility to verify operation of the board and its associated software. For complete information about running the test utility and interpreting the results, refer to your "TMS320CDSK Help" under TMS320C6000 Code Composer Studio Help in the CCS online help system.
To run the C6713 DSK confidence test, complete the following steps after you install and configure your board.
Access the folder \..\ti\c6000\dsk6x11\conftest
CCS IDE creates this folder when you install it. It contains the files to run the C6713 confidence test.
Start the confidence test by typing dsk6xtst at the DOS prompt.
By default, the test utility creates a log file named dsk6xtst.log where it stores the test results. To specify the name and location of a log file to contain the results of the confidence test, use the CCS IDE command line options to run the confidence utility. For further information about running the confidence test from a DOS window and using the command line options, refer to the "DSK Confidence Test" topic in the CCS IDE online help.
If your confidence test fails, reconfigure your C6713 DSK. After you change your board configuration, rerun the confidence utility to check your new settings.
Texas Instruments markets a complete set of tools for use with the C6713 DSK. These tools are primarily intended for rapid prototyping of control systems and hardware-in-the-loop applications.
This section provides a brief example of how the TI development tools work with Simulink Coder software, the Embedded Coder, and the C6713 DSK block library.
Executing code generated from Simulink Coder software on a particular target in real-time requires target-specific code. Target-specific code includes I/O device drivers and an interrupt service routine.
Other components, such as Embedded Coder software, are required if you need the ability to download parameters on-the-fly to your target hardware.
Since these components are specific to particular hardware targets (in this case, the C6713 DSK), check that the target-specific components are compatible with the target hardware.
To allow you to build an executable, the Embedded Coder provides a target makefile specific to C6000 hardware targets. This target makefile invokes the optimizing compiler provided as part of CCS IDE.
Used in combination with the Embedded Coder and Simulink Coder software, TI products provide an integrated development environment that, once installed, needs no additional coding.
After you have installed the C6713 DSK development board and supporting TI products on your PC, start the MATLAB software. At the MATLAB command prompt, type c6713dsklib. This opens a Simulink block library, c6713dsklib, that includes a set of blocks for C6713 DSK I/O devices:
C6713 DSK ADC — Configure the analog to digital converter
C6713 DSK DAC — Configure the digital to analog converter
C6713 DSK LED — Control the user-defined light emitting diodes (LED) on the C6713 DSK
C6713 DSK DIP Switch — Set the dual inline pin switches on the C6713 DSK
C6713 DSK Reset — Reset the processor on the C6713 DSK
These devices are associated with your C6713 DSK board.
With your model open, select Simulation > Configuration Parameters from the menu bar to open the Configuration Parameters dialog box.
In the Configuration Parameters dialog box, select the Code Generation pane. For the C6713 DSK set System target file to idelink_grt.tlc
With this configuration, you can generate and download a real-time executable to your TI C6713 DSK. Start the Simulink Coder build process by clicking Build on the Code Generation pane. Simulink Coder software automatically generates C code and inserts the I/O device drivers as specified by the ADC and DAC blocks in your block model.
These device drivers are inserted in the generated C code as inlined S-functions. Inlined S-functions offer speed advantages and simplify the generated code. For more information about inlining S-functions, refer to your Target Language Compiler documentation. For a complete discussion of S-functions, refer to your documentation about writing S-functions.
During the same build operation, the software invokes the TI compiler to build an executable file.
If you select the Build_and_execute option, the executable file is automatically downloaded via the peripheral component interface (PCI) bus to the TI evaluation board. After downloading the executable file to the C6713 DSK, the build process runs the file on the digital signal processor.
Starting and Stopping DSP Applications on the C6713 DSK. When you create, build, and download a Simulink model to the C6713 DSK, you are not running a simulation of your DSP application. You are running the actual machine code corresponding to the block diagram you built in Simulink software. To start running your DSP application on the evaluation module, you must open your Simulink model and rebuild the machine executable by clicking Build on the Code Generation pane. Each time you want to start the application on the C6713 DSK, you use Simulink Coder software to rebuild the executable from the Simulink model and download the code to the board.
Your model runs until the model encounters one of the following actions:
Using the Debug > Halt option in CCS IDE
Using halt from the MATLAB command prompt
Encountering a Stop block in the model.
Clicking the C6713 DSK Reset block in your model (if you added one) or in the DSK block library
Clicking the Reset block stops the running application and restores the digital signal processor to its initial state.
Rather than targeting your C6000 board when you build your signal processing application, you can create Texas Instruments Code Composer Studio (CCSv3) IDE projects. Creating projects for CCSv3 IDE lets you use the tools provided by the CCSv3 IDE software suite to debug your real-time process.
If you build and download your Simulink model to CCSv3 IDE, Embedded Coder software opens Code Composer Studio software, creates a new CCSv3 IDE project named for your model, and populates the new project with all the files it creates during the build process—the object code files, the assembly language files, the map files, and any other required files. As a result, you can immediately use CCSv3 IDE to debug your model using the features provided by the CCSv3 IDE.
Creating a project in CCSv3 IDE is the same as targeting C6000 hardware. You configure your target options, select your build action to create a CCSv3 IDE project, and then build the project in CCSv3 IDE by clicking Make Project.
In the Configuration Parameters dialog box, expand the node for the Code Generation pane, and then select the IDE Link pane. Set Build action to Create_project. The Archive_library option does not create a CCSv3 IDE project. None of the other options is relevant when you are simply creating an IDE project.
Return to the Simulink Coder category, clear Generate code only and click Build to build your new CCSv3 IDE project.
Simulink Coder software and Embedded Coder software generate all the files for your project in CCSv3 IDE and create a new project in the IDE. Your new project is named for the model you built, with a custom project build configuration CustomMW, not Release or Debug.
In CCSv3 IDE you see your project with the files in place in the folder tree.
As long as the processor on your custom board is from the TI C6000 DSP family, you can use Embedded Coder software to generate code for your target processor.
The blocks for the peripherals in the C6000 DSP Library, such as the C6416 DSK ADC or C6713 DSK DAC blocks, are specific to their hardware and will not work with your custom board. None of the board-specific blocks provided by this toolbox work with custom hardware.
The Target Preferences block provides a way to target boards that are not specifically supported. Due to certain features related to memory maps and other processor-specific attributes, custom hardware targeting only works with the C6000 DSPs.
Several guidelines affect your targeting configuration decisions when you decide to use custom targets and the custom Target Preferences block:
Specify the memory allocation (memory mapping) using the Memory and Section panes on the Target Preferences dialog box. Set the memory mapping for your target that best matches your hardware. For example, if your custom target uses the C6713 processor, be sure your memory configuration is the same as the one on the supported C6713 DSK, such as has the same memory size, the same EMF settings, the same memory sections, and the same cache organization.
To use on-chip memory only for your target, choose the Near_Calls setting for the Memory model in the TI C6000 compiler options. To use external memory that is specific to your board, choose the Far_Calls setting for the Memory model. The other selection in the Memory model list offers a combination of near and far allocation for data and aggregate data.
Do not use the existing ADC, DAC, DIP Switch, or LED blocks unless you are quite sure that your hardware is identical to the matching EVM or DSK in all important respects. Generally, the ADC, DAC, and other target-specific blocks are design specifically for their designated targets and can cause problems when you use them on hardware that is not identical.
Set the Overrun notification method in the TI C6000 runtime category to Print_message when you use the overrun notification feature. If you choose to use the LED notification option, verify that on your specialized target you access the LEDs in exactly the same way, and the LEDs respond in the same way, as the LEDs on the corresponding supported DSK or EVM.
To use one of the custom targets, create your model, add and configure the Target Preferences block, and then open the Configuration Parameters dialog box for the model.
Generally, targeting hardware, or a development environment as it is called by some, requires that you complete a series of processes that starts with building your model and ends with generating code to suit your target processor.
Build the Simulink model of your algorithm or process to be converted to code for your target processor.
Add target-specific blocks to your model, such as ADC and DAC blocks, and configure the block parameters. (Skip this step when you are targeting a processor on a custom board.)
Add a Target Preferences block to your model. The top level of the model must contain a Target Preferences block.
Configure the options on the Target Preferences block to select the target, map memory segments, allocate code and data sections to the memory segments, and set other target-specific options.
Set the Simulink Configuration Parameters for your model. Notice that you do this after you add the Target Preferences block to your model.
Memory Maps. Memory maps are an essential part of targeting any processor or board. Without the map, the code generation process cannot determine where various features of the generated code, such as variables, data, and executable code, reside on the target processor.
To discuss memory maps and configuring memory, a few terms need to be defined:
Memory map — Map of the memory space for a target system. The memory space is partitioned into functional blocks.
memory segment — Memory partition that corresponds to a physical range of memory on the target processor. The segment is named in some fashion, such as IPRAM or SDRAM.
Memory section — The smallest unit of an object file. This is a block of data or code that, based on the memory map, resides in an area of contiguous memory on the target and in the memory map. Sections of object files are both distinct and separate. Memory sections come in two flavors:
Uninitialized sections that reserve memory space for uninitialized data. One example of an uninitialized section is .bss. The .bss section reserves space for variables that are not initialized.
Initialized sections contain code and data. The .text (containing executable code) and .data (containing initialized data) sections are initialized.
Memory management — Process of specifying the memory segments that the various memory sections use for your application. A logical memory map of the hardware memory results from the process of managing memory.
During code generation, the linker and assembler work to allocate your code and data into the memory on your target according to the memory map specifications you provide. For more information about memory utilization and memory management, refer to the CCS IDE online help, using keywords like memory map, memory segment, and section.
The compiler does not interact with the memory map. It makes no assumptions about memory allocation and is not aware of the memory map. As far as the C6000 compiler is concerned, the physical memory on your target is one continuous linear block of memory that is subdivided into smaller blocks containing code, data, or both.
When you configure the block parameters for the Target Preferences block, you are setting up the memory map for your target processor. You specify the memory segments that are defined and the contents of each segment. You specify the sections, both named and default, and the segments to which the sections are assigned.
These memory management functions are identical to the ones available in the CCS IDE Configuration Tool.
To use a board that has a TI C6000 processor but is not one of the supported boards, configure the Target Preferences block as described in this section.
Configuring the block parameters software about your target processor and how to generate code that will run on the target processor.
Add the Target Preferences block to your model, or edit the current Target Preferences block.
Set Board to C6000 Custom.
Select your target processor from the Processor list. Most of the C6000 family of DSP processors are on the list. If the one you need is not listed, pick one that closely matches your target processor.
Set the actual CPU clock rate for the CPU on your target in CPU clock speed (MHz). Report the clock speed of the processor on your target processor. When you enter a value, you are not changing the CPU clock rate, you are reporting the actual rate. If the value you enter does not match the rate on the target, your model real-time results might be wrong, and code profiling results will not be appropriate. You must enter the actual clock rate the board uses. The rate you enter here does not change the rate on the board. Setting CPU clock to the actual board rate allows the code you generate to run well according to the actual clock rate of the hardware.
If your target is a simulator rather than a hardware target, use the Get from IDE button on the Board pane of the Target Preferences block. Then set Board Name under IDE Support to one of the simulators installed with your IDE.
To enable the Embedded Coder to connect to CCS IDE, select your target from the Board Name list. On this list you see the names of the boards you have configured in the CCS Setup Utility. If your target board does not appear on the list, start CCS Setup and add your board to the System Configuration dialog box.
Select the processor to target from the Processor Name list. For the board you selected in Board Name, Processor Name lists all the processors on the board. The list comes from the processors you added to the board in the CCS Setup Utility.
Now you have completed the process of identifying your target to the Embedded Coder and Simulink Coder software. While this process is required, it represents only one small part of enabling you to generate code to run on your custom board.
One very important part of targeting custom hardware is to provide the target memory map configuration to the linker and assembler.
Memory and Section panes on the Target Preferences dialog box provide the controls required to specify how the linker and assembler arrange the code, data, and variables on your target processor.
Memory Pane. The information that follows describes the options on the panes in detail.
The Memory pane contains memory options in three areas:
Physical Memory specifies the mapping for processor memory
Heap specifies whether you use a heap and determines the size in words
L2 Cache enables the L2 cache (where available) and sets the size in kB
Be aware that these options can affect the options on the Section pane. You can make selections here that change how you configure options on the Section pane.
Most of the information about memory segments and memory allocation is available from the Code Composer Studio online help.
Physical Memory Options. This list shows the physical memory segments available on the board and processor. By default, Target Preferences blocks show the memory segments found on the selected processor. In addition, the Memory pane on preconfigured Target Preferences blocks shows the memory segments available on the board, but off of the processor. Target preferences blocks set default starting addresses, lengths, and contents of the default memory segments.
The default memory segments for each processor and board are different. For example:
Custom boards based on C670x processors provide IPRAM and IDRAM memory segments by default.
C6713 DSK boards provide SDRAM memory segment by default
Name. When you highlight an entry on the Physical memory list, the name of the entry appears here. To change the name of the existing memory segment, select it in the Physical memory list and then type the new name here.
To add a new physical memory segment to the list, click Add, replace the temporary label in Name with the one to use, and press Return. Your new segment appears on the list.
After you add the segment, you can configure the starting address, length, and contents for the new segment. New segments start with code and data as the type of content that can be stored in the segment (refer to the Contents option).
Names are case sensitive. NewSegment is not the same as newsegment or newSegment.
Address. Address reports the starting address for the memory segment showing in Name. Address entries are in hexadecimal format and limited only by the board or processor memory.
When you are using a processor-specific preferences block, the starting address shown is the default value. You can change the starting value by entering the new value directly in Address when you select the memory segment to change.
Length. From the starting address, Length sets the length of the memory allocated to the segment in Name. As in all memory entries, specify the length in hexadecimal format, in minimum addressable data units (MADUs). For the C6000 processor family, the MADU is 8 bytes, one word.
When you are using a processor-specific preferences block, the length shown is the default value. You can change the value by entering the new value directly in this option.
Contents. Contents describes the kind of program sections that you can store in the memory segment in Name. As the processor type for the Target Preferences block changes, the kinds of information you store in listed memory segments can change. Generally, the Contents list contains these strings:
Code — Allow code to be stored in the memory segment in Name.
Data — Allow data to be stored in the memory segment in Name.
Code and Data — Allow code and data to be stored in the memory segment in Name. When you add a new memory segment, this is the default setting for the contents of the new element.
You can add or use as many segments of each type as you need, within the limits of the memory on your processor.
Add. Click Add to add a new memory segment to the target memory map. When you click Add, a new segment name appears, for example NEWMEM1, in Name and on the Physical memory list. In Name, change the temporary name NEWMEM1 by entering the new segment name. Entering the new name, or clicking Apply updates the temporary name on the list to the name you enter.
Remove. This option lets you remove a memory segment from the memory map. Select the segment to remove in the Physical memory list and click Remove to delete the segment.
Create Heap. If your processor supports using a heap, as does the C6713, for example, selecting this option enables creating the heap and enables the Heap size option. Create heap is not available on processors that either do not provide a heap or do not allow you to configure the heap.
Using this option you can create a heap in any memory segment on the Physical memory list. Select the memory segment on the list and then select Create heap to create a heap in the select segment. After you create the heap, use the Heap size and Define label options to configure the heap.
The location of the heap in the memory segment is not under your control. The only way to control the location of the heap in a segment is to make the segment and the heap the same size. Otherwise, the compiler determines the location of the heap in the segment.
Heap Size. After you select Create heap, this option lets you specify the size of the heap in words. Enter the number of words in decimal format. When you enter the heap size in decimal words, the system converts the decimal value to hexadecimal format. You can enter the value directly in hexadecimal format as well. Processors may support different maximum heap sizes.
Define Label. Selecting Create heap enables this option that allows you to name the heap. Enter your label for the heap in the Heap label option.
Heap Label. Selecting Define label enables this option. You use Heap Label to provide the label for the heap. Any combination of characters is accepted for the label except reserved characters in C/C++ compilers.
Enable L2 Cache. C621x, C671x, and C641x processors support an L2 cache memory structure that you can configure as SRAM and partial cache. Both the data memory and the program share this second-level memory. C620x DSPs do not support L2 cache memory, and this option is not available when you choose one of the C620x processors as your target processor.
If your processor supports the two-level memory scheme, this option enables the L2 cache on the processor.
L2 Cache Size. After you enable the L2 cache, select the size of the cache from the list.
Options on this pane let you specify where various program sections should go in memory. Program sections are distinct from memory segments—sections are portions of the executable code stored in contiguous memory locations. Among the sections used generally are .text, .bss, .data, and .stack. Some sections relate to the compiler, some to DSP/BIOS, and some can be custom sections as you require.
For more information about program sections and objects, refer to the CCS IDE online help. Most of the definitions and descriptions in this section come from CCS IDE.
In the pane shown in the preceding figure, you configure the allocation of sections for Compiler, DSP/BIOS, and Custom needs.
This table provides brief definitions of the various kinds of sections in the Compiler, DSP/BIOS, and Custom lists. All sections do not appear on both lists. The string appears on the list shown in the table.
String | Section List | Description of the Section Contents |
|---|---|---|
.args | DSP/BIOS | Argument buffers |
.bss | Compiler | Static and global C variables in the code |
.bios | DSP/BIOS | DSP/BIOS code if you are using DSP/BIOS options in your program |
.cinit | Compiler | Tables for initializing global and static variables and constants |
.cio | Compiler | Standard I/O buffer for C programs |
.const | Compiler | Data defined with the C qualifier and string constants |
.data | Compiler | Program data for execution |
.far | Compiler | Variables, both static and global, defined as far variables |
.gblinit | DSP/BIOS | Load allocation of the DSP/BIOS startup initialization tables section |
.hwi | DSP/BIOS | Dispatch code for interrupt service routines |
.hwi_vec | DSP/BIOS | Interrupt Service Table |
.obj | DSP/BIOS | Configuration properties that the target program can read |
.pinit | Compiler | Load allocation of the table of global object constructors section. |
.stack | Compiler | The global stack |
.switch | Compiler | Jump tables for switch statements in the executable code |
.sysdata | DSP/BIOS | Data about DSP/BIOS |
.sysinit | DSP/BIOS | DSP/BIOS initialization startup code |
.sysmem | Compiler | Dynamically allocated object in the code containing the heap |
.text | Compiler | Load allocation for the literal strings, executable code, and compiler generated constants |
.trcdata | DSP/BIOS | TRC mask variable and its initial value section load allocation |
You can learn more about memory sections and objects in your Code Composer Studio online help.
Compiler Sections. During program compilation, the C6000 compiler produces both uninitialized and initialized blocks of data and code. These blocks are allocated into memory as required by the configuration of your system. On the Compiler Sections list you find both initialized (sections that contain data or executable code) and uninitialized (sections that reserve space in memory) sections. The initialized sections are
.cinit
.const
.switch
.text (created by the assembler)
These sections are uninitialized:
.bss (created by the assembler)
.far
.stack
.sysmem
Other sections appear on the list as well:
.data (created by the assembler)
.cio
.pinit
When you highlight a section on the list, Description shows a brief description of the section. Also, Placement shows you where the section is currently allocated in memory.
Description. Provides a brief explanation of the contents of the selected entry in the Compiler Sections list.
Placement. Shows you where the selected Compiler Sections list entry is allocated in memory. You change the memory allocation by selecting a different location from the Placement list. The list contains the memory segments as defined in the physical memory map on the Memory pane. Select one of the listed memory segments to allocate the highlighted compiler section to the segment.
DSP/BIOS Sections. During program compilation, DSP/BIOS produces both uninitialized and initialized blocks of data and code. These blocks get allocated into memory as required by the configuration of your system. On the DSP/BIOS sections list you find both initialized (sections that contain data or executable code) and uninitialized (sections that reserve space in memory) sections.
Description. Provides a brief explanation of the contents of the selected DSP/BIOS Sections list entry.
Placement. Shows where the selected DSP/BIOS Sections list entry is allocated in memory. You change the memory allocation by selecting a different location from the Placement list. The list contains the memory segments available on C6000 processors, and changes based on the processor you are using.
DSP/BIOS Object Placement. Distinct from the entries on the DSP/BIOS Sections list, DSP/BIOS objects like STS or LOG, if your project uses them, are placed in the memory segment you select from the DSP/BIOS Object Placement list. All DSP/BIOS objects use the same memory segment. You cannot select the locations for individual objects.
Custom Sections. When your program uses code or data sections that are not included in either the Compiler Sections or DSP/BIOS Sections lists, you add the new sections to this list. Initially, the Custom Sections list contains no fixed entries, just a placeholder for a section for you to define.
Name. You enter the name for your new section here. To add a new section, click Add. Then replace the temporary name with the name to use. Although the temporary name includes a period at the beginning, you do not need to include the period in your new name. Names are case sensitive. NewSection is not the same as newsection, or newSection.
Placement. With your new section added to the Name list, select the memory segment to which to add your new section. Within the restrictions imposed by the hardware and compiler, you can select any segment that appears on the list.
Add. Clicking Add lets you configure a new entry to the list of custom sections. When you click Add, the block provides a new temporary name in Name. Enter the new section name to add the section to the Custom Sections list. After typing the new name, click Apply to add the new section to the list. Or click OK to add the section to the list and close the dialog box.
Remove. To remove a section from the Custom Sections list, select the section to remove and click Remove. The selected section disappears from the list.
Although each processor has memory map requirements, the C6000 DSP family of processors share some memory features and not others. Details of the memory sections and segments, as well as memory allocations and limitations for each processor, are provided in your documentation for CCS IDE and from TI.
To manage the memory on your processor, set the options within these panes to specify the memory allocation to use. Recall that the memory map is the result of the settings you provide for the options in the Memory and Section panes in the Target Preferences dialog box.
Unfortunately, each processor has different needs, and the differences make it impossible to provide details about how you set the options for your target processor. You determine, from your model and code
What memory segments you require
Which sections you need and where
Whether you need custom memory segments and sections
Where to begin each memory segment and how much memory to allot to each segment
Any other information that you need to set the options on the Memory and Section panes?
After you configure the options in the Target Preferences dialog box, you are ready to set the Simulink Configuration Parameters for your model and generate code.
To take advantage of Embedded Coder software features, you must migrate your models to a system target file called idelink_ert.tlc. This target is based on the embedded real-time target (ERT) used by Embedded Coder software. Other Embedded Coder target files are based on the generic real-time target (GRT).
To use Embedded Coder software, choose the system target file idelink_ert.tlc, available in the System Target File Browser.
If you simply choose the system target file idelink_ert.tlc in the System Target File Browser directly to change the target for the model, all the IDE Link options are reset to default values by the switch. The C6000-specific options are the same between the two system target files.
You can set your model to use this system target file the usual way, via the System Target File Browser, available from the Simulink Coder pane in the Configuration Parameters dialog box. However, when you use the system target browser to switch your model between the ERT- and GRT-based TI C6000 system target files, the TI C6000-specific options (the configuration set) for the model are reset to default values.
For setting up a new model to use the ERT-based target .tlc file.
From your model menu bar, select Simulation > Configuration Parameters.
In the Configuration Parameters dialog box, select the Code Generation pane.
On the System Target File Browser, find and select the file idelink_ert.tlc.
 | Getting Started | Targeting with DSP/BIOS Options |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
