5. Simulate & Deploy

☀️ Light

Step 1 — simulate the closed loop

Open tutorial_picooz_simulation.slx:

Structure:

[ Setpoint Generator ] ──► (+)──► [ Controller ] ──► [ Identified Plant ] ──┐
                            ▲                      (picooz_motorBlade_m)    │
                            │                                               │
                            └───────────────────────────────────────────────┘
                                           measured ω

The plant in the simulation model is the same picooz_motorBlade_m.m ODE you identified on page 3, plugged in via a MATLAB Function block.

Recommended first run

Apply a step sequence to the setpoint:

Check:

• Rise time — matches your design target.
• Overshoot — should be zero or small with a well-tuned controller.
• Steady-state error — exact zero with the integral term active.
• Control effort u(t) — must not saturate the PWM duty at ±1 for your operating range.

Iterate on the controller gains until you are satisfied. This iteration takes seconds — the simulation runs faster than real time.

This is the MBD payoff you have been working toward

Everything you tune here carries unchanged to the hardware — because the hardware runs the same model. The target-specific parts (PWM, ADC, UART) are isolated in MPLAB Device Blocks that the simulation model simply stubs out.

Step 2 — generate embedded C code

Replace the identified plant block with the PWM HS FEP + ADC HS 12b hardware blocks (same inputs/outputs — they now talk to real peripherals). Switch Simulation → Mode → External.

Press Monitor & Tune.

Under the hood, in roughly this order:

1. Embedded Coder traverses the model and emits C code for the controller subsystem.
2. MPLAB Device Blocks emit C code for the peripherals (PWM HS FEP, ADC HS 12b, UART) and the rate-monotonic scheduler.
3. XC-DSC compiles to .elf / .hex.
4. MDB (or MPLAB X) programs the target through your debugger (PKOB, PICkit, ICD…).
5. The target starts running your Simulink model — physically on the MCU, not on your PC.

Typical numbers on a dsPIC33AK512MPS506 @ 200 MIPS:

Code Replacement Library (CRL) — automatic optimisation

The Super-Twisting controller uses sqrt(). On dsPIC the toolbox automatically substitutes the generic floating-point sqrt with a hand-tuned assembly implementation from mchp/Lib_dsPIC/MACRO/ — the Code Replacement Library. Same for sin, cos, atan2 in more complex models.

This is transparent. Your model is unchanged; the generated C is optimised.

Step 3 — change target without rewriting a single line

The model you just deployed is not tied to the dsPIC33A. Change the Master block’s target to, for example, dsPIC33CK256MP508 or SAME70Q21B — the same Simulink model rebuilds for the new target. Peripheral pinning adapts automatically (PPS on dsPIC, PORT mux on SAM).

The controller’s generated C is unchanged. Only the initialisation code for the peripherals differs.

Industrial relevance. This is how a prototype developed on a €30 dev kit scales to a production BOM with a different MCU from the same family.

What’s next

The embedded code is on the target. Time to verify that the hardware response matches the simulation — the final MBD validation step.

Next → 6. Validate & Beyond

Back → 4. Controller Design