- Client
- Industrial instrument maker (under NDA)
- Platform
- Renesas Synergy, Arm Cortex-M4 at 240 MHz, SSP
- Goal
- Full measurement cycle under 500 ms
- Timeline
- ~3 weeks
The problem
The client's instrument took 1.5 seconds to turn raw sensor data into a result. The product needed 500 ms. Their engineering team had concluded the Renesas Synergy MCU was too slow and was about to start evaluating faster MCUs and Linux SoCs.
A new processor means a new schematic, a new PCB, a new firmware port and a fresh round of certification and testing. For a small hardware company that is months of work and a large R&D bill.
Before you change anything, send me the current project. Let me measure where the 1.5 seconds actually go.
What was really going wrong
The Cortex-M4 at 240 MHz was not the bottleneck. The way the firmware used it was. Profiling with the core's cycle counter showed four issues:
- Signal processing used double-precision maths. The Cortex-M4 FPU is single-precision only, so every double operation ran in slow software emulation.
- Filters were plain C loops, processing one sample at a time and ignoring the M4's DSP instructions.
- The frequency analysis used a generic FFT written for a PC, not one tuned for Cortex-M.
- Hot code ran from flash with wait states, and the CPU copied ADC samples by hand instead of letting DMA do it.
How I solved it
Measure first
I instrumented every stage of the pipeline with the DWT cycle counter, so each decision was based on numbers, not guesses.
Single-precision maths
I moved the processing chain to 32-bit float and made the compiler treat constants as single precision. That took the slow emulation out of every operation.
CMSIS-DSP and SIMD
I replaced the hand-written filters and FFT with Arm's CMSIS-DSP library. Where accuracy allowed, filters run in Q15 fixed point, where the M4's SIMD instructions do two 16-bit multiply-accumulates per cycle.
Memory and DMA
I placed the hottest loops in SRAM, enabled DMA for ADC transfers and tuned compiler optimisation for the release build.
Prove accuracy
I ran the old and new firmware on the same recorded datasets and compared every output, so the client could see the results had not changed.
| Change | Cycle time |
|---|---|
| Original firmware | 1.5 s |
| Single-precision float | ~900 ms |
| CMSIS-DSP filters with Q15 SIMD | ~450 ms |
| Optimised CMSIS FFT | ~260 ms |
| SRAM placement, DMA, compiler tuning | ~200 ms |
What the client got
Results
- A measurement cycle of about 200 ms, well inside the 500 ms target and leaving headroom for new features.
- The same results as before, verified against recorded data.
- No new schematic, PCB, firmware port or re-certification. The hardware they had already validated stayed in production.
- A profiling setup their own team can use for future changes.
Sometimes the most valuable engineering decision is the one that avoids a redesign. Changing hardware is the right call when the silicon really is the limit. Here it was not.
Related guideOptimise Before You Swap the MCU: Speeding Up Firmware With CMSIS-DSP and SIMD on Cortex-M
Embedded systems consultant at TechProgeny, Bengaluru. 7+ years and 29+ shipped products across firmware, embedded Linux, edge AI, apps and IoT servers.