overview of creating a model and generating executable for c2000 processors -凯发k8网页登录

overview of creating a model and generating executable for c2000 processors

accessing the embedded coder block library

describes how to access the block library and open the required target hardware.

after you have , you can open the block library for c2000™ microcontroller blockset.
to open the c2000 microcontroller blockset library, at the matlab^® command prompt, enter the command:
```
c2000lib
```
alternately from the simulink library browser, locate, and select c2000 microcontroller blockset.
open the required target block to access the device driver blocks.
create your real-time model for your application the same way you create other simulink^® models. select blocks to build your model from the following sources or products:
- the libraries in the c2000lib block library (for handling input and output functions for on your target hardware)
- simulink coder™ software
- discrete time blocks from simulink
- another blockset that meets your needs and operates in the discrete time domain

configuring target hardware resources

describes how to configure target hardware resources using configuration parameters.

after adding the required blocks for the model, open modeling tab and click model settings.
in the configuration parameters window, click hardware implementation and select the hardware board.
configure the target hardware resources as required. for more details refer and

note

the peripherals supported in c2000 microcontroller blockset can be of any of the following configuration:

blocks only - features that can be configured only through the block. (hardware interrupt, etc.)
blocks configuration parameters - features that can configured in both block and configuration parameters. (adc, epwm, sci, spi, etc)
configuration parameters only - features that can be configured only through configuration parameters. (emif, dma, clock configuration, etc.)

configuring additional options for hardware selection

following configuration settings are done automatically as part of a ti c2000 hardware selection. on selecting different hardware other than ti c2000 target, the below configurations are re-configured to default.

when changing modelreferencenuminstancesallowed from multiple to one, the name for the signal logged in child model (output signal) when running external mode using xcp over can will change.

if set to one, you get _b.
if set to multiple, you get _dw.model_instancedata.rtb.

hcs is the config set object for the model. you can use the following command to get the config set object.

hcs = getactiveconfigset(mdlname);

go to configuration parameters > math and data typesand set the simulation behavior for denormal numbers parameter to flush to zero (ftz).
```
set_param(hcs,'denormalbehavior', 'flushtozero');
```
go to configuration parameters > math and data typesand set the default for underspecified data type parameter to single.
```
set_param(hcs,'defaultunderspecifieddatatype','single');
```
go to configuration parameters > code generation > interfaceand set the code replacement libraries parameter to ti c28x for the c28x core of ti c2000 processors.
```
set_param(hcs,'codereplacementlibrary','ti c28x');
```

go to configuration parameters > code generation > optimization > advance parameters and select the maximum stack size (bytes) parameter depending on the processor.

sl no	device family	maximum stack size(bytes)
1	f281x	`512`
2	f2802x, f2803x, f2805x, f2834x, f2804x, f28m35x, f28m36x	`768`
3	f2806x, f2837x, f28004x, f28003x, f2838x, f28002x	`1024`
4	arm-core	`2560`

set_param(hcs,'maxstacksize','1024');

go to configuration parameters > hardware implementation > device detailsand set the support long long parameter to on.
```
set_param(hcs,'prodlonglongmode','on');
```
note
models using cla requires long long mode to be set to off.
go to configuration parameters > code generation > optimizationand set the remove root level i/o zero initialization parameter to on.
```
set_param(hcs,'zeroexternalmemoryatstartup', 'on');
```

ensure the above mentioned configurations are done when the model has to run in sil mode for a custom board. in sil mode, ensure following additional setting is done:

go to configuration parameters > code generation > verificationand set the enable portable word sizes parameter to on. this will ensure identical code generation for a model in pil and sil mode.

configuring additional options for code generation

you can follow the steps below to configure additional options like compiler flag, crl and custom code, etc required for code generation in code generation pane.

in the configuration parameters window, click code generation pane.
by default,
- toolchain for c28x core of all ti c2000 processors expect ti f2838x processor is texas instruments code composer studio (c2000). this generates an executable in common object file application binary interface (coff abi) format.
- toolchain for ti f2838x (c28x) processor is texas instruments code composer studio - eabi (c2000). this generates an executable in elf application binary interface (eabi) format.
- toolchain for arm core is texas instruments code composer studio (arm).
coff abi format will interpret double datatype in simulink as 32-bit floating point for c28x processors and elf abi format will interpret double datatype in simulink as 64-bit floating point for ti f2838x (c28x) processor. for more information related to coff abi and elf abi, refer to the ti documentation.
note
- elf abi (eabi) format will only work with ti f2838x processor and rest of the ti c2000 processors with coff abi format.
- by default, the code generation tools shipped with the blockset has eabi support. if you want to use a different version of cgt ensure it has eabi support.
- all the files referred (libraries - .lib, source - .c/.h/.asm and linker command files - .cmd) should be in the same format as supported by the toolchain. else linker errors is seen during build process.
- if your are adding any custom files, ensure that the custom files matches the toolchain format.
generate code only option under build process enables you to specify code generation versus an executable build. for more information, refer (simulink coder)
you can choose the build configuration options to get the required compiler flags for the code compilation.
- faster builds
- faster run
- debug
- specify
use specify option to edit column tool options to add any additional flags. for more information, refer to (simulink coder)
the code generation > optimization category includes parameters for improving the simulation speed of your models and improving the performance of the generated code. for more information, refer (simulink coder).
the code generation > report category includes parameters for generating and customizing the code generation report. for more information, refer (simulink coder)
the code generation > custom code category includes parameters for inserting custom c code into the generated code. for more information, refer (simulink coder).
the code generation > interface category includes parameters for configuring the interface of the generated code and code replacement library(crl). for more information, refer (simulink coder).
the code generation > verification category includes code verification and performance analysis parameters for sil and pil simulations and also configuring profiling options. additionally you can configure the following options and perform profiling which is independent of sil and pil simulations:
- measure task execution time - by enabling this parameter in configuration parameters, you can perform real time execution of profiling.
- measure function execution times - configure to get different levels of profiling (tasks, subsystems or functions) in configuration parameters. the profiling logic is added accordingly. there will be additional overhead due to profiling logic on the measure time. currently only hardware interrupts are supported for asynchronous system profiling.
  - off - measure time with respective task
  - course - tasks, reference models and subsystem only
  - detailed - tasks,reference models, subsystem, block/function internalization and step logic
- save options - select to save only as summary data only or all data to get detailed time line in configuration parameters. metrics option is not supported for c2000.
profiling with build, load and run
- profiling data - run the following code in matlab command window to obtain the profiling data, report and time line.
  - profiling data - gathers profiling data from the target hardware and stores it in a variable.
    codertarget.profile.getdata('modelname')
  - profiling report - provides html report based on the profiling data.
    executionprofile.report
  - profiling timeline - provides the timeline report of the tasks or profiled functions.
    executionprofile.timeline
    for more information, refer (embedded coder) and .
- profiling with monitor & tune
  you can use the c2000 microcontroller blockset to profile the real-time execution of the generated code running as an executable on a texas instruments^® c2000 board with xcp on serial and xcp on tcp/ip interface. for more information, see .
- profiling with pil
  you can configure the profiling options and use it with pil mode.

generate code, build and download the executable

after configuring hardware resource and code generation for a model, you can generate the code, build the real-time executable and download it to your texas instruments development board. simulink coder software automatically generates c code and inserts the i/o device drivers as specified by the hardware blocks along with configuration parameters in your simulink model.

when you are creating a custom device driver block using s-function, use the matlab_mex_file macro to differentiate between simulation and code generation behaviors. for example, when you include the texas instruments header file in the generated code for creating the mex file, use the #else section to avoid compilation errors, as shown:

#ifdef matlab_mex_file /*
/* simulation behavior */
#else
/* code generation behavior*/
#endif

during the build operation, the texas instruments cross-compiler builds an executable file from the generated code. the build operation will generate dependency files (.dep) for each of the source files (.c) which it will use to create the object files (.obj). the object files are then linked using linker command file to create the map file (.map) and the executable file (.exe) files.

the default linker command file can be modified, or different linker command file can be provided if required using the option hardware implementation > target hardware resources > build options > use custom linker.

dependency build

subsequent builds will use dependency files to recompile the object files only if any source or header files are changed or make file is updated. the dependency build makes use of windows^® powershell to update the dependency files. hence the dependency build will not be used and object files is recompiled, if windows powershell is not present in the computer.

parallel build

the build will make use of multiple cores in host computer by enabling parallel build to compile the object files faster. this may cause issues in the order of the messages displayed in build log if there are any build failures. you can disable this option using hardware implementation > target hardware resources > build options > disable parallel build .

if you select the build, load and run option in hardware implementation > target hardware resources > build options > build action parameter then the generated executable is automatically downloaded to the target.

select option boot from flash if the application has to load to the flash. if you do not select this option, the application loads to the ram. hardware implementation > target hardware resources > build options > boot from flash.

by default, the target configuration file will be provided to support download to control card or launchpad of the selected hardware board. if you have any custom board, you can provide your own target configuration file in the option in hardware implementation > target hardware resources > build options > select target configuration

for ccs v5 and the later versions, a ccs project file is also generated during the build process. you can use this project file for debugging in the ccs ide.

note

rapid accelerator simulation is not supported by c2000 microcontroller blockset.

overview of creating a model and generating executable for c2000 processors -凯发k8网页登录