Motorcycle cluster.
Half the flash.
Same performance.
A leading global racing motorcycle manufacturer needed a new instrument cluster that matched the performance of its predecessor — but had to flash over CAN in under nine minutes. Crossware delivered both.
Replace the cluster. Match the spec. Reduce the flash time.
The tier-one supplier needed to deliver a next-generation instrument cluster to a leading global racing motorcycle manufacturer. The requirement was clear: match the visual quality and performance of the outgoing cluster exactly — no regression on animations, responsiveness or feature set.
But a new constraint was added: the cluster firmware had to be flashable over CAN bus within nine minutes. The existing build was too large to meet this target. Reducing binary size without sacrificing what made the cluster good was the core engineering problem.
A visually rich cluster with no room to spare in flash.
The cluster was not a simple display. It had multiple layers of visual complexity that all contributed to binary size:
-
01
Complex RPM gauge animations
The tachometer used high-fidelity animated sequences requiring significant image data. Frame count and image quality directly affected binary size.
-
02
Dynamic content strings
Music playback, phone call information and turn-by-turn navigation all required dynamic text rendering and associated font assets.
-
03
Settings screen microanimations
The settings UI had a dense layer of micro-interactions and transition animations — each contributing small amounts of asset data that accumulated significantly.
-
04
Full-screen images in settings
Settings screens included full-screen background images — some of the heaviest assets in the entire binary, with limited scope for lossy compression under the original approach.
Two levers: hardware decode and delta compression.
Crossware approached the binary size problem from two angles simultaneously — exploiting hardware capabilities that were available but unused, and applying a smarter image encoding strategy.
-
01
Hardware JPEG decoder enablement
The Renesas RH850 D1M1A has an on-chip JPEG decoder that was not being used. Crossware integrated and enabled this hardware decoder within the Qt for MCUs BSP, then converted the startup animation sequence from uncompressed image assets to JPEG. The result was a significant reduction in binary size for the most flash-intensive section of the firmware.
-
02
Delta frame technique for animation sequences
Rather than storing each animation frame as a complete image, Crossware implemented a delta encoding approach — only the pixels that change between consecutive frames are stored. For animation sequences with large static regions (backgrounds, gauges), this eliminated the majority of redundant image data while preserving visual fidelity at runtime.
-
03
Full exploitation of all four RH850 D1M1A hardware layers
The RH850 D1M1A provides four independent hardware rendering layers. Crossware restructured the UI composition to use all four layers — each handling a distinct visual plane of the cluster. This avoided software-compositing overhead and delivered consistent 30+ FPS across every screen, including the animation-heavy RPM gauge and the micro-animated settings screens.
One screen, taken apart. Each plane is rendered and stored independently, and the display controller composites them into the frame the rider sees — no software blend pass, no full-frame redraw when a single element changes.
Indicators and warning lamps on their own plane. A telltale can illuminate or clear without the layer beneath it being touched.
Speed, tacho ramp, gear and ride data. The animation-heavy plane, and the one carrying the delta-encoded frame sequences.
The status and function rail. Because it sits on its own plane, a state change here costs nothing on the main layer above it.
What reaches the display. Composition happens in hardware, which is what holds 30+ FPS through the animation-heavy states.
Flash time target met. Performance maintained across all screens.
The combination of hardware JPEG decoding and delta frame encoding brought the firmware binary below the size required for nine-minute CAN flashing. No visual quality was sacrificed — the startup sequence, RPM animations and settings screens all rendered identically to the outgoing cluster.