C Function Block Configuration

When to Use

• Calling or wrapping C/C++ code or libraries in Simulink
• Creating, configuring, or using a C Function block
• Integrating custom code, legacy code, or external C/C++ into a model
• Integrating a C++ class into a Simulink model or test bench
• Configuring inputs, outputs, or parameters for a C++ algorithm in a block

When NOT to Use

• Building general Simulink models without C/C++ integration
• MATLAB Function blocks (Embedded MATLAB), those use MATLAB syntax, not C/C++
• Code generation workflows (Embedded Coder, Simulink Coder), this skill is for simulation-time configuration only

Rules

• Derive each symbol's Simulink type from the corresponding C/C++ function parameter/return type (e.g. float → single, bool → boolean, char*/char[] → string (R2024b+)). However, when replacing an existing block (e.g. an S-Function), use the types already on that block first, for example, what looks like int32 from C may actually be fixdt(1,32,3) or another fixed-point type in the existing model.
• MANDATORY for C++ classes: When the user's code defines a C++ class, you MUST first attempt to declare a Persistent symbol of Class: ClassName and call class methods directly in the code sections (e.g. obj.Method(args)). If the class has an init method (not a constructor), call it in StartCode. Only fall back to wrapper/handler functions or opaque pointer patterns if the class approach fails to compile.
• Prefer relative paths for custom code files (sources, headers, libraries, search directories). Use paths relative to the model file location (e.g. 'myFunctions.h', './src/myLib.cpp') rather than absolute paths. This ensures portability across machines and users.

Workflow Overview