Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Deploy MATLAB-generated code to embedded hardware using Embedded Coder. Use when configuring code generation for microcontrollers (STM32, Raspberry Pi, ARM Cortex), setting up PIL/SIL verification, disabling dynamic memory allocation, or configuring hardware-specific code generation settings. Covers ERT-based configurations, processor-in-the-loop testing, memory constraints, and the MEX→SIL→PIL verification progression.
.claude/skills/matlab-matlab-deploy-embedded-code/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 59% | 0% |
| case-01 | ✗→✓ | ▲ Improved | 41% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -13% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 15% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 99% | 0% |
Configure MATLAB Coder with Embedded Coder for production-quality code generation targeting embedded hardware, and verify correctness with processor-in-the-loop (PIL) testing.
codegen workflowsmatlabcfg = coder.config("lib", "ecoder", true);
The "ecoder", true flag creates an ERT-based (Embedded Real-Time) configuration that generates production-quality code with no OS dependencies.
With coder.hardware:
matlabcfg.Hardware = coder.hardware("STM32F746G-Discovery");
Without the support package, configure hardware manually:
matlabcfg.HardwareImplementation.ProdHWDeviceType = 'ARM Compatible->ARM Cortex-M'; cfg.HardwareImplementation.ProdBitPerFloat = 32; cfg.HardwareImplementation.ProdBitPerDouble = 64;
See references/supported-hardware.md for the full list of supported boards and their constraints.
matlabcfg.EnableDynamicMemoryAllocation = false; cfg.StackUsageMax = 512;
EnableDynamicMemoryAllocation = false — disables malloc/free for targetswhere heap is unavailable or non-deterministic. All arrays must be bounded at compile time.
StackUsageMax — set based on target SRAM. The code generation report showsactual usage after compilation.
For entry-points that use deep learning inference (invoke, predict):
matlabcfg.DeepLearningConfig = coder.DeepLearningConfig('none'); cfg.LargeConstantGeneration = "KeepInSourceFiles";
DeepLearningConfig('none') — generates C with no external DL library dependencies(MKL-DNN, cuDNN, TensorRT). Required for bare-metal targets. Without this, codegen may attempt to link an unavailable library and fail.
LargeConstantGeneration = "KeepInSourceFiles" — keeps weight constants in sourcefiles rather than separate data files. Needed for bare-metal targets where external data file linking is unsupported.
SIMD vectorization — generates vectorized code for the target ISA:
matlabcfg.InstructionSetExtensions = 'Neon v7'; % ARM Cortex-A (128-bit, 4x float32)
| Target | Value | Notes | |--------|-------|-------| | ARM Cortex-A (Raspberry Pi) | 'Neon v7' | 128-bit SIMD | | Intel x86-64 | 'SSE', 'SSE4.1', 'AVX', 'AVX2', 'AVX512F' | Match target CPU | | ARM Cortex-M | Do not set — use CodeReplacementLibrary instead | Different mechanism |
Code replacement library (CRL) — routes supported ops to compiler-vendor optimized implementations (NEON on ARM, etc.). Complementary to InstructionSetExtensions on ARM Cortex-A:
matlabcfg.HardwareImplementation.ProdHWDeviceType = 'ARM Compatible->ARM Cortex-A'; cfg.CodeReplacementLibrary = 'GCC ARM Cortex-A';
For Cortex-M, select the CRL matching your compiler (e.g. 'ARM Cortex-M' for generic; vendor-specific CRLs are shipped with the corresponding support package). Cortex-M does not use InstructionSetExtensions.
OpenMP multi-threading — enables parallel loops in generated code:
matlabcfg.EnableOpenMP = true; % multi-core targets (Cortex-A, x86) cfg.EnableOpenMP = false; % single-core targets (Cortex-M) — no OS/threading support, won't compile
MATLAB Coder vs Simulink Coder naming. Several properties above have different names when configuring the same option via set_param on a Simulink model:
| MATLAB Coder (cfg.X = ...) | Simulink Coder (set_param) | Notes | |---|---|---| | EnableOpenMP | MultiThreadedLoops | Valid on both grt.tlc and ert.tlc; both take an OpenMP-capable compiler. | | StackUsageMax | MaxStackSize | Same numeric semantics on both sides. | | DeepLearningConfig = coder.DeepLearningConfig("none") | DLTargetLibrary = "none" (codegen) + SimDLTargetLibrary = "none" (simulation) | Simulink side takes a plain string, not a config object. Set BOTH parameters — DLTargetLibrary only affects slbuild; simulation uses the separate SimDLTargetLibrary. |
This skill's examples are all MATLAB Coder (cfg.X = ...); for the Simulink side and for AI-model-specific perf knobs (reduction-loop vectorization, MEX SIMD), see matlab-deploy-ai-model/references/codegen-performance-options.md.
PIL compiles the generated code, deploys it to the physical board, sends test vectors, and compares outputs against MATLAB. This catches precision differences, stack overflows, and memory issues that SIL cannot detect.
Cortex-M (serial transport):
matlabcfg.VerificationMode = "PIL"; cfg.Hardware.PILInterface = "Serial"; cfg.Hardware.PILCOMPort = "COM4"; % adjust to your system
Cortex-A / Raspberry Pi (SSH transport):
matlabcfg.VerificationMode = "PIL"; cfg.Hardware = coder.hardware("Raspberry Pi"); cfg.Hardware.DeviceAddress = "192.168.1.10"; cfg.Hardware.Username = "<your-pi-username>"; cfg.Hardware.Password = "<your-pi-password>"; cfg.Hardware.BuildDir = "/home/pi/mymodel"; % optional: defaults to /home/pi/MATLAB_ws/<release>
Pi PIL runs over SSH (not serial). The support package uses DeviceAddress, Username, and Password to establish the SSH connection. BuildDir specifies where the compiled binary is deployed on the target; if omitted, defaults to /home/pi/MATLAB_ws/<release>/. Do not set PILInterface or PILCOMPort — those are for serial-connected bare-metal boards only.
matlabcfg.TargetLang = "C"; codegen -config cfg -args {inputArgs} myEntryPoint
For confidence in deployment, follow this sequence:
matlabcfgSil = coder.config("lib", "ecoder", true); cfgSil.VerificationMode = "SIL"; codegen -config cfgSil -args {inputArgs} myEntryPoint
| Property | Values | Purpose | |----------|--------|---------| | VerificationMode | "PIL", "SIL", "None" | Enable in-the-loop verification | | Hardware | coder.hardware(boardName) | Select target board | | Hardware.PILInterface | "Serial" | PIL communication type | | Hardware.PILCOMPort | "COM4", "/dev/ttyACM0" | Serial port | | EnableDynamicMemoryAllocation | true (default), false | Master switch for heap | | DynamicMemoryAllocationThreshold | numeric (bytes), default 65536 | Arrays above this use heap | | LargeConstantGeneration | "KeepInSourceFiles", "WriteOnlyDNNConstantsToDataFiles" | Where to put large constants | | StackUsageMax | numeric (bytes) | Stack limit for generated code (Simulink: MaxStackSize) | | EnableOpenMP | boolean | OpenMP multi-threading (Simulink: MultiThreadedLoops) | | CodeReplacementLibrary | "GCC ARM Cortex-A", "ARM Cortex-M", … | Vendor-optimized op replacements | | TargetLang | "C", "C++" | Output language |
| Mistake | Why It's Wrong | Correct Approach | |---------|---------------|-----------------| | DynamicMemoryAllocation = "Off" | Wrong property name and type | EnableDynamicMemoryAllocation = false (boolean) | | Skipping SIL before PIL | PIL failures on hardware are harder to debug | Always validate with SIL first | | Not setting StackUsageMax | Default may exceed target SRAM | Set explicitly based on hardware constraints | | Using cfg = coder.config("lib") without "ecoder", true | Creates a generic config, not ERT-based | Always pass "ecoder", true for embedded targets |
coder.config("lib", "ecoder", true) for embedded targetsDynamicMemoryAllocation (wrong property name — it's EnableDynamicMemoryAllocation)TargetLang = "C" for Cortex-M targets (smaller code footprint)references/supported-hardware.md — board specs, support packages, and PIL interface detailsmatlab-deploy-ai-model — full AI model codegen pipeline (load, verify, generate MEX/lib)Copyright 2026 The MathWorks, Inc.
Other measured skills in the registry, with their headline benchmark lift.