Choose an External Code Integration Workflow
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 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.
|Partition your application, map algorithms to components, and identify integration points.
|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.
|Evaluate the characteristics of the external code that you are importing.
|Identify integration requirements, which assists with choosing optimal tooling for your integration.
|Based on the results of tasks 1–4, 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. 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.
For more information on exporting generated code, see Callable Function Integration.
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.)
|What to Consider
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.
|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?
|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.)
|What to Consider
|What level of effort is planned for the integration project—low, medium, or high?
|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
|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.
|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.
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 hardware-dependent external reusable external algorithmic code from generated code. For example: device drivers.
|Call external driver code from the Simulink environment.
|Place external C/C++ code in generated code.
|Augment functions with external code using model configuration parameters or custom code blocks.
|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.
- Call Reusable External Algorithm Code for Simulation and Code Generation
- Place External C/C++ Code in Generated Code
- Call External Device Drivers
- Deploy Generated Component Software to Application Target Platforms
- Code Replacement
- Generate Component Source Code for Export to External Code Base
- Generate Shared Library for Export to External Code Base