| Target Language Compiler | |
Writing Block Target Files to Inline S-Functions
With C MEX S-functions, all targets except ERT will support calling the original C MEX code if the source code (.c file) is available when Real-Time Workshop enters its build phase. For S-functions that are in Fortran or .m, you must inline them in order to have complete code generation for Simulink models that contain them. Additionally, once you have determined that you will inline an S-function, you must decide to either make it fully inlined or wrappered.
Fully Inlined S-Functions
The block target file for a fully inlined S-function is a self-contained definition of how to inline the block's functionality directly into the various portions of the generated code -- start code, output code, etc. This approach is most beneficial when there are many modes and data types supported for algorithms that are relatively small or when the code size is not significant.
Function-Based or Wrappered Code Generation
When the physical size of the code needed for a block becomes too large for inlining, the block target file is written to gather inputs, outputs, and parameters, and make a call to a function that you write to perform the block functionality. This has an advantage in generated code size when the code in the function is large or there are many instances of this block in a model. Of course, the overhead of the function call must be considered when weighing the option of fully inlining the block algorithm or generating function calls.
If a decision has been made to go with function-based code generation, there are two more options to consider:
.c file(s) and have the TLC code's BlockTypeSetup method specify external references to your support functions. Use LibAddToModelSources for names of the modules containing the supporting functions. This approach is usually done using one function per file to get the smallest executable possible.
Start and Outputs will also conditionally generate more functions in separate code generation buffers to be written to a separate .c file that contains customized versions of functions (data types, widths, algorithms, etc.), but only the functions needed by this model instead of all possible functions.
Either approach can produce optimal code. The first option can result in hundreds of files if your S-function supports many data types, signal widths and algorithm choices. The second approach is more difficult to write, but results in a more maintainable code generation library and the code can be every bit as tight as the first approach.
For further information on wrapping, see Wrapper Inlined S-Function Example, the tutorial Wrapping User Code with TLC, and Writing Wrapper S-Functions in Writing S-functions documentation.
| | Inlining S-Functions | Inlining C MEX S-Functions | |