Mikrocontroller oder FPGA

Der oft unterschätzte Designentscheid

Braucht dieses System wirklich ein FPGA oder reicht ein Mikrocontroller? Diese Frage stellt sich häufiger, als man denkt. Drei Praxisprojekte zeigen, warum die Antwort heute oft anders ausfällt als noch vor wenigen Jahren.

 
Wenn ein Problem nach FPGA klingt

Hohe Datenraten, präzises Timing, viel Parallelität. Bei solchen Problemstellungen wirkt die Entscheidung zunächst klar:  Das ist ein Fall für ein FPGA.

Einen solchen Moment hatten wir in einem Bewerbungsgespräch. Wir haben ein Projekt vorgestellt und schnell kam die Aussage: Das klingt nach FPGA.

Unsere Antwort war einfach: Nein, dies haben wir mit einem Mikrocontroller umgesetzt.

Das sorgt meistens für ein kurzes Innehalten und genau darum geht es. Nicht alles was nach FPGA aussieht, braucht heute eines.

Was hat sich in den letzten Jahre verändert?

Die Leistungsfähigkeit von Mikrocontrollern wird oft an der CPU-Leistung gemessen. In der Praxis ist das aber nicht der entscheidende Punkt. Der grosse Unterschied steckt heute in der Peripherie: High-Resolution Timer, flexible DMA-Mechanismen, Trigger-Logik oder parallele Interfaces sind heute integrierter Bestandteil vieler Controller. Und genau diese integrierte Hardware erlaubt es, zeitkritische Aufgaben mit einem Mikrocontroller auszuführen ohne dessen CPU substanziell zu beanspruchen. Das führt dazu, dass sich Grenzen verschieben. Anforderungen, die früher klar eine FPGA-Lösung erforderten, sind heute zumindest Kandidaten für eine Mikrocontroller-Lösung.

Die Entscheidung ist nie nur technisch

Die Frage Microcontroller oder FPGA wird oft technisch diskutiert. In realen Projekten ist das nur ein Teil der Wahrheit. Es geht auch um die verfügbaren Mitarbeiter im Team, das vorhandene Know-how, die Wartbarkeit und die Kosten über den ganzen Lebenszyklus.

FPGA-Entwicklung ist eine eigene Disziplin. Die Einstiegshürde ist höher und das Know-how ist seltener verfügbar. Wenn auf Kundenseite dieses Know-how fehlt, wird es schnell schwierig, Anpassungen selbst vorzunehmen. Änderungen sind dann nicht nur technisch, sondern auch organisatorisch aufwändiger, da sie oft wieder externe Unterstützung benötigen. Dazu kommen wirtschaftliche Aspekte. FPGA-Lösungen bringen häufig zusätzliche Lizenzkosten für Tools oder IP-Cores mit sich und auch die Bauteilkosten liegen je nach Anwendung über denen eines Mikrocontrollers. 

Ein weiterer Punkt ist der Umgang mit Änderungen im Feld. Während sich Mikrocontroller-Systeme in der Regel relativ einfach per Software aktualisieren lassen, ist das bei FPGA-Lösungen oft aufwändiger, insbesondere wenn keine eigene Softcore-Architektur vorgesehen ist.

Auf der anderen Seite stehen klassische Mikrocontroller-Projekte mit C / C++. Viele Teams sind dort bereits stark aufgestellt. Code lässt sich einfacher anpassen, wiederverwenden und über längere Zeit pflegen. Insbesondere wenn man konsequent auf strukturierte Software setzt, wie zum Beispiel mit dem C++ Framework von CSA: C++-Framework für Embedded Anwendungen. Durch den Aufbau auf bestehendem Wissen und grösserer Flexibilität bez. einsetzbaren Ressourcen resultieren zudem geringere Projektrisiken und oft eine kürzere Time-to-Market.

Diese Faktoren sind am Ende mindestens so wichtig wie reine Performancezahlen.

Drei Projekte, in denen die CSA bewusst auf MCU statt FPGA gesetzt hat

Projekt 1: 

Akustisches Messsystem

Ein Piezo-Kristall musste im MHz-Bereich in einem sehr schmalen Frequenzfenster angesteuert werden, da er nur bei seiner individuellen Resonanzfrequenz optimal arbeitet. Diese ist bauteilabhängig und muss deshalb für jedes Gerät fein justiert werden können.

Gleichzeitig muss das reflektierte Signal synchron zur Ansteuerung in einem exakt definierten Zeitfenster erfasst werden. Die Anforderungen an Timing und Auflösung liegen damit klar in einem Bereich, der klassisch einem FPGA zugeordnet wird.

Die Umsetzung zeigte jedoch einen anderen Ansatz. Durch den Einsatz eines High-Resolution-Timers mit intern synchronisierten Zählern konnte eine sehr feine zeitliche Auflösung erreicht werden. Das Zusammenspiel mehrerer Timer ermöglicht es, sowohl die Signalerzeugung als auch die Messung präzise im Mikrocontroller abzubilden.

Projekt 2:

Rotierendes LED-System

Im zweiten Projekt ging es um einen rotierenden LED-Globe. Dabei werden zwei LED-Ringe, ein innerer und ein äusserer, während der Rotation so angesteuert, dass für den Betrachter ein dreidimensional wirkendes Bild entsteht. Die Tiefenwirkung ergibt sich aus der Kombination beider Ringe und der zeitlich exakt abgestimmten Ansteuerung der LEDs. Die Grundidee ist einfach, die Umsetzung nicht.

Während sich das System dreht, müssen an definierten Winkelpositionen jeweils neue „Bildspalten“ ausgegeben werden. Pro Umdrehung entsteht so aus vielen einzelnen Stützstellen ein stabiles Bild. Für jede Position bleiben nur wenige hundert Mikrosekunden. In diesem kurzen Fenster müssen die Daten für alle LEDs beider Ringe vollständig und mit konstantem Timing übertragen werden. Gleichzeitig werden neue Bilddaten von der SD-Karte gelesen.

Die LEDs werden seriell angesteuert, sodass pro Bildspalte mehrere tausend Bits anfallen. Daraus ergeben sich kontinuierliche Datenraten im zweistelligen Megabitbereich. Mit Hilfe einer Vorverarbeitung der Bilddaten, dem Segmentieren der LED-Ringe und dem Einsatz von Timern und DMA konnte die Ausgabe erfolgreich realisiert werden. Das vollständige Projekt ist hier beschrieben: Rotating LED Globe - wenn Präzision und Innovation verschmelzen

Projekt 3:

Echtzeitsteuerung von Sensoren und Aktoren entlang eines Förderbandes

Mehrere hundert Objekte mussten fortlaufend erfasst, verfolgt und zum richtigen Zeitpunkt verarbeitet werden. Die Anforderungen lagen im Mikrosekundenbereich und mussten parallel für mehrere unabhängige Kanäle sowie bis zu 64 Sensoren und Aktoren funktionieren.

Auch hier lag der Schlüssel in der konsequenten Nutzung der Peripherie. Moderne DMA-Mechanismen wie 2D-DMA und Linked-List-DMA erlauben es, komplexe Abläufe hardwareseitig zu beschreiben und zeitlich exakt auszuführen, ohne dass die CPU eingreifen muss. Sequenzen von IO-Operationen können dabei vorbereitet und automatisch abgearbeitet werden.

Die CPU bleibt dadurch für Steuerlogik, Datenverarbeitung und die Kommunikation via Ethernet mit dem übergeordneten System reserviert, während die zeitkritischen Aufgaben deterministisch in der Peripherie abgearbeitet werden.

Alle drei Projekte hätten klassisch auch mit einem FPGA umgesetzt werden können. In diesen konkreten Fällen passten die Anforderungen jedoch sehr gut zu den Fähigkeiten der eingesetzten Mikrocontroller.

Wo die Grenzen weiterhin liegen

Trotz dieser Entwicklung gibt es weiterhin klare Anwendungsbereiche für FPGAs. Sobald maximale Parallelität erforderlich ist oder sehr hohe Datenraten verarbeitet werden müssen, stossen Mikrocontroller an ihre Grenzen. Ebenso dann, wenn die vorhandene Peripherie nicht ausreicht oder IO-Anforderungen stark skalieren. Ein FPGA bietet in solchen Fällen mehr Freiheitsgrade und lässt sich spezifischer auf die Anwendung zuschneiden.

In der Praxis gibt es zwar auch Mischformen, beispielsweise Kombinationen aus Mikrocontroller und externer Logik wie CPLDs oder kleinen FPGAs. Diese bringen jedoch zusätzliche Schnittstellen, Komplexität und Wartungsaufwand mit sich und sind deshalb kritisch zu betrachten.

Fazit

Der Technologieentscheid ist ein wegweisender Meilenstein in jedem Projekt und sollte nicht unterschätzt werden. Ein späterer Wechsel ist aufwändig und mit hohen Kosten verbunden.
Es ist entsprechend wichtig, die Möglichkeiten von modernen Mikrocontrollern zu kennen und die integrierte Peripherie wie DMAs und High-Resolution Timer konsequent zu berücksichtigen. Diese ermöglicht heute deutlich mehr Anwendungsfälle, als man auf den ersten Blick vermuten würde.

Schlussendlich geht es aber nicht um die Frage «Mikrocontroller oder FPGA», sondern darum, welches Werkzeug ist für die jeweilige Aufgabe am besten geeignet. Und genau diese Antwort kann heute eine andere sein als noch vor ein paar Jahren.

Der Bewerber vom Anfang arbeitet übrigens inzwischen bei uns. Eines der Projekte hat er selbst umgesetzt. Mit einem Mikrocontroller.

Wir unterstützen bei der richtigen Architekturentscheidung

Die richtige Architektur entsteht selten beim ersten Blick auf die Anforderungen. Oft lohnt es sich, einen Schritt zurückzugehen und Optionen zu vergleichen. Gerade an der Schnittstelle zwischen MCU und FPGA gibt es viele Graubereiche. Die Erfahrung zeigt, dass sich der entscheidende Unterschied oft in den Details versteckt.

Wir unterstützen euch dabei, solche Entscheidungen strukturiert zu treffen. Technisch, aber auch mit Blick auf Wartbarkeit, Team-Skills und langfristige Kosten. Kontakt CSA

Der Erfolg unserer Kunden ist auch unser Erfolg.