Choose an External Code Integration Workflow - MATLAB & Simulink (original) (raw)

Main Content

Software projects typically involve combining code from multiple sources. A typical system structure for a code generation application consists of a framework that combines code from multiple sources, including external code (legacy and custom code) and code generated from Simulink® models.

This figure shows an application that requires integration of existing driver code for hardware devices. The core software algorithms and logic can be a combination of code modules for external reusable algorithms integrated into the Simulink environment and code generated as part of an overall model design.

Completing these tasks helps you choose external code integration workflows and tooling that align with your project.

Choose a Software Execution Framework for Scheduling Code Execution

The code generator supports two types of software execution frameworks—single top model and multiple top-level. The first question to answer concerns which of the two frameworks meets the scheduling and other needs of your project. For example, you can import external code into a single, rate-based top model. You can export code from a single top model or multiple top-level models for integration with custom (external) scheduling mechanisms.

Importing calls to external device driver code into a model and generating code for that model for export involves importing and exporting code.

Based on goals and requirements, external code integration is characterized in several ways, requiring different workflows and integration tooling:

Next, see Evaluate Characteristics of External Code.

Evaluate Characteristics of External Code

Before choosing an external integration workflow, evaluate these characteristics of the external code. To interface with external code, generated C or C++ code handles one or more of the external code characteristics. An understanding of these characteristics and your requirements for modeling, simulation, and code generation helps you choose the optimal workflow for your integration scenario. (See Identify Integration Requirements.)

Characteristic What to Consider
Hardware dependency Is the external code hardware-dependent? Utility functions, lookup tables, and filters are examples of hardware-independent code.Device drivers interact directly with hardware. They depend on characteristics of the hardware. For example, a device driver for an analog-to-digital converter initializes, reads data from, and writes data to hardware registers. Hardware differences and dependencies concern data type size, endianess, shift operations, compiler directives, and optimized function and operator support. Other code interfaces with device drivers by using an API and data mapped to specific memory addresses. Typically, simulation on a development computer is not possible. Reading from and writing to a register during simulation on a development computer produces unexpected and unwanted results.
Reusable Is the external code a reusable software module? Examples include utility functions, lookup tables, filters, specialized integrators, and proportional-integral-derivative (PID) control modules.
Dependency on data persistence between function calls Does the external code require persistent data? For example, a call to a first order filter function uses the output of the previous call to the function to calculate a new output value. You have the option of defining the data as global or using shared memory outside the context of the function.
Data typing and interface How complex is the data that the external code uses? What does the data interface look like? It consists of arguments, a return value, global variables, and access functions. What data types does the code use? Are the types limited to basic ANSI C integers, floating-point types, arrays of integers or floating-point types, and pointers to these types? Does the interface include structures or pointers to structures?
Fixed-point code Is the external code designed to run on integer-only processors? If yes, the code exchanges and uses data represented as integers only. Data can be associated with fixed-point scaling or offsets.
External resource dependencies Does the external code use data, functions, or macros defined outside the scope of the code? For example, the function can use a standard ANSI function, a shared library, or predefined constants. In these cases, you must inform the compiler and linker of the paths and file names of the external resources.
External solver required Are you using the external function for advanced development or rapid prototyping to describe a system with a continuous transfer function or a set of differential equations? If yes, the external code relies on an external solver.

Next, see Identify Integration Requirements.

Identify Integration Requirements

Before choosing an external integration workflow, review these integration requirements. An understanding of these requirements and the characteristics of your external code helps you choose the optimal workflow for your integration scenario. (See Evaluate Characteristics of External Code.)

Requirement What to Consider
Effort What level of effort is planned for the integration project—low, medium, or high?
Learning effort What is the programming experience of assigned project resources? How much experience do assigned resources have with Simulink and MathWorks® C/C++ code generation products?
Simulation and code generation behaviors Do you want to take advantage of Model-Based Design? To take full advantage of Model-Based Design, convert code to modeling elements, which you can then use in the Simulink and Stateflow® simulation environment. Then, simulate and generate code for the integrated component. Use software-in-the-loop (SIL) or processor-in-the-loop (PIL) testing to verify whether algorithm behavior is the same in both environments.
Data interface and typing Does your model or generated code need to exchange data with the external function? If so, map inputs, outputs, and parameters to the external function interface. Typical function interfaces involve function arguments and return values, global variables, and access functions, such asgetRPM.Do you want to represent arrays, structures, or enumerated types? In the Simulink environment, you can represent these types as vectors, buses, and IntEnum, respectively. Is fixed-point support required? If you use the Simulink fixed-point interface, you can scale and specify offsets. Does the external code use company-specific data types? If yes and you have Embedded Coder software, create alias types to represent those external types. The code generator uses the alias types in the code that it produces. For example, once defined, you can specify an alias type in a function prototype, for a temporary variable, or for block output. Does the code exchange data with shared memory? If yes, define and use memory sections.
Direct function call Do you want to call C external code directly from a model? You can choose from mechanisms, such as the C Function block, the C Caller block, Legacy Code Tool, Stateflow external code interface and chart action language, and the MATLAB® Function block.
Insertion of external code into generated code Do you want to control the placement of external code within generated code? Do you want to insert code into generated entry-point functions? You can place code within generated code by using model configuration parameters or custom code blocks.
Code generation optimization support Do you want to optimize the code that the code generator produces? If so, you can configure the model for the code generator to optimize the code it produces based on application objectives, such as execution, ROM, and RAM efficiency. You also have the option of using code replacement libraries.
Files required Do you want to minimize the number of files that you maintain? Some external code integration tools require that you maintain separate files for defining simulation and code generation.

Next, see Choose a Workflow.

Choose a Workflow

To choose a workflow for integrating external code into the Simulink environment, use the following table with links to more information.

Goal Action More Information
Call hardware-independent reusable external algorithmic code from generated code. For example: utility functions, lookup tables, and digital filters. Choose an approach for integrating external code into the Simulink environment for code generation based on your programming language and other integration requirements. Call Reusable Hardware-Independent External Code for Simulation and Code Generation
Call hardware-dependent external reusable external algorithmic code from generated code. For example: device drivers. Call external driver code from the Simulink environment. Call External Device Drivers
Place external C/C++ code in generated code. Augment functions with external code using model configuration parameters or custom code blocks. Place External C/C++ Code in Generated Code
Change the code that the code generator produces for functions and operators to meet application code requirements. Use code replacements to specify application-specific implementations of functions and operators. Code Replacement

See Also

Topics