MCU graphics · side-by-side reference
Renesas RH850/D1M, NXP i.MX RT1176, and Infineon Traveo T2G all drive HMI displays, and all three share the same five-stage skeleton, assets → render → memory → compose → panel. Read each pipeline down its column; scan a single stage across the row to see what's shared and what isn't. The whole story lives in two rows: how much rendering power the purple stage has, and how much RAM the teal stage costs.
NXP carries a true vector GPU (GC355) plus a raster blitter, resolution-independent paths, any-angle rotation. Renesas has an OpenVG drawing engine. Infineon has a fixed-function 2.5D blitter with no path geometry at all, so vector shapes must be pre-rasterized into assets. A QML Shape that renders on the RT1176 or D1M may have no hardware path on the T2G.
Renesas and Infineon keep this stage tiny, sprites read straight from ROM, or a 128-line OTF ring replaces the framebuffer, to cut BOM cost and stay deterministic. NXP lets it grow into full double-buffered framebuffers in external RAM, buying generality and higher resolution at the price of bandwidth and power.
The compose row is the quiet agreement: every one of the three blends its layers on the fly at scan-out, so no fully composed frame is ever stored, the differences are all upstream, in what feeds that final blend.
| Component / role | Renesas RH850/D1M | NXP i.MX RT1176 | Infineon Traveo T2G |
|---|---|---|---|
| Positioning | Automotive instrument cluster; ASIL-B safety | General crossover MCU; rich HMI / multimedia | Automotive cluster / body; safety-oriented |
| CPU | RH850 G3-cores, lockstep options | Cortex-M7 ~1 GHz + Cortex-M4 | Dual Cortex-M7 (+ M0+) |
| Vector / geometry GPU | OpenVG 1.1 engine (high-end variants) | GC355 (VeriSilicon Vivante), OpenVG / VGLite | None, no path / vector geometry |
| Blit / raster engine | 2D drawing within the GPU | PXP, blit, scale, fixed rotate, CSC, alpha | Blit engine, fill, blit, blend, affine, decompress |
| Composition / display controller | Sprite engine + video output | LCDIFv2, 8 layers, on-the-fly blend | Layer composition engine + CmdSeq replay |
| Sprite / direct-from-memory | Sprite engine reads images direct from ROM; VRAM wrapper | None dedicated (planes via LCDIFv2) | SpriteLayer (≤8 sub-layers) + OTF replay |
| Framebuffer model | On-the-fly, framebuffer minimized RAM-frugal | Full double-buffered framebuffers framebuffer-based | OTF = none; IBO / LBO-mem when needed RAM-frugal |
| Graphics memory | Internal Video RAM + wrapper; external up to DDR2 | Up to 2 MB SRAM; external SDRAM / HyperRAM / PSRAM | 4 MB line-based internal VRAM; external HyperRAM via SMIF |
| Display out / max | Parallel RGB / TCON to TFT | MIPI-DSI / parallel, up to 1920×1080 @ 30 Hz | RGB / LVDS / MIPI, dual display; OTF layer ≤ 1300×720 |
| Special blocks | JPEG unit, HUD warp (VOWE), stepper driver, sound gen | Camera CSI, extensive crypto | Safety features (JPEG / HUD vary by part) |
| Typical framework | Renesas libs, Qt / others | Qt for MCUs, Embedded Wizard, emWin, LVGL, VGLite | Qt for MCUs (QUL), emWin |
Porting note. The RH850 ↔ T2G move is conceptually easy, both are sprite/OTF, both RAM-frugal, but asset-pipeline-heavy, since you manage compressed images and sprite/line budgets on both. The RT1176 is the opposite: memory and rendering are generous, but you inherit framebuffer management, external-RAM bandwidth planning, and a real GPU driver stack. And "GPU" means three different things across the columns, so vector drawing ports cleanly between NXP and high-end Renesas (both OpenVG) but not to the T2G.