Perfektes Timing

Der Scheduler



Für seinen Entscheidungsprozess benötigt der Scheduler exakt drei eTPU-Zyklen. Betrachtet man einen Prozessor, der mit einem Systemtakt von 100 MHz arbeitet – dies ist weder das Maximum noch das Minimum für Prozessoren mit integrierter eTPU –, so kann der Servicevorgang für ein Ereignis 60 ns nach Eintreten des Ereignisses gestartet werden. Diese Zeit ist wesentlich kürzer als die Interruptlatenzzeit der CPU. Auf der anderen Seite kann diese Zeit auch länger sein, wenn mehrere Service-Anforderungen gleichzeitig anstehen. Gute eTPU-Funktionen sollten sich nicht lange mit Servicevorgängen für einen Kanal aufhalten, um die anderen Kanäle nicht zu vernachlässigen. Aufgaben mit anspruchsvollem Timing sollten daher als mehrere Servicevorgänge unterschiedlicher Ereignisse oder als Servicekette für ein Ereignis organisiert werden.


Warum beträgt die Integergröße der eTPU 24 bit und nicht 16 oder 32 bit? Was bedeuten diese 24 bit Auflösung für ein Timing-Modul?
Betrachtet man einen 100-MHz-Prozessor, dessen eTPU mit einer maximalen Frequenz von 50 MHz (100 MHz/2) getaktet wird, bedeutet das, dass die Auflösung der eTPU bei 20 ns (1/50 MHz) liegt. Die eTPU kann einen Ausgangspin zur vorgegebenen Zeit mit einer Genauigkeit von ±10 ns umschalten, und sie kann auch den Zeitpunkt einer Signalflanke mit einer Genauigkeit von ±10 ns erfassen. Das ist wirklich gut, aber nicht übertrieben (hängt von der Anwendung ab). Gleichzeitig kann die eTPU-Hardware mit der oben beschriebenen Genauigkeit einen Impuls mit einer maximalen Dauer von 0,335 s (224 x 20 ns) erzeugen bzw. messen.
Zieht man eine Auflösung von 16 bit in Betracht, so läge die maximale Impulsdauer bei 0,0013 s, ist also nicht ausreichend, und mit einer Genauigkeit von 32 bit wäre sie bei 1 min 25 s, was sich als unnötig erweist.

Bisher wurden Aufgaben und interne Struktur der eTPU beschrieben, nun geht es um den praktischen Einsatz der eTPU in einer echten Applikation. Für den Einsatz der eTPU-Bibliothek reichen zwei einfache Schritte aus.

Ziel des ersten Schrittes ist es, den binären Programmcode für die eTPU zu erzeugen. Der Codespeicher der eTPU ist nicht groß genug, um die ganze eTPU-Bibliothek aufnehmen zu können. Außerdem benötigt keine Anwendung alle Funktionen gleichzeitig. Es reicht aus, die benötigten Funktionen aus der Bibliothek auszuwählen und diese zu verlinken. Für diesen Zweck steht auf der Website von Freescale [1] ein einfaches Compilertool zur Verfügung. Wie in Bild 2 gezeigt, wählt der Anwender die eTPU-Funktionen, die er in seiner Anwendung nutzen will. Mit einem Klick auf die Schaltfläche „Compile“ wird der binäre Programmcode der eTPU erzeugt und für den Download auf den Computer des Anwenders vorbereitet.

Auslastung der eTPU

Die Zuordnung der Kanäle durch die eTPU-Funktionen und die Einstellung der Funktionsparameter sind die bestimmenden Faktoren für die Auslastung der eTPU. Die Auslastung lässt sich mit Hilfe des „eTPU Graphical Configuration Tool“ abschätzen und in Prozent ausdrücken. In den meisten Fällen fällt das Ergebnis überraschend gut aus; nur in wenigen Anwendungen kommt man zu einer signifikanten Auslastung der eTPU. In diesem Fall ist es wichtig, sich das Timing der auf der eTPU laufenden Funktionen etwas genauer anzusehen. Man muss prüfen, ob die maximal für einen Servicevorgang anfallende Wartezeit nicht so lang wird, dass sie die korrekte Funktion beeinträchtigt. Diese Aufgabe ist alles andere als trivial. Man muss den Scheduler-Algorithmus, die Zuordnung der Kanäle durch die eTPU-Funktionen, die Funktionsparameter, die Parameter der Eingangssignale, die Kanalprioritäten und alle Servicezeiten mit einbeziehen. Der einfachere Weg besteht darin, den eTPU-Simulator zu nutzen, um die kritischste Situation zu simulieren und sich das Timing anzusehen.