Build a Simulink model once and obtain a matched Linux runtime, A2L, Intel HEX, and INCA ProF flash package. The default path is a generic, offline Linux cross-build: it does not require a Raspberry Pi to be connected and it does not use the Raspberry Pi Support Package. The same model/code-generation path can target a Raspberry Pi, Orange Pi, Radxa, or another compatible Linux SBC.

The package integrates Vector XCPlite for XCP on TCP measurement, calibration pages, and virtual application flashing. It also includes an optional generic Linux GPIO library for target-specific hardware integration.

• Quick start
• What is generated
• Target and board portability
• Calibration and lookup tables
• Optional deployment
• INCA/CANape setup
• xcpWorkflow API reference
• Requirements and release protection

Open MATLAB in the project root and run one command. The first build can provision the selected compiler inside WSL; it never contacts a board.

cfg = xcpWorkflow("Model", "xcpMultiRateTest", ...
    "XcpHost", "192.168.1.50");  % address to use after deployment

xcpWorkflow generates C code with an unsaved generic ERT configuration, cross-compiles the staged application locally, then creates the calibration and flash artefacts. The saved .slx configuration is restored afterwards. No login script, stored username, password, or board connection is used.

For a second model, only the model name changes:

cfg = xcpWorkflow("Model", "xcpMultiRateTestV2", ...
    "Deploy", false, "Offline", true);

Every run writes a matched set to xcp_out/:

The runtime has one XCP DAQ event per generated Simulink task. It exports cycle/overrun/execution-time and per-core CPU diagnostics in addition to model measurements.

GenericErt=true (the default) builds with HardwareBoard=None and ert.tlc. It intentionally avoids Raspberry Pi Support Package code-generation hooks. Select an ABI profile appropriate to the Linux image that will run the result:

cfg = xcpWorkflow("Model", "myModel", "TargetProfile", "linux-armv7");
cfg = xcpWorkflow("Model", "myModel", "TargetProfile", "linux-x86_64");

The supplied profiles are linux-aarch64, linux-armv7, and linux-x86_64. A custom profile accepts the compiler and production-hardware settings explicitly. CPU architecture alone is not sufficient: use a sysroot matching the oldest intended target Linux distribution if GLIBC compatibility matters.

For GPIO, the reusable sbc/sbc_hardware_lib.slx library contains generic Linux character-device-v2 GPIO Read and GPIO Write blocks. They use /dev/gpiochipN and a kernel line offset, so the board header-to-line mapping belongs in a per-board JSON profile rather than in the model. See sbc/README.md.

Tunable parameters in the generated <model>_P structure become XCP calibration objects with working/reference calibration pages. The default filter removes generated dimensions and index bookkeeping.

For explicit standard 1-D and 2-D Lookup Table blocks whose breakpoint and table data are simple dialog parameter names, the exporter creates a linked A2L CURVE or MAP with AXIS_PTS references. INCA/CANape therefore opens one instrument named after the Simulink lookup block (for example, testNew), including its X axis and—where applicable—Y axis, rather than unrelated vector instruments named after generated storage variables. The calibration filter keeps referenced axes with their table so it cannot produce dangling A2L axis references.

Input-port tables/axes, parameter expressions, lookup-table objects, and lookups above two dimensions stay separate VAL_BLK objects. The workflow warns instead of claiming an incorrect calibration relationship.

A board is needed only to run, deploy, or validate the generated application. Set Offline=false and supply connection values directly in the command; they are not persisted by the project:

cfg = xcpWorkflow("Model", "xcpMultiRateTest", ...
    "Offline", false, "Deploy", true, ...
    "PiHost", "192.168.1.50", ...
    "PiUser", "target-user", ...
    "PiPassword", "your-password", ...
    "PiAppDir", "/opt/xcp_app", ...
    "XcpHost", "192.168.1.50");

PiHost is only the SSH/deployment endpoint; XcpHost is the XCP address written into the A2L and may differ. The legacy Pi* option names work for any supported Linux SBC. Remote native build is also available explicitly with "BuildMode", "remote", but the normal portable workflow is local cross-build.

Call cfg = xcpWorkflow("Name", Value, ...). Option names are case-sensitive. The returned cfg contains resolved paths, toolchain selection, discovered tasks, EPK, and generated artifact paths.

• MATLAB/Simulink R2024b and Embedded Coder.
• Windows with a Debian/Ubuntu WSL distribution for the default cross-build, or a native compiler selected through LocalBuildRunner.
• A compiler appropriate to the target profile. With the defaults, the workflow can provision it automatically in WSL.
• A Linux SBC and SSH only when deploying/running the result.
• INCA or CANape to import the generated A2L/HEX and calibrate/flash over XCP.

Release copies protect the workflow implementation with MATLAB P-code created using pcode(..., "-R2022a", "-inplace"), the latest P-code compatibility format offered by MATLAB R2024b. Public invocation, C templates, model files, and the generic SBC hardware library remain readable and adaptable. P-code is an obfuscation mechanism, not a substitute for a license or trust boundary.

xcpWorkflow.m              Public one-command entry point
workflow/                   P-coded release implementation and C templates
external/XCPlite/           Pinned XCPlite source used offline
sbc/                        Generic Linux GPIO library, C HAL, and profiles
*.slx                       Example Simulink models
modelParams.m               Example model initialisation values

Generated folders (xcp_build/, xcp_out/, slprj/, and *_ert_rtw/) are not part of the source distribution and are ignored by Git.