Een volwaardige HMI zonder Yocto-onderhoud?

Een touchscherm van zeven inch, met animaties en een duidelijke bediening, gold lang als een reden om meteen Linux te kiezen. Dat klopt niet meer vanzelf. High-end microcontrollers tekenen vandaag interfaces die er op het eerste gezicht uitzien als een klein embedded Linux-systeem, terwijl de rest van het toestel een controller blijft.

Het verschil zit niet in een mooier lettertype. Het zit in kloksnelheid, een grafische versneller, een displaycontroller en genoeg extern geheugen om de framebuffer vast te houden. Daarbovenop komt een bibliotheek zoals LVGL of TouchGFX, die alleen opnieuw tekent wat veranderd is.

Waarom Linux de reflex werd

Een rijke interface vroeg vroeger om een application processor. Je had een kernel nodig, een windowing-laag, lettertypen, en genoeg RAM om een heel scherm bij te houden. Op een Cortex-M met een SPI-schermpje van 320×240 bleef de interface een menu: een paar knoppen, een waarde, een alarm.

Die grens is opgeschoven. Een paneel van 800×480 of 1024×600 is geen desktop. Het is één applicatie, fullscreen, met een bekende set schermen. Daarvoor hoef je geen compositor, geen pakketbeheer en geen distributie te onderhouden. Je hebt een processor nodig die het scherm kan uitsturen en een CPU die de widgets op tijd kan bijwerken.

De vraag is niet of het scherm er modern uitziet. De vraag is of de rest van het product Linux nodig heeft.

Zodra die rest een camera, een browser, containers of meerdere programma’s op hetzelfde scherm is, verandert het antwoord. Tot dan is een microcontroller vaak de rustigere architectuur.

De hardware die het scherm draagt

Twee families kom je in dit segment het vaakst tegen: de STM32H7 van ST, en de zwaardere ESP32-varianten van Espressif. Ze lossen hetzelfde probleem op een andere manier op.

STM32H7. De bekende H743 loopt op een Cortex-M7 tot 480 MHz. Nieuwere onderdelen in dezelfde lijn, zoals de H735, gaan tot 550 MHz. Dual-core varianten zoals de H745 zetten naast die M7 een Cortex-M4, zodat de regellus niet hoeft te wachten op het tekenen. De grafische versneller op deze klassieke H7 is Chrom-ART, in de documentatie DMA2D: die vult vlakken, kopieert bitmaps en mengt lagen zonder dat de CPU elke pixel aanraakt. De LTDC-displaycontroller leest de framebuffer en stuurt het paneel. Extern SDRAM hangt aan de FMC.

NeoChrom is een stap zwaarder, en die zit niet op elke H7. Die GPU hoort bij de nieuwere STM32H7RS, met een Cortex-M7 tot 600 MHz. Rotatie, schaling en meer laagmenging gaan daar in hardware. Voor een interface met veel beweging is dat het verschil tussen een CPU die pixels schuift en een blok dat het overneemt.

ESP32-S3 en ESP32-P4. De S3 heeft twee Xtensa-kernen tot 240 MHz en PSRAM naast de chip. Met de parallelle RGB-interface kom je goed weg met 480×272 en 800×480. Een paneel van 1024×600 kan, maar dan zit je krap in bandbreedte en in de tijd die het tekenen nog overlaat. De P4 is voor dit werk gebouwd: twee RISC-V-kernen tot 400 MHz, PSRAM, en MIPI-DSI naar het scherm. Daarmee schuift Espressif in hetzelfde segment als een H7 met extern geheugen, met wifi en een lagere instap voor teams die al in dat ecosysteem zitten.

Andere MCU-families doen dit ook. NXP en Renesas hebben onderdelen met een vergelijkbare displaycontroller en extern RAM. De afweging blijft dezelfde: klok, versneller, en of de framebuffer in het geheugen past.

De software tekent alleen wat wijzigt

LVGL is de bibliotheek die je op deze chips het vaakst tegenkomt. De kern is C, ze draait bare metal of op een RTOS, en ze is hardware-onafhankelijk. Widgets, animaties en invoer zitten in de firmware, naast de regeling. Hoe de licentie en de vergelijking met TouchGFX, Slint en Qt uitvallen, staat in LVGL voor embedded GUI’s.

Het prestatiepunt is gedeeltelijk tekenen. Een HMI verandert zelden het hele beeld. Een waarde telt op, een knop licht op, een grafiek schuift een stuk. LVGL houdt die regio bij. DMA2D of NeoChrom vult en kopieert ze. De CPU blijft vrij voor de toepassing.

TouchGFX hoort bij STM32. De designer, de voorbeelden en de koppeling met Cube zitten in hetzelfde ecosysteem, en de tooling is daar gratis. Het nadeel is dat het scherm aan die chipfamilie vastzit. LVGL neem je mee als de volgende revisie een andere leverancier krijgt.

Op een ESP32-P4 is LVGL eveneens de gebruikelijke laag, met de PSRAM als framebuffer en de MIPI- of RGB-uitgang als displaypad. De bibliotheek verandert niet. De driver en de hoeveelheid geheugen wel.

Wat je in de praktijk van het scherm mag verwachten

Het geheugen is de eerste grens, niet het aantal knoppen. Eén framebuffer in 16-bit kleur vraagt dit:

Scherm	Eén buffer	Dubbele buffering
480×272	255 kB	510 kB
800×480	750 kB	1,5 MB
1024×600	1,2 MB	2,4 MB
1280×800	2,0 MB	4,0 MB

Een H743 heeft veel intern SRAM, maar niet genoeg aaneengesloten geheugen voor een zeven-inch paneel met dubbele buffering. Daar komt het externe SDRAM. De LTDC en de CPU delen die bus. Een interface die er soepel uitziet, is er een die die bus niet volzet met een volledig nieuw beeld, elk frame opnieuw.

Voor een gewone bediening op 1024×600, met animaties op de regio’s die wijzigen, halen teams op een STM32H7 met DMA2D en extern SDRAM rond de 30 beelden per seconde. Dat is een vloeiende HMI. Het is geen video, en het is geen volledig scherm dat dertig keer per seconde van nul wordt opgebouwd. Zet je die eis erbij, dan loopt de framerate terug of je schuift door naar een H7RS met NeoChrom, of naar een MPU.

800×480 past ruimer, ook op een ESP32-S3 met genoeg PSRAM. 480×272 hoort nog op kleinere microcontrollers thuis, en daar is deze hele H7-klasse vaak te veel chip voor het scherm.

Dertig beelden per seconde zegt iets over de bediening, niet over een mediaspeler.

Wat je wint tegenover Linux

De winst zit in alles wat je niet meeneemt.

• De stuklijst. Een microcontroller, een SDRAM en een paneel zijn goedkoper dan een application processor of een SOM, zeker bij hogere aantallen. De layout van SDRAM is reëel werk, maar lichter dan DDR op een MPU.
• Opstarten. Het eerste beeld kan er in een fractie van een seconde staan. Een Linux-image doet daar seconden over, ook als je het image klein houdt.
• Vermogen. De MCU blijft in de orde van een watt of minder, afhankelijk van klok en scherm. Een Linux-module zit daar snel boven, en de voeding en de warmte volgen.
• Determinisme. De regellus en het scherm delen één firmware. Een Cortex-M4 naast de M7, of een zorgvuldig ingedeelde RTOS, houdt de besturing voorspelbaar. Op Linux is dat een aparte oefening in prioriteiten, kernels en latency.
• Minder software om bij te houden. Geen distributie, geen userspace, geen compositor. De aanvalsoppervlakte en de certificeringsmap zijn kleiner. Een medisch of industrieel dossier wordt daar niet vanzelf licht van, maar je certificeert firmware, niet een besturingssysteem met een pakketlijst.

Dat laatste is geen vrijbrief. De Cyber Resilience Act en een medische norm kijken nog steeds naar het hele toestel. Minder code maakt het dossier overzichtelijker. Het haalt de verplichting niet weg.

Wanneer Linux de betere keuze blijft

Een mooi scherm is geen reden meer om Linux te nemen. Andere eisen zijn dat nog wel.

Kies een MPU met Linux wanneer het product een camera en een videopijplijn heeft, wanneer er een browser of een zware webtechnologie op het scherm moet, of wanneer meerdere processen het display delen. Ook wanneer je het applicatieframework van Qt nodig hebt, met netwerk, opslag en een updateverhaal dat bij een Linux-image hoort. Welke distributie dan past, lees je in Yocto vs Ubuntu vs Debian.

Dezelfde grens zie je aan het paneel. Een 1280×800 met veel gelijktijdige animaties, of een interface die eruitziet als een applicatie met lijsten, kaarten en live video, past niet comfortabel in een MCU-framebuffer. Dan is de microcontroller de duurdere keuze, omdat je de beperking later alsnog wegwerkt met een redesign.

Waar je dit tegenkomt

Dit patroon zit in bedieningspanelen van machines, in pompen en klimaatkasten, in eenvoudige medische apparaten met een vast scherm, en in dashboards die één taak tonen. Het scherm is de interface van een controller. Het is niet de computer.

Een smart-home-paneel aan de muur kan hier ook landen, zolang het geen browser en geen camerafeed hoeft te zijn. Zodra dat wel zo is, zit je weer bij Linux.

Hoe wij ernaar kijken

Bij Invisto beginnen we bij het schermformaat, de framebuffer en de vraag wat het toestel nog meer moet doen. Past het beeld in extern RAM, en is de rest van het product een regellus met een interface, dan is een STM32H7 of een ESP32-P4 een sterke en vaak goedkopere architectuur dan Linux. Vraagt het product om camera, meerdere programma’s of een zwaar applicatieframework, dan tekenen we het scherm op een MPU en houden we de microcontroller niet kunstmatig in beeld.

Het framework volgt die keuze. LVGL of TouchGFX op de MCU, Qt wanneer Linux er om een andere reden al is.