agentsclimarketplace

Matlab deploy embedded code

Skill matlab/matlab-agentic-toolkit/skills-catalog/code-generation/matlab-deploy-embedded-code

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.From its SKILL.md

Install
npx -y skills add matlab/matlab-agentic-toolkit --skill matlab-deploy-embedded-code

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its file declares

Copied from the file, not written here

The file declares its own license as MathWorks BSD-3-Clause. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

7.6 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it

Deploy Embedded Code

Configure MATLAB Coder with Embedded Coder for production-quality code generation targeting embedded hardware, and verify correctness with processor-in-the-loop (PIL) testing.

When to Use

  • Generating C/C++ code for a microcontroller or embedded Linux board
  • Setting up PIL or SIL verification for generated code
  • Configuring code generation with no dynamic memory allocation
  • Deploying deep learning models to resource-constrained hardware
  • Selecting a hardware target board (STM32, Raspberry Pi)

When NOT to Use

  • Generating MEX or desktop libraries — use standard codegen workflows
  • Simulink-based deployment — use Simulink Coder / Embedded Coder workflows directly
  • GPU code generation (CUDA) — use GPU Coder

Workflow

1. Create an ERT-Based Configuration

cfg = 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.

2. Select Target Hardware

With coder.hardware:

cfg.Hardware = coder.hardware("STM32F746G-Discovery");

Without the support package, configure hardware manually:

cfg.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.

3. Configure Memory for Bare-Metal Targets

cfg.EnableDynamicMemoryAllocation = false;
cfg.StackUsageMax = 512;
  • EnableDynamicMemoryAllocation = false — disables malloc/free for targets where heap is unavailable or non-deterministic. All arrays must be bounded at compile time.
  • StackUsageMax — set based on target SRAM. The code generation report shows actual usage after compilation.

For entry-points that use deep learning inference (invoke, predict):

cfg.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 source files rather than separate data files. Needed for bare-metal targets where external data file linking is unsupported.

4. Configure Performance (SIMD and OpenMP)

SIMD vectorization — generates vectorized code for the target ISA:

cfg.InstructionSetExtensions = 'Neon v7';  % ARM Cortex-A (128-bit, 4x float32)
TargetValueNotes
ARM Cortex-A (Raspberry Pi)'Neon v7'128-bit SIMD
Intel x86-64'SSE', 'SSE4.1', 'AVX', 'AVX2', 'AVX512F'Match target CPU
ARM Cortex-MDo not set — use CodeReplacementLibrary insteadDifferent mechanism

OpenMP multi-threading — enables parallel loops in generated code:

cfg.EnableOpenMP = true;   % multi-core targets (Cortex-A, x86)
cfg.EnableOpenMP = false;  % single-core targets (Cortex-M) — no OS/threading support, won't compile

5. Set Up PIL Verification

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):

cfg.VerificationMode = "PIL";
cfg.Hardware.PILInterface = "Serial";
cfg.Hardware.PILCOMPort = "COM4";  % adjust to your system

Cortex-A / Raspberry Pi (SSH transport):

cfg.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.

6. Generate Code

cfg.TargetLang = "C";
codegen -config cfg -args {inputArgs} myEntryPoint

7. Verify with the MEX → SIL → PIL Progression

For confidence in deployment, follow this sequence:

  1. MEX — verify on host, fast iteration
  2. SIL (Software-in-the-Loop) — run generated code on host, compare to MATLAB
  3. PIL (Processor-in-the-Loop) — run on actual hardware, compare to MATLAB
cfgSil = coder.config("lib", "ecoder", true);
cfgSil.VerificationMode = "SIL";
codegen -config cfgSil -args {inputArgs} myEntryPoint

Key Properties

PropertyValuesPurpose
VerificationMode"PIL", "SIL", "None"Enable in-the-loop verification
Hardwarecoder.hardware(boardName)Select target board
Hardware.PILInterface"Serial"PIL communication type
Hardware.PILCOMPort"COM4", "/dev/ttyACM0"Serial port
EnableDynamicMemoryAllocationtrue (default), falseMaster switch for heap
DynamicMemoryAllocationThresholdnumeric (bytes), default 65536Arrays above this use heap
LargeConstantGeneration"KeepInSourceFiles", "WriteOnlyDNNConstantsToDataFiles"Where to put large constants
StackUsageMaxnumeric (bytes)Stack limit for generated code
TargetLang"C", "C++"Output language

Common Mistakes

MistakeWhy It's WrongCorrect Approach
DynamicMemoryAllocation = "Off"Wrong property name and typeEnableDynamicMemoryAllocation = false (boolean)
Skipping SIL before PILPIL failures on hardware are harder to debugAlways validate with SIL first
Not setting StackUsageMaxDefault may exceed target SRAMSet explicitly based on hardware constraints
Using cfg = coder.config("lib") without "ecoder", trueCreates a generic config, not ERT-basedAlways pass "ecoder", true for embedded targets

Conventions

  • Always: use coder.config("lib", "ecoder", true) for embedded targets
  • Always: disable dynamic memory for bare-metal Cortex-M targets
  • Always: follow MEX → SIL → PIL verification order
  • Never: use DynamicMemoryAllocation (wrong property name — it's EnableDynamicMemoryAllocation)
  • Prefer: TargetLang = "C" for Cortex-M targets (smaller code footprint)

References

  • references/supported-hardware.md — board specs, support packages, and PIL interface details

See Also

  • matlab-deploy-ai-model — full AI model codegen pipeline (load, verify, generate MEX/lib)

Copyright 2026 The MathWorks, Inc.


What ships with it: 2 files

2.6 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 326,871. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.