GuideFirmware

Optimise Before You Swap the MCU: Speeding Up Firmware With CMSIS-DSP and SIMD on Cortex-M

Firmware too slow? Before redesigning the board around a faster chip, check whether your Cortex-M is actually being used well. A practical checklist for profiling and DSP optimisation.

Short answer

Firmware misses a timing target
Profile first, do not swap chips yet
Heavy filtering, FFT or matrix maths
Use CMSIS-DSP and fixed point
Optimised and still too slow
Then consider faster silicon

Cortex-M4, M7 and M33 cores include DSP instructions, and many include a floating-point unit. A lot of application firmware never uses them, which means teams sometimes redesign hardware to solve a software problem.

Step 1: Measure where the time goes

Use the core's cycle counter or a GPIO toggle and an oscilloscope to time each stage. Optimising without measuring is guessing, and the slow part is rarely where people expect.

Step 2: Check the usual suspects

  • Double-precision maths on a core whose FPU only supports single precision. Every double becomes slow software emulation.
  • Debug builds shipped to production, with optimisation turned off.
  • Hand-written loops for filters, FFTs and matrix maths.
  • Code and data in slow memory, with flash wait states on every access.
  • CPU copying data that DMA could move for free.

Step 3: Use CMSIS-DSP

Arm's CMSIS-DSP library provides filters, transforms, statistics and matrix functions optimised for Cortex-M. On cores with the DSP extension, its fixed-point (Q15 and Q31) functions use SIMD instructions that process two 16-bit values in one instruction.

Step 4: Fix memory and data movement

Place hot code and buffers in tightly coupled or zero-wait-state RAM where available, enable caches on cores that have them, and let DMA move ADC samples and communication buffers.

Step 5: Only then compare chips

If the optimised firmware still misses the target, you now have accurate numbers to size a new processor, instead of guessing.

Frequently asked questions

How much faster can firmware get?

It depends on the starting point. Moving from unoptimised double-precision code to CMSIS-DSP with fixed point can give several times speed-up. In one client project, the same MCU went from 1.5 s to about 200 ms.

Does CMSIS-DSP work on every Cortex-M?

It runs on all of them, but the biggest gains come on cores with the DSP extension and an FPU, such as the M4, M7 and M33.

Will optimisation change my results?

It can if done carelessly. Always compare outputs against the original on recorded data.

Sources

  1. Arm white paper: DSP capabilities of Cortex-M4 and Cortex-M7
See it in a real projectFrom 1.5 s to 200 ms on the Same Renesas MCU: How I Saved a Client a Hardware Redesign
Nikhil Robinson

Embedded systems consultant at TechProgeny, Bengaluru. 7+ years and 29+ shipped products across firmware, embedded Linux, edge AI, apps and IoT servers.