Real-Time Workshop

Inlined and Noninlined Drivers

In your target system, a device driver has a dual function. First, it functions as a code module that you compile and link with other code generated from your model by Real-Time Workshop. In addition, the driver must interact with Simulink during simulation. To meet both these requirements, you must incorporate your driver code into a Simulink device driver block.

You can build your driver S-function in several ways:

• As a MEX-file component, bound to an S-Function block, for use in a Simulink model. In this case, the Simulink engine calls driver routines in the MEX-file during execution of the model.
• As a module within a stand-alone real-time program that is generated from a model by Real-Time Workshop. The driver routines are called from within the application in essentially the same way that Simulink calls them.

• In many cases, the code generated from driver blocks for real-time execution must run differently from the code used by the blocks in simulation. For example, an output driver may write to hard device addresses in real time; but these write operations could cause errors in simulation.

  Real-Time Workshop provides standard compilation conditionals and include files to let you build the drivers for both cases. (See Conditional Compilation for Simulink and Real-Time.)

• As inlined code. The Target Language Compiler enables you to generate the explicit code from your routines (instead of calls to these routines) in the body of the application. Inlined code eliminates calling overhead, and reduces memory usage.

Inlining an S-function can improve its performance significantly. However, there is a tradeoff in increased development and maintenance effort. To inline a device driver block, you must implement the block twice: first, as a C MEX-file, and second, as a TLC program.

The C MEX-file version is for use in simulation. Since a simulation normally does not have access to I/O boards or other target hardware, the C MEX-file version often acts as a "dummy" block within a model. For example, a digital-to-analog converter (DAC) device driver block is often implemented as a stub for simulation.

Alternatively, the C MEX-file version can simulate the behavior of the hardware. For example, an analog-to-digital converter (ADC) device driver block might read sample values from a data file or from the MATLAB workspace.

The TLC version generates actual working code that accesses the target hardware in a production system.

Inlined device drivers are an appropriate design choice when:

• You are using the Real-Time Workshop Embedded Coder target. Inlined S-functions are required when building code from the Real-Time Workshop Embedded Coder target. S-functions for other targets can be either inlined or noninlined.
• You need production code generated from the S-function to behave differently than code used during simulation. For example, an output device block may write to an actual hardware address in generated code, but perform no output during simulation.
• You want to avoid overhead associated with calling the S-function API.
• You want to reduce memory usage. Note that each noninlined S-function creates its own Simstruct. Each Simstruct uses over 1K of memory. Inlined S-functions do not allocate any Simstruct. For optimal memory usage, consider using inlined S-functions with the Real-Time Workshop Embedded Coder target.
• You want to avoid making calls to routines that are required by Simulink, but which are empty, in your generated code.

Creating Device Drivers

Device Driver Requirements and Limitations