Target files bundled with the code generator are suitable for many different applications and development environments. Third-party targets provide additional versatility. In addition, you have the option of implementing a custom target.
To implement a target based on the ARM® Cortex®-A or ARM Cortex-M processor, install the corresponding support package and see the Target SDK: Embedded Coder® Support Package for ARM Cortex-A Processors, Develop a Target (Embedded Coder Support Package for ARM Cortex-A Processors) or Embedded Coder Support Package for ARM Cortex-M Processors, Develop a Target (Embedded Coder Support Package for ARM Cortex-M Processors). Otherwise, use these functions and topics.
You might want to implement a custom target for one of the following reasons:
To enable end users to generate executable production code for a specific CPU or development board, using a specific development environment (compiler/linker/debugger).
To support I/O devices on the target hardware by incorporating custom device driver blocks into your models.
To configure the build process for a special compiler (such as a cross-compiler for an embedded microcontroller or DSP board) or development/debugging environment.
The code generator provides a point of departure for the creation of custom embedded targets, for the basic purposes above. This manual covers the tasks and techniques you need to implement a custom embedded target.
The following sections describe several types of targets intended for different use cases
There is a progression of capabilities from baseline or rapid prototyping targets to production targets. Initially, you might want to implement a rapid prototyping target. Later, you can enhance the target to be more full-featured. For example, you might want to add support for software-in-the-loop (SIL) or processor-in-the-loop (PIL) simulation at some point for verifying your embedded target. The target types are not mutually exclusive. An embedded target can support more than one of these use cases, or additional uses not outlined here.
The discussion of target types is followed by Recommended Features for Embedded Targets, which contains a suggested list of features and general guidelines for embedded target development.
A rapid prototyping target or baseline target offers a starting point for targeting a production processor. A rapid prototyping target integrates coded generator software with one or more popular cross-development environments (compiler/linker/debugger tool chains). A rapid prototyping target provides a starting point from which you can customize the target for application needs.
Target files provided for this type of target should be readable, easy to understand, and fully commented and documented. Specific attention should be paid to the interface to the intended cross-development environment. This interface should be implemented using the preferred approach for that particular development system. For example, some development environments use traditional make utilities, while others are based on project-file builds that can be automated under control of the code generator.
When you use a rapid prototyping target, you need to include your own device driver and legacy code and modify linker memory maps to suit your needs. You should be familiar with the targeted development system.
A production target supports embedded application development for a production processor. It includes the capability to create program executables that interact immediately with the external world. In general, ease of use is more important than simplicity or readability of generated code files, because it is assumed that you do not want or need to modify the files.
Desirable features for a production target include:
Significant I/O driver support, provided out of the box
Easy downloading of generated standalone executable programs with third-party debuggers
User-controlled placement of an executable in FLASH or RAM memory
Support for code visibility and tuning on target hardware
You can use software-in-the-loop (SIL) or processor-in-the-loop (PIL) simulation to verify generated code and validate the target compiler/processor environment.
You can use SIL and PIL simulation modes to verify automatically generated code by comparing the results with a normal mode simulation. With SIL, you can easily verify the behavior of production-intent source code on your host computer; however, it is generally not possible to verify exactly the same code that will subsequently be compiled for your target hardware because the code must be compiled for your host platform (i.e. a different compiler and different processor architecture than the target). With PIL simulation, you can verify exactly the same code that you intend to deploy in production, and you can run the code either on real target hardware or on an instruction set simulator.
For examples describing how to run processor-in-the-loop testing to verify a custom target, see Sample Custom Targets.
For more information on SIL and PIL simulation, see SIL and PIL Simulations (Embedded Coder).
A specialized use case is the generation of executables intended for use in hardware-in-the-loop (HIL) simulations. In a HIL simulation, parts of a pure simulation are gradually replaced with hardware components as components are refined and fabricated. HIL simulation offers an efficient design process that eliminates costly iterations of part fabrication.
You can base targets on the generic real-time (GRT) target or the Embedded Real-Time (ERT) target that is included in the Embedded Coder product.
If your target is based on the ERT target, it should use
'Embedded-C' value for the CodeFormat TLC
variable, and it should inherit the options defined in the ERT target's system target
file with the following lines in the TLC file:
%% Assign code format %assign CodeFormat = "Embedded-C" %%---------------------------- /% BEGIN_RTW_OPTIONS rtwgensettings.DerivedFrom = 'ert.tlc'; END_RTW_OPTIONS %/ %%----------------------------
By following these recommendations, your target has the production code generation capabilities of the ERT target.
See Customize System Target Files for further details on the inheritance
mechanism, setting the CodeFormat, and other details.
The most fundamental requirement for an embedded target is that it generate a real-time executable from a model or subsystem. Typically, an embedded target generates a timer interrupt-based, bareboard executable (although targets can be developed for an operating system environment as well).
Your target should support code generator concepts of single-tasking and multitasking solver modes for model execution. Tasking support is available with the ERT target, but you should thoroughly understand how it works before implementing an ERT-based target.
For information on timer interrupt-based execution, see Absolute and Elapsed Time Computation and Asynchronous Events.
You should generate the target executable's main program module, rather than using
a static main module (such as the static rt_main.c or
rt_cppclass_main.cpp module provided with the software). A
generated main.c or .cpp can be made much more
readable and more efficient, since it omits preprocessor checks and other extra
code.
For information on generated and static main program modules, see Deploy Generated Standalone Executable Programs To Target Hardware (Embedded Coder).
Follow the guidelines in Folder and File Naming Conventions.
Most cross-development systems run under a Microsoft® Windows® PC host. Your target should support the Windows operating system as the host environment.
Some cross-development systems support one or more versions of The Open Group UNIX® platforms, allowing for UNIX host support as well.
Your embedded target must support at least one embedded development environment. The interface to a development environment can take one of several forms. The toolchain approach and template makefile approach generate standard makefiles to work with your development environment. For general information about these build approaches, see Choose Build Approach and Configure Build Process. For detailed information about the structure of template makefiles, see Customize Template Makefiles.
It is important to consider the license requirements and restrictions of the development environment vendor. You may need to modify files provided by the vendor and ship them as part of the embedded target.
Your target should support a mechanism you can use to observe the target code as it runs in real time (outside of a debugger).
You can use the rtiostream API to implement a communication
channel to enable exchange of data between different processes. For an example of
creating a communication channel for target connectivity, see Create a Target Communication Channel for Processor-In-The-Loop (PIL) Simulation (Embedded Coder). This
rtiostream communication channel is required to enable
processor-in-the-loop (PIL) on a new target. See Communications rtiostream API (Embedded Coder).
One industry-standard approach is to use the CAN bus, with an ASAP2 file and CAN Calibration Protocol (CCP). There are several host-based graphical front-end tools available that connect to a CCP-enabled target and provide data viewing and parameter tuning. Supporting these tools requires implementation of CAN hardware drivers and CCP protocol for the target, as well as ASAP2 file generation. Your target can leverage the ASAP2 support provided with the code generator.
Another option is to support Simulink® external mode simulation. For more information, see the External Mode Simulations for Parameter Tuning and Signal Monitoring.
Device driver support is an important issue in the design of an embedded target. Device drivers are Simulink blocks that support either hardware I/O capabilities of the target CPU, or I/O features of the development board.
If you are developing a rapid prototyping target, consider providing minimal driver support, on the assumption that end users develop their own drivers. If you are developing a production target, you should provide full driver support.
See Device Drivers.
Automatic download of generated code to the target hardware makes a target easier
to use. Typically a debugger utility is used; if the chosen debugger supports command
script files, this can be straightforward to implement. STF_make_rtw_hook.m describes a mechanism to execute code from the build
process. You can use this mechanism to make system() calls to
invoke utilities such as a debugger. You can invoke other simple downloading utilities
in a similar fashion.
Executables that are mapped to RAM memory are typical. You can provide optional support for FLASH or RAM placement of the executable by using your target's code generation options. To support this capability, you might need multiple linker command files, multiple debugger scripts, and possibly multiple makefiles or project files. Also include the ability to automatically switch between these files, depending on the RAM/FLASH option value.
Select a popular, widely available evaluation or prototype board for your target processor. Consider enclosed and ruggedized versions of the target board. Also consider board level support for the various on-chip I/O capabilities of the target CPU, and the availability of development systems that support the selected board.