Choose an External Code Integration Workflow

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

Task	Action	More Information
1	Partition your application, map algorithms to components, and identify integration points.	Design Models for Generated Embedded Code Deployment
2	Determine whether you can rely on scheduling code that the code generator produces, or whether you must integrate generated code with scheduling mechanisms that are specific to your run-time environment.	Choose a Software Execution Framework for Scheduling Code Execution
3	Evaluate the characteristics of the external code that you are importing or to which you are exporting generated code.	Evaluate Characteristics of External Code
4	Identify integration requirements, which assists with choosing optimal tooling for your integration.	Identify Integration Requirements
5	Based on the results of tasks 1–4, choose a workflow.	Choose a Workflow

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, as described in Design Models for Generated Embedded Code Deployment. 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.

Single top model
Generate one set of application code files from external code and code that the Simulink^® C/C++ code generator produces. The generated code includes a scheduler. In this case, you import code into the Simulink code generation environment.
Single top model or multiple top-level models
Integrate C or C++ code that the code generator produces from model components with external application code and an external scheduler. You export generated code from the Simulink code generation environment.

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:

Import existing external code into generated code.
- Call reusable external algorithm code for simulation and code generation.
- Place external C/C++ code in generated code.
- Call external device drivers.
- Apply function and operator code replacements.
- Interface with external timer interrupt or scheduler.
- Generate replacement code for specific run-time environment.
Export generated code for inclusion in external code base. Requires Embedded Coder^® .
- Generate component source code for export.
- Generate shared library for export.

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 as `getRPM`. 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 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 each integration point, use the following flow diagram . The gray boxes identify common workflows and provide links to more information. Click the gray box that best addresses the requirements of an integration point.

Documentation