Configure Generated C Function Interface for Model Entry-Point Functions - MATLAB & Simulink (original) (raw)

What Is an Entry-Point Function?

An entry point is a location in code where a transfer of program control (execution) occurs. The main function (main()) is the entry point to a C/C++ program and is called when the application starts executing. Calls to other functions, for example from the main function, provide entry points to function code. Program control is transferred to the called function. The function code executes, and when finished, returns control to the main or other calling function.

When producing code for a model, the code generator defines a set of entry-point functions that you can call to execute the generated code. You can call the generated functions from external code or from a version of the generated main function that you modify.

The Code Interface Report section of the code generation report lists the entry-point functions that the code generator produces for a model. For more information, see Analyze Generated Data Code Interface Report.

Types of Generated Entry-Point Functions

The code generator produces entry-point functions for these types of model functions.

If you have Embedded Coder software, to facilitate integration of external and generated code and achieve compliance with code standards and guidelines, you can configure how the code generator produces function interfaces from a model or subsystem.

Configure Reusability of Entry-Point Functions

By default, top models generate code that is not reusable or reentrant. Entry-point functions have a void-void interface. Code communicates with other code by directly accessing global data structures that reside in shared memory.

If your application requires reusable, multi-instance entry-point function code, you can configure the code generator to call each function (instance) with unique data. In this case, the code is reentrant.

You configure whether entry-point functions are reusable with the model configuration parameter Code interface packaging (component) and related parameters. The parameter settings that you choose depend on factors such as configuration selections for the system target file, programming language, and argument interface.

Default Configurations for Single-Instance C Entry-Point Functions

By default, for GRT- and ERT-based system target files, the code generator produces single-instance C entry-point functions. The generated code:

• Creates an execution function without arguments (void-void).
• Allocates memory statically (at compile time) for model data structures.

The default model configuration parameter settings for configuring single-instance entry-point function code are:

• Language set toC.
• Code interface packaging (component) set to Nonreusable function.

Generate Reusable, Multi-Instance C Entry-Point Functions

You can configure the code generator to produce reusable entry-point functions in C for either a GRT- or ERT-based system target file. However, the function interfaces that the code generator produces by default varies. Assuming that model configuration parameter Language is set to C and Code interface packaging (component) is set to Reusable function, the code generator produces this entry-point function code for each system target file scenario.

If you are using an ERT-based system target file and want to generate reusable, multi-instance C entry-point functions that are reentrant, consider:

• Using dynamic memory allocation to initialize model data structures. Select Use dynamic memory allocation for model initialization.
• Packing values of model root-level Inport blocks into a structure, packing values of root-level Outport blocks into a second structure, and passing the structures to the execution function as arguments by reference. Set Pass root-level I/O as to Structure reference.
• Packing values of model root-level Inport blocks andOutport blocks into the real-time model data structure and passing that structure to the execution function as an argument by reference. Set Pass root-level I/O as to Part of model data structure.

Configure Reusability of Model Reference Entry-Point Functions

By default, model references generate code that is reusable and reentrant. The code generator calls each referenced model function with unique data.

You can configure whether a referenced model entry-point function is reusable with the model configuration parameter Code interface packaging (subcomponent).

By default, nonreusable model references generate code that passes root-level I/O data to entry-point functions as function arguments. If you are using an ERT-based system target file, consider eliminating function arguments by passing root-level I/O data as global variables. Set the model configuration parameter Implement root-level I/O as to Global variables.

Choose an Approach for Configuring Generated C Function Interfaces

To facilitate integration of external and generated code and achieve compliance with code standards and guidelines, you can use the Code Mappings editor or code mappings API to configure how the code generator produces function interfaces from a model or subsystem.

For models configured with a service interface, you can configure:

• Function name
• Function arguments for functions in subcomponents and functions in component models that are represented as Simulink Function blocks
• Memory section

You can use software-in-the-loop (SIL) testing to verify code generated for customized entry-point functions. Create a SIL block by using your generated code. Then, integrate the SIL block into a model to verify that the generated code provides the same result as the original model or nonvirtual subsystem. For more information, see Choose a SIL or PIL Approach.

Configure Default Code Generation Settings for a Function Category

Reduce the effort of preparing a model for C code generation by specifying default configurations for categories of functions across a model. For example, you can configure function name rules and placement of function code in memory sections. Applying default configurations can save time and reduce the risk of introducing errors in code, especially for models that have a large number functions.

The code generator produces entry-point functions for these categories of model functions:

Configure default code mappings for functions by using the Code Mappings Editor – C or code mappings API function setFunctionDefault. Using these interfaces, you can associate a function category with a function customization template defined in the model's Embedded Coder Dictionary.

If your application requires that you configure the placement of entry-point functions in memory, for example, to optimize the generated code for specific hardware, you can apply a default memory section to a category of functions across a model. In the Code Mappings editor, map a function category to a function customization template that is defined to use a specific memory section. See Create Function Customization Template.

If a function customization template does not exist, you can create one by using the Embedded Coder Dictionary (see Define Service Interfaces, Storage Classes, Memory Sections, and Function Templates for Software Architecture).

For an example of how to configure default configurations for function categories, seeConfigure Default C Code Generation for Categories of Data Elements and Functions.

Configure Names for Individual C Entry-Point Functions

For your generated C code to adhere to code standards and guidelines or to more easily integrate that code with external code, you can configure the name of an individual entry-point function. For example, you can name the initialize function generated for a modelmyInitFunc.

If your model meets at least one of these criteria, consider configuring the names of functions individually:

• Uses multiple functions that have unique naming requirements.
• Uses few functions.
• Has a default configuration for a function category and you need to override the configuration for a specific function.

Configure function names for individual step functions by using the Code Mappings editor or code mappings API function setFunction. Using these interfaces, you can associate a function with a function customization template that is defined in the model's Embedded Coder Dictionary and specify a function name.

This example shows how to change the name of the initialize function for model ConfigurationInterface.

1. Open the model.
   openExample('ConfigurationInterface')
2. Open the Embedded Coder app.
3. On the C Code tab, select > .
4. In the Code Mappings editor, Functions tab, change the function name by using one of these methods:
   • In the Function Name column, enter a name for the function.
   • In the Function Preview column, click the function prototype hyperlink to open a configuration dialog box. In the C Initialize Function Name field, enter the function name. ClickApply to verify the change in the C function prototype field or click OK to exit the dialog box and view the function name in the Function Preview column of the Code Mappings editor.
     For this example, change the name of the initialize function tofcnprotoctrl_init.
5. Save the model.
6. Generate code.
7. Verify the changes in the generated code. In the Code view, find instances of function name fcnprotoctrl_init. The function name appears in generated files ConfigurationInterface.h andConfigurationInterface.c.
   • In ConfigurationInterface.h:
     extern void fcnprotoctrl_init(void);
   • In ConfigurationInterface.c:
     void fcnprotoctrl_init(void)
     {
     ...
     }

Configure Name and Arguments for Individual Step Functions

For your generated C code to adhere to code standards and guidelines or to more easily integrate the code with external code, you can configure the name and arguments of individual step functions generated for Simulink periodic functions. You can customize these aspects of a step function:

• Function name
• Argument names
• Order of the arguments
• Return value and argument data qualifiers
• Buffering optimizations for arguments

If your model meets at least one of these criteria, consider configuring the name and arguments of a step function individually:

• Is a periodic, single-tasking model for which the code generator produces one step function.
• Has a default configuration for Execution function category and you need to override the configuration for a specific step function.

Configure code mappings for individual step functions by using the Code Mappings editor or code mappings API function setFunction. Using these interfaces, you can associate a function with a function customization template that is defined in the model's Embedded Coder Dictionary and completely customize the step function prototype.

This example shows how to customize the step function name and arguments for a rate-based, single-tasking model.

Open the Configuration Dialog Box

1. Open the model AtomicSubsystem.slx.

open_system("AtomicSubsystem");

2. Open the Embedded Coder app. Press Ctrl+D to update the model.

3. On the C Code tab, select Code Interface > Individual Element Code Mappings.

4. In the Code Mappings editor, click the Inports tab. Notice inports are mapped to Auto storage class. Click the Outports tab. Notice outports are also mapped to Auto storage class. To customize generated C function interfaces, root-level inports and outports must be configured to use Auto for the storage class.

5. Click the Functions tab.

6. For the step function row, in the Function Preview column, click the prototype hyperlink to open the Configure C Step Function Interface dialog box.

In the Configure C Step Function Interface dialog box, the C function prototype field displays a preview of changes that you make to the function prototype.

For models configured to generate multi-instance code, see Generate Reentrant Code from Top Models.

Customize the Function Name

1. In the Configure C Step Function Interface dialog box, set C Step Function Name to atomicsubsystem_run. The function preview is updated to reflect the new function name.

2. Click Apply, close the dialog box, and save the model.

3. Generate code and verify the name change.

• Click the Code tab. In the Code view file list, select file AtomicSubsystem.h. In the Search field, verify that the list of code elements includes function name atomicsubsystem_run. To view the declaration, select the function name.

The declaration is highlighted in the code:

• Verify the name change in file AtomicSubsystem.c. To view the source code (definition), in the Search field, select atomicsubsystem_run.

For more examples, see Configure Names for Individual C Entry-Point Functions.

Customize Function Arguments

Configure Global Data Structures

By default, a top or referenced model uses a void-void step function to pass data. This type of function enables generated code to communicate with external code by accessing global data stored as data structures that reside in shared memory.

To configure a model to have a void-void step function, open the Configure C Step Function Interface dialog box and clear the Configure arguments for Step function prototype check box. Verify the change in the C function prototype preview.

Configure Arguments

Rate-based model step functions can use arguments to pass data. You can customize these argument settings:

• Return value
• Type qualifiers
• Names
• Order

Example

1. Open the Configure C Step Function Interface dialog box. In the Code Mappings editor, click the Functions tab. Then, click the function preview for the step function.

2. In the Configure C Step Function Interface dialog box, select Configure arguments for Step function prototype.

3. Click Get default. The dialog box expands to show a field for configuring the function return value and a table that lists input and output arguments with default settings.

4. Customize the return value of the step function. Set C return argument to either void or one of the output arguments. For this example, select void.

5. For each argument, specify a C Type Qualifier.

Type Qualifiers:

• Value: Value, for example, arg
• Const: Value with the const qualifier, for example, const arg
• Pointer to const: Value with const qualifier and referenced by pointer, for example, const * arg
• Pointer: Reference by pointer, for example, * arg
• Const pointer to const: Value with const qualifier, reference by pointer, and the pointer itself, for example, const * const arg

Models that include a referenced model

• For a referenced model, the type qualifier for a root input argument in the step function interface is set to Auto. The code generator uses the interface specification by generating a type cast that discards the const qualifier from the source signal.
• For the parent of the reference model, the type qualifier for the source signal is set to a value other than Auto. To override this behavior, add a const type qualifier to the referenced model.

For this example, make no changes to the C type qualifier.

6. Customize the argument names by editing values in the C Identifier Name column.

For this example, change the names of the arguments by removing the underscores after arg, for example, change arg_In1_1s to argIn1_1s.

7. Customize the argument order by dragging table rows to new positions.

For this example, move Out1 to the second position.

8. Validate, apply your changes, close the dialog box, and save the model.

9. Generate code and verify the changes in the Code view.

• Verify your changes in file AtomicSubsystem.h by checking that the Search field includes function atomicsubsystem_run.To view the function declaration, select the function name.

• Verify your changes in file AtomicSubsystem.c.To view the definition for the function, select function name atomicsubsystem_run.

Prototype Different from Preview

In the Configure C Step Function Interface dialog box, the function prototype preview for a referenced model can show fewer arguments than the function prototype in the generated code.

For example, consider a model named mdlref_counter with an inport (arg_input), an outport (arg_output), and a saturation block with limits that have workspace parameter argument names lower_saturation_limit and upper_saturation_limit. The Configure C Step Function Interface dialog box shows a function prototype preview as:

mdlref_counter_custom(arg_input, arg_output)

In the generated code, the prototype includes the parameter arguments:

mdlref_counter_custom(real_T arg_input, real_T arg_output, real_T rtp_lower_saturation_limit, real_T rtp_upper_saturation_limit)

Optimize Buffering for Arguments

You can optimize the buffering required for I/O arguments in the step function for a model. If you adhere to these requirements when configuring an inport and outport pair, the code generator merges the corresponding arguments and reuses the associated buffer.

• The Inport and Outport blocks must have the same properties, including data type, dimension, and sample rate.
• The sample rate of the Inport and Outport blocks must be the same as the base rate of the model.
• A conditionally executed subsystem cannot drive the Outport block.
• A single, nonvirtual block output must drive the Outport block. For example, a Mux block, which merges multiple buffers, cannot drive the Outport block.
• In the Configure C Step Function Interface dialog box, you must configure the Inport and Outport with the same C type qualifier and identifier name.

This section shows how to merge arguments for ports In1_1s and Out1 for example model AtomicSubsystem.

1. Open the Configure C Step Function Interface dialog box for the model AtomicSubsystem.

2. Open the display for the arguments by selecting Configure arguments for Step function prototype.

3. For ports In1_1s and Out1, set C Type Qualifier to Pointer and C Identifier Name to sharedArg.

4. Verify that the preview shows the merged argument for In1_1s and Out1.

5. Validate, apply your changes, close the dialog box, and save the model.

6. Generate and view the code. In the Code view, search for the atomicsubsystem_run function and check the function interface. For this example, the shared argument appears in read code for the Inport block and write code for the Outport block.

In the example main ert_main.c of this example, if a value is not assigned to sharedArg before calling atomicsubsystem_run, the output value assigned to sharedArg from the previous run of atomicsubsystem_run is used as the input value. To set appropriate input values for this example, modify the generated function rt_OneStep in ert_main.c and assign values for sharedArg and argIn_2s as needed.

Configure Code Generation Settings for C Entry-Point Functions Programmatically

To automate configuration of model functions for C code generation, use the programming interface for code mappings. For example, when creating custom block libraries or part of an application test environment, use the programming interface to automate function configuration.

Typical uses of these functions include:

• Create a function interface.
• Modify an existing function interface.
• Create a function interface, starting with default configuration information from a model.
• Reset the model function interface to the default ERT function configuration.

For an example of how to configure code generation settings for C entry-point functions programmatically, see Configure Default Data and Function Code Generation Programmatically. That example shows how to configure default settings for function categories and individual functions.

How to Interface with Generated Entry-Point Functions

1. After generating code for a model, use the Code view to review the generated entry-point functions and, if applicable, variables representing external input and output ports.
2. Add #include statements to your external code that include the generated header files that declare the model entry-point functions.
3. Add an #include statement that includes the generated filertwtypes.h. This file provides type definitions,#define statements, and enumerations.
4. Initialize target-specific data structures and hardware, such as ADCs or DACs.
5. If applicable, initialize data for each instance of a reusable model.
6. If applicable, write input data to generated variables that represent model Inport blocks.
7. Call the generated entry-point functions or set up use of thert_OneStep function.
8. If applicable, read data from generated variables that represent model Outport blocks.

For more information, see Deploy Applications to Target Hardware.

C Function Interface Customization Limitations

These limitations apply to customizations for generated C function interfaces:

• You must select the model configuration parameter Single output/update function.
• Multirate models are supported, but you must configure the models for single tasking.
• You must configure root-level inports and outports to use theDefault storage class.
• If you choose to customize a function interface, you must provide your own custommain program. You cannot configure the function interface with the static rt_main.c that MathWorks® provides. Specifying a function interface configuration other than the default creates a mismatch between the generated code and the default staticrt_main.c.
• The code generator removes the data structure for the root inports of the model unless a subsystem implemented by a nonreusable function uses the value of one or more of the inports.
• The code generator removes the data structure for the root outports of the model except when you enable MAT-file logging or if the sample time of one or more of the outports is not the fundamental base rate (including a constant rate).
• If you copy a subsystem block to create a block in a new model or the same model, the function interface information from the original subsystem block is not copied to the new subsystem block.
• If you have Stateflow®, for a Stateflow chart that uses a model root inport value or that calls a subsystem that uses a model root inport value, do one of the following to generate code:
  • Clear the Execute (enter) Chart At Initialization check box in the Stateflow chart.
  • Make the Stateflow function a nonreusable function.
  • Insert a Simulink® Signal Conversion block immediately after the root inport. In theSignal Conversion block parameters dialog box, selectExclude this block from 'Block reduction' optimization.
• If a model root inport value connects to a Simscape™ conversion block, insert a SimulinkSignal Conversion block between the root inport and the Simscape conversion block. In the Signal Conversion block parameters dialog box, select Exclude this block from 'Block reduction' optimization.
• When building a referenced model that is configured with a function interface, do not use virtual buses as inputs or outputs to the referenced model. Use nonvirtual buses instead.
• If the C function interface is not the default, the value is ignored for the model configuration parameter . For more information, see Pass fixed-size scalar root inputs by value for code generation.

See Also

Simulink Function | Function Caller

Topics

• C Data Code Interface Configuration for Model Interface Elements
• Configure Default C Code Generation for Categories of Data Elements and Functions
• Simulink Function Blocks and Code Generation