The Tunable Parameters toolkit lets you expose selected block parameters as calibratable variables โ€” values you can change live on the running target over XCP / External Mode โ€” while keeping everything else inlined as constants in the generated C. This gives you fast, small firmware and the parameters you actually want to tune at runtime.

Find it on the Microchip toolstrip tab, Tune section (see Microchip Toolstrip ).


Why promote a parameter?

By default the blockset generates code with inlined parameters: a Gain of 5000 becomes the literal 5000 in the C โ€” fast and compact, but you cannot change it without rebuilding. To tune a value live (controller gains, limits, setpoints) it must become a Simulink.Parameter with a storage class that places it in the model’s parameter structure (<model>_P), which External Mode / XCP can read and write.

Promoting only the handful of parameters you need keeps the rest inlined โ€” you don’t pay the RAM / indirection cost for parameters you never tune.


Quick workflow

  1. Select the block(s) whose parameters you want to tune.
  2. Click Tunable param on the Microchip tab โ†’ a table lists each promotable field with its current value and a suggested action.
  3. Tick the fields to Promote, pick a data type (or leave auto), and Apply. The literals become Simulink.Parameters.
  4. (Optional) Click Bind slider to attach a dashboard Slider/Knob.
  5. Build with Monitor & Tune โ†’ move the slider (or edit the parameter) and the value updates on the hardware with no rebuild.

To undo, re-open the table and set the action to Revert (the original literal is remembered).


The audit view (whole model)

Click Tunable audit for a model-wide table of every promotable field:

ColumnMeaning
Block / Fieldwhere the parameter lives
Textthe dialog text (e.g. Kp, 5000, [0.1 0.3])
Stateliteral / identifier / expression / unresolved
ScopeXCP-reachable / C-only / inlined (from the storage class)
StorageClassthe current Simulink.Parameter storage class
Widgetwhether a dashboard widget is already bound
Suggestionthe recommended action

From here you can promote/revert in bulk, bind widgets, and export / import calibration sets.


Storage class โ€” what lands where

The storage class decides where a promoted parameter ends up in the generated C. The toolkit groups them for you:

ScopeStorage classesReachable over XCP?
XCP-reachable (in <model>_P)SimulinkGlobal, Model default, Custom Const, Volatile, ConstVolatile, Struct, BitFieldโœ… yes
C-only (free-standing symbol)ExportedGlobal, ImportedExtern*, ExportToFile, ImportFromFile, FileScope, Localizable, GetSetโš ๏ธ accessible by name, not via <model>_P
InlinedAuto (under Inlined default), Custom Define (#define)โŒ no (compile-time constant)

For live tuning over External Mode, pick an XCP-reachable class โ€” the default suggestion (SimulinkGlobal / Model default) is correct for most cases.

Gotcha: on a parameter stored in the model workspace, MATLAB silently normalises SimulinkGlobal to Model default. They are synonyms here โ€” both land in <model>_P.

The XCP access path for a promoted parameter is <model>_P.<name> โ€” the audit view shows the exact path when you click a row.


Calibration sets (export / import)

Once you have a set of tuned values you like, save them as a calibration set:

  • Export โ€” dump every Simulink.Parameter in the model to a .mat file.
  • Import โ€” load a .mat, see a diff-preview of what would change, then apply.

This lets you keep named calibrations (e.g. motorA_aggressive.mat, motorB_smooth.mat) and swap them in without touching the model.

Both are on the Tunable โ€ฆ drop-down.


Data types and fixed-point

When promoting you can keep auto (the toolkit suggests a sensible type from the value), or force double / single / int16 / a fixdt(...) string, etc.

  • On floating-point targets (dsPIC33A FPU, PIC32, SAM) single/double is usually fine.
  • On fixed-point targets you may want an explicit fixdt to control RAM and resolution. This requires the Fixed-Point Designer toolbox; if it is absent, the toolkit degrades gracefully (offers the floating-point types only).

The “transformation of dialog parameters” trap

Some blocks precompute run-time parameters from their dialog parameters at codegen (e.g. Sine Wave Frequency/Phase, Pulse Generator, Chirp, Discrete Filter, Lookup Table). If you promote such a parameter with an Inlined default and a tunable storage class, code generation fails with a “transformation of one or more dialog parameters” error.

The audit table detects these and flags them with a severity banner and an Apply fix suggestion (typically: switch the model’s Default parameter behavior to Tunable, or use a different field). See the simulink-storage-class-scope reference for the full block list.


Canvas highlight

Tunable show tints the canvas so you can see at a glance what is calibratable:

  • pastel sky-blue โ€” block has at least one XCP-reachable tunable parameter
  • pastel peach โ€” block has a promoted parameter that is C-only (named symbol, not in <model>_P)

Click Clear highlight (Sim-Only section) to remove the tint.


Scripting API

Everything the toolstrip does is also available programmatically:

% Analyze
out = MCHP_Fun.tunable.analyze(gcb);          % one block
rep = MCHP_Fun.tunable.analyze(bdroot);       % whole-model audit

% Promote a literal Gain to a tunable Simulink.Parameter
MCHP_Fun.tunable.apply('promote', struct( ...
    'block', gcb, 'field', 'Gain', ...
    'name', 'Kp', 'dataType', 'single', ...
    'storageClass', 'SimulinkGlobal'));

% Revert / rename / calibration sets
MCHP_Fun.tunable.apply('revert', struct('block', gcb, 'field', 'Gain'));
MCHP_Fun.tunable.apply('export', struct('file', 'cal_motorA.mat'));
MCHP_Fun.tunable.apply('import', struct('file', 'cal_motorA.mat'));

% Bind a dashboard slider to a promoted parameter
MCHP_Fun.tunable.widget('bind', gcb, 'Kp');

See help MCHP_Fun.tunable.run for the toolstrip verb dispatcher.