Reihe: Embedded World – Die unsichtbaren Gehirne verstehen (Teil 5)

Der Taktgeber – Zeit und Echtzeit in Embedded Systems

Von DerSchneider

Einleitung: Die verborgenen Rhythmen

In unserer menschlichen Wahrnehmung ist Zeit ein fließender Strom. Wir spüren ihren Lauf nicht direkt, sondern nur an ihren Wirkungen – am Stand der Uhr, am Wechsel von Tag und Nacht, am Altern der Dinge. Für ein Embedded System ist Zeit etwas völlig anderes: Sie ist ein regelmäßiger, unerbittlicher Puls, der jedes Geschehen im Chip taktet. Ohne diesen Puls ist das System tot. Mit ihm erwacht es zu einem rhythmischen Leben, das nach strengen Gesetzen abläuft.

Dieser Artikel widmet sich der Zeit in eingebetteten Systemen. Wir erkunden, wie ein Chip seinen Takt bekommt, wie er ihn misst und wie er es schafft, nicht nur schnell, sondern auch verlässlich zu sein – pünktlich zur richtigen Zeit am richtigen Ort. Und wir klären eines der am meisten missverstandenen Konzepte der Informatik: Was bedeutet eigentlich „Echtzeit“?

Hauptteil

1. Der Herzschlag des Systems: Der Taktgeber

Jedes digitale System braucht einen Takt. Stellen Sie sich vor, Sie müssten eine komplexe Choreografie mit hundert Tänzern koordinieren – ohne Dirigent, ohne Metronom, ohne gemeinsamen Rhythmus. Es wäre unmöglich. Genauso unmöglich wäre es für die Milliarden von Transistoren in einem Chip, geordnet zusammenzuarbeiten, wenn sie keinen gemeinsamen Takt hätten.

Diesen Takt liefert der Oszillator – eine Schaltung, die ein regelmäßiges elektrisches Signal erzeugt, das zwischen zwei Spannungszuständen hin- und herschwingt. Meistens ist das ein Quarzoszillator, der die piezo-elektrische Eigenschaft von Quarzkristallen nutzt: Legt man Spannung an, verformen sie sich; verformt man sie, erzeugen sie Spannung. In der richtigen Anordnung schwingt ein Quarz mit extrem präziser Frequenz – typisch sind 4, 8, 16 oder 20 Megahertz (Millionen Schwingungen pro Sekunde).

Jede Schwingung ist ein Taktzyklus. Und in jedem Taktzyklus kann die CPU eine bestimmte Menge an Arbeit erledigen – wie viele Befehle, hängt von der Architektur ab. Ein einfacher 8-Bit-Prozessor braucht oft mehrere Zyklen für einen Befehl, moderne Hochleistungsprozessoren schaffen mehrere Befehle pro Zyklus.

Die Taktfrequenz ist also die Geschwindigkeit, mit der der Chip arbeitet. Aber Vorsicht: Höhere Frequenz bedeutet nicht automatisch mehr Leistung. Ein 16-MHz-Prozessor kann durch geschickte Architektur mehr Arbeit erledigen als ein 20-MHz-Prozessor alter Bauart.

2. Die inneren Uhren: Timer und Counter

Der Taktgeber gibt den Grundrhythmus vor. Aber ein System braucht auch die Fähigkeit, Zeit zu messen – um nach einer Sekunde eine LED auszuschalten, um alle 10 Millisekunden einen Sensor abzufragen, um die Dauer eines Tastendrucks zu erfassen.

Dafür gibt es Timer und Counter – spezielle Hardware-Einheiten, die unabhängig von der CPU arbeiten.

Timer sind im Grunde digitale Stoppuhren. Sie werden mit einem Takt versorgt (oft dem Systemtakt oder einem geteilten Takt) und zählen hoch oder runter. Ein 16-Bit-Timer kann zum Beispiel von 0 bis 65.535 zählen. Erreicht er einen bestimmten Wert (den Compare-Wert), kann er einen Interrupt auslösen oder ein Signal erzeugen.

Counter sind ähnlich, aber sie zählen nicht den internen Takt, sondern externe Ereignisse. Jeder Impuls an einem bestimmten Pin erhöht den Zählerstand. So kann man messen, wie oft sich ein Rad dreht, wie viele Teile ein Förderband passieren, wie viele Tastendrücke erfolgen.

Die Kunst besteht darin, diese Hardware-Uhren geschickt zu nutzen. Ein gut programmiertes Embedded System verschwendet keine CPU-Zeit mit Warten, sondern lässt die Timer im Hintergrund laufen und wird nur bei Bedarf durch Interrupts geweckt.

3. Der Puls des Lebens: Was ist Echtzeit?

Kommen wir zum vielleicht wichtigsten und am meisten missverstandenen Konzept der Embedded World: Echtzeit.

Echtzeit bedeutet nicht „besonders schnell“. Ein System, das in Nanosekunden reagiert, aber manchmal erst nach einer Sekunde, ist nicht echtzeitfähig. Ein System, das in 10 Millisekunden reagiert – aber immer in 10 Millisekunden, zuverlässig, garantierbar –, das ist echtzeitfähig.

Die Definition lautet: Ein System ist echtzeitfähig, wenn es auf ein Ereignis innerhalb einer garantierten Zeitspanne reagieren kann. Die Korrektheit des Ergebnisses hängt nicht nur vom logischen Wert ab, sondern auch vom Zeitpunkt, zu dem es geliefert wird.

Man unterscheidet zwei Arten:

Harte Echtzeit: Wenn die Frist überschritten wird, hat das katastrophale Folgen. Der Airbag muss innerhalb von Millisekunden auslösen – tut er es nicht, ist der Fahrer tot. Die Motorsteuerung muss den Einspritzzeitpunkt exakt einhalten – tut sie es nicht, läuft der Motor unrund oder geht kaputt. Die Bremse muss sofort reagieren – tut sie es nicht, gibt es einen Unfall.

Weiche Echtzeit: Wenn die Frist überschritten wird, ist das ärgerlich, aber nicht katastrophal. Ein Videoplayer, der kurz ruckelt, ist lästig, aber niemand stirbt. Ein Temperatursensor, der einmal zu spät misst, verfälscht die Statistik, aber die Heizung fällt nicht aus.

Die meisten Embedded Systems müssen harte Echtzeitanforderungen erfüllen. Das ist es, was ihre Entwicklung so anspruchsvoll macht.

4. Echtzeit in der Praxis: Garantien statt Geschwindigkeit

Wie erreicht man Echtzeitfähigkeit? Nicht durch möglichst schnelle Hardware – obwohl die natürlich hilft –, sondern durch deterministisches Verhalten. Das System muss in jeder Situation vorhersagbar reagieren.

Das bedeutet:

• Keine unvorhersehbaren Verzögerungen: Ein Cache, der mal trifft und mal nicht, ist für harte Echtzeit problematisch. Eine Speicherverwaltung, die mal mehr und mal weniger Zeit braucht, ebenfalls.
• Priorisierung: Wichtige Aufgaben müssen unwichtige unterbrechen können. Dafür gibt es Interrupts mit Prioritäten.
• Nachweisbarkeit: Man muss rechnerisch beweisen können, dass unter allen Umständen alle Fristen eingehalten werden. Das ist oft schwieriger als das Programmieren selbst.

Ein Beispiel: Stellen Sie sich ein System vor, das alle 10 Millisekunden einen Sensor auslesen muss. Wenn die CPU gerade mit einer anderen Aufgabe beschäftigt ist, muss der Sensor-Interrupt diese Aufgabe unterbrechen können. Und es muss garantiert sein, dass diese Unterbrechung nie länger als die erlaubten 10 Millisekunden dauert.

5. Zeitfresser: Wo die Zeit verloren geht

In der Praxis lauern viele Zeitfresser, die die Echtzeitfähigkeit gefährden:

Interrupt-Latenz: Die Zeit vom Eintreffen eines Interrupt-Signals bis zum Beginn der Bearbeitung. Sie kann variieren, je nachdem, was die CPU gerade tut.

Prioritätsinversion: Ein klassisches Problem in Echtzeitsystemen. Ein hochpriorer Task wartet auf eine Ressource, die ein niederpriorer Task gerade hält – und der niederpriore Task wird von einem mittelprioren Task verdrängt. Der hochpriore Task wartet dann auf den mittelprioren, obwohl der niederpriore die Ressource freigeben könnte, wenn er nur laufen dürfte.

Scheduling-Overhead: Die Zeit, die das Betriebssystem braucht, um zu entscheiden, welcher Task als nächstes laufen soll.

Speicherzugriffe: Je nach Speichertechnologie können Zugriffszeiten variieren. Ein Flash-Zugriff kann länger dauern als ein RAM-Zugriff.

6. Zeit messen ohne Uhr: Der Watchdog-Timer

Eine besondere Form des Timers verdient eigene Erwähnung: der Watchdog-Timer. Er ist der Sicherheitsbeamte im System.

Die Idee ist einfach: Ein Timer läuft und muss regelmäßig von der Software zurückgesetzt werden. Wenn die Software das vergisst – weil sie abgestürzt ist oder sich in einer Endlosschleife verfangen hat –, läuft der Timer irgendwann ab und löst einen Reset aus. Das System startet neu.

Der Watchdog-Timer ist die letzte Verteidigungslinie gegen Software-Fehler. In sicherheitskritischen Systemen ist er unverzichtbar. Er sorgt dafür, dass ein eingebettetes System auch nach einem Fehler wieder in einen definierten Zustand zurückkehrt – und nicht einfach stehen bleibt.

7. Ein Beispiel aus der Praxis: Die Motorensteuerung

Stellen wir uns ein konkretes Beispiel vor: die Steuerung eines bürstenlosen Gleichstrommotors (BLDC). Solche Motoren stecken in Elektroautos, Drohnen, Waschmaschinen.

Die Anforderungen an die Zeit sind extrem:

• Alle 50 Mikrosekunden muss der Rotor-Winkel gemessen werden.
• Daraus muss in unter 20 Mikrosekunden die nächste Kommutierungsphase berechnet werden.
• Die PWM-Signale für die drei Phasen müssen mit einer Präzision von Nanosekunden getaktet werden.
• Gleichzeitig muss das System auf Not-Aus-Signale innerhalb von Mikrosekunden reagieren.

Das ist nur mit spezialisierter Hardware und echtzeitfähiger Software möglich. Timer erzeugen die PWM-Signale automatisch, ohne CPU-Beteiligung. Interrupts signalisieren, wann der Rotor eine bestimmte Position erreicht hat. Die CPU hat nur die eigentliche Berechnung zu erledigen – und muss garantiert pünktlich damit fertig werden.

8. Die Zeit als Ressource

In der Embedded-Welt ist Zeit eine Ressource wie Speicher oder Rechenleistung. Man muss sie einteilen, verwalten und sparsam einsetzen. Ein Programm, das zu viel Zeit verbraucht, gefährdet die Echtzeitfähigkeit des gesamten Systems.

Deshalb denken Embedded-Entwickler anders als PC-Programmierer. Sie fragen nicht nur: „Funktioniert das?“ Sie fragen auch: „Wie lange dauert das? Und ist diese Dauer immer gleich?“ Sie optimieren nicht nur auf Korrektheit, sondern auch auf Determinismus.

Fazit und Ausblick

Die Zeit ist in Embedded Systems kein abstrakter Fluss, sondern ein handfestes technisches Problem. Der Taktgeber gibt den Grundrhythmus vor, Timer und Counter messen die Zeit, und das Konzept der Echtzeit stellt sicher, dass alles pünktlich geschieht. Wer ein Embedded System verstehen will, muss verstehen, wie es mit der Zeit umgeht.

Doch Zeit allein genügt nicht. Das System muss auch mit der Außenwelt kommunizieren – Sensoren auslesen, Aktoren steuern, mit anderen Systemen sprechen. Dafür braucht es Schnittstellen, und zwar auf der untersten Ebene: direkt mit der Hardware.

Mit diesen Schnittstellen beschäftigen wir uns im nächsten Artikel.