Allgemeines

Das Treffen der PEARL-User-Group bzw. des Arbeitskreises Embedded Systems, RTOS-UH/PEARL der GI-Fachgruppe Echtzeitsysteme und PEARL (REAL-TIME) fand am Donnerstag, 31.05.2007, 14:00-17:00 Uhr, mit 8 Teilnehmern am Institut für Regelungstechnik der Universität Hannover statt.

TOP1: PEARL 90 Weiterentwicklungen

• Innerhalb der Fachgruppe zeichnet sich durch das Ausscheiden einiger aktiver Mitglieder eine Art Generationswechsel ab.
• Der Workshop PEARL 2007 findet vom 6.-7.12.2007 in Boppard mit dem Thema Mobilität und Echtzeit statt. Wegen der hohen Resonanz mussten einige Beiträge abgewiesen werden.
• In 2006 wurden ca. 7.000 angemeldete Kopien von RTOS-UH ausgeliefert.

TOP2: Compiler und Laufzeitsysteme: Statusbericht und Ausblick

Behobene Fehler

• Unter Umständen hat der Compiler die neuen CHAR(1000)-Variablen in dem 32-Bit statt in den 16-Bit Adressraum der Task abgelegt.
• Ein CONVERT in eine CHAR(1000)-Variable erfolgte modulo 256.
• Mit dem neuen Lader 6.6-D wurde ein Fehler bei der Behandlung von CRC-Fehlern der S-Records behoben.

Ausnahmebehandlung und Signale

Vorgänge im Systemkern

Zunächst soll die betriebssystemseitige Bearbeitung von Ausnahmesituationen betrachtet werden. Dabei wird von einem normalen System mit dem Standard Error-Dämon #ERRDM ausgegangen. Es sind 3 unterschiedliche Ausnahmesituationen zu unterscheiden:

• 1. Hardwareinduzierte Ausnahmen: Die Rechnerhardware wurde mit einer nicht korrekt lösbaren Aufgabe betraut. Klassisches Beispiel: Es soll von einer nicht existenten Speicherzelle gelesen werden oder der gelesene Maschinenbefehl ist illegal kodiert. Aus der Sicht der gerade laufenden Software kommt das Ereignis unvorbereitet, wenngleich es an einen Maschinenbefehl gekoppelt ist - im Gegensatz zu von der Außenwelt getriebenen Interrupts. Der Prozessor wird bei dieser Ausnahmesituation wie bei einem Interrupt der höchsten Priorität nun zu einem speziellen Stück Code (im Supervisormode) geführt, welches den individuellen Errorcode erstellt und darin vorgibt, ob der verursachende Prozess anzuhalten ist. Der Verursacher kann hier sowohl eine Task als auch ein Supervisorprozess (kernel mode) sein. Supervisorprozesse dürfen aber keinesfalls angehalten werden sondern müssen zu einem funktionserhaltenden Ende geführt werden.
• 2. Softwareinduzierte Ausnahmen: Der Rechner funktioniert hardwareseitig korrekt, aber es ist eine (typischerweise datenabhängige) Fehlersituation aufgetreten. Klassisches Beispiel: die Software soll die Wurzel aus einer negativen Zahl bestimmen. Die Ausnahmesituation wird von der Software durch einen Betriebssystemaufruf (ERROR-Trap) eingeleitet. Durch die Kodierung des dem System mitgegebenen Error-Codes wird ein informeller Text erstellt. Auch hier wird dem System damit mitgeteilt, ob der laufende Prozess angehalten werden muss: Während man die Wurzel aus einer negativen Zahl ersatzweise mit Null beantworten kann (und die Task weiterlaufen kann), ist es nicht möglich, einer Prozedur übergebene (falsche) Zeiger (wrong parameterlist) zu reparieren. Im letzteren Fall muss die Task angehalten werden und sollte nicht entblockiert sondern beendet werden - eventuell durch einen Bedienerprozess oder manuell. Der Fehler kann stets einer Task angelastet werden.
• 3. Mischformen: Es gibt in fast allen Prozessoren Maschinenbefehle, die abhängig vom inspizierten Datum eine Ausnahmesituation auslösen oder auch nicht. Klassisches Beispiel: Der Indextester des PEARL-Compilers überprüft im Test-Mode mithilfe des CHECK-Traps ob der errechnete lineare Feldindex eine Zelle innerhalb des Feldes adressiert. Liegt das Element außerhalb, feuert der Maschinenbefehl eine Ausnahme. (Nebenbei: Beim PEARL-Indextester repariert das Ausnahmebehandlungsprogramm den Fehler und addressiert das erste Element des Feldes - Fortsetzung möglich!). Der Fehler kann typischerweise immer einer Task angelastet werden, wird daher wie eine softwaregetriggerte Ausnahme behandelt.

Im Nukleus ist für alle drei Ausnahmesituationen eine Behandlungsroutine integriert. Diese kann man - für alle Fälle, in denen der Fehler einer Task zugeordnet werden kann - so parametrieren, dass die verursachende Task gezwungen wird, selbst auf den Fehler zu reagieren. Dabei kann das zentrale Fehlermeldesystem (#ERRDM = Error-Dämon) ausgeschaltet werden. So arbeitet z.B. die Shell mit einem eigenen Handler und verwendet das Fehlermeldesystem nicht.

Das Involvieren des Error-Dämonen erfolgt über einen Ringpuffer, der in der Shell des verantwortlichen Users angelegt ist. Bei den Ausnahmesituationen, die nicht einer Task zugeordnet werden können, erfolgt die Fehlermeldung auf der Konsole - der Anschlusss eines eigenen Exception-Handlers ist für diese Situation nicht möglich und auch nicht sinnvoll. Aber: alle Interruptprozesse bringen zwangsweise (über den Malfunction-Exit) einen eigenen Handler mit. Dies ist eine markante Eigenschaft von RTOS-UH, die die Überlebenswahrscheinlichkeit erhöht.

Im folgenden Flussbild wird der Ablauf mit einer Ausnahme vom Typ 1 (Hardwarefehler) begonnen. Die Fälle 1,2 und 3 treffen sich an einem Sammelpunkt - immer dann, wenn eine Task als Verursacher feststeht.

Exception-Handler in PEARL

Die Signalbehandlung ist über den Anschluss sogenannter ON-Blöcke möglich. Bei der Definition des Bearbeitungsmodes kann auf Wunsch der normale Error-Dämon neben dem eigenen Handler seine Meldung machen, allerdings wird die Task dann in keinem Fall mehr suspendiert.

Neben dem Bearbeitungsmode muss eine Variable (die RST-Struktur) angegeben werden, in die das Betriebssystem im Fehlerfall Daten einschreiben kann. Dazu gehört die letzte überlaufene Zeilennummer, die letzte registrierte Modulnummer, der Errorcode, der Program Counter und ggf. der Induceparameter.

Es gibt zwei Stufen der Auslösung, die angewählt werden können.

• Nur schwere Fehler: Der PEARL-Code im ON-Block wird nur angesprungen, wenn es sich um eine Ausnahme mit gesetztem Suspend-Bit handelt. In diesem Fall kann die Task nicht an der Fehlerstelle fortgesetzt werden. Es ist aber möglich, per EXIT-Anweisung auf den Task-Grundlevel zurückzukehren oder Prozeduren abzubrechen. Über die Shell per INDUCE-Befehl gefeuerte Ausnahmen werden wie schwere Fehler behandelt, wenn der Induceparameter negativ ist. Auch wenn der Exception Handler bei einem leichten Fehler nicht angesprungen wird, so gibt es dennoch alle üblichen Einträge in die RST-Struktur. Nach Aufruf einer Prozedur kann man also abfragen, ob in ihr Fehler aufgetreten sind - auch wenn diese nicht zum Abbruch geführt haben.
• Alle Fehler: Jede Auslösung wird wie ein schwerer Fehler behandelt.

Sinnvollerweise wird die RST-Struktur als statisch alloziertes Objekt definiert. Damit kann sie am einfachsten auch von Prozeduren aus erreicht werden.

#DEFINE X_ERRDM 1; ! Invoke #ERRDM
#DEFINE X_SEO   2; ! Invoke Exception handler Severe Errors Only
#DEFINE X_ALL   4; ! Catch all errors

MODULE EXCDEMO;    ! A simple demo prog
SYSTEM; A1;
PROBLEM;
SPC A1 DATION OUT ALPHIC;
DCL RS STRUCT(/Lino FIXED,       ! Last registered line number
               Mono FIXED,       ! Last registered module number
               Ecount FIXED,     ! Exception counter (all)
               Errcode BIT(16),  ! 16-Bit error code
               PC BIT(32),       ! Program counter to exception
               Indpar FIXED,     ! Induce parameter
               Buffer(100) FIXED ! Reserve for later extensions
                /);

/* +P  */
TA:TASK;
DCL I FIXED;

ON E_(X_ALL+X_ERRDM) RST(RS);     ! Catch all, invoke #ERRDM too
! Task will go here if exception handler is executed
  PUT 'Exception fired at PC:', RS.PC TO A1 BY SKIP,A,B4(8);
  SUSPEND;
  ! Do whatever may be necessary
  EXIT -1;  ! Step one procedure level down if not on task level
  END;

!.... Task may be here for the first time or after exception

IF RS.Ecount > 0 THEN
  PUT 'Restarted', RS.Ecount TO A1 BY SKIP,A,F(4);
ELSE
  PUT 'Initial Start' TO A1 BY SKIP,A;
FIN;

I=2//0; ! Diese Barriere wird nicht ueberwunden

END; ! TASK

MODEND;

TOP3: Neue RTOS-UH Implementierungen

• Am IRT ist eine RTOS-UH Implementierung für die PPMC280/PPMC2800-Karte (MPC7447 PowerPC G4 mit 1 GHz, eine 128-Bit AltiVec-Einheit, 2 Ethernet-Ports und PCI) von Motorola entstanden. Das System beinhaltet einen Flash-Filemanager, der sich auch für den MPC555 eignet.
• Als Entwicklungstool kommt am IRT die freie IDE Code::Blocks zum Einsatz, die um eine Sprachunterstüzung (Syntax-Highlighting und Code-Folding) für PEARL90 und den RTOS-UH Assembler ergänzt wurde. Für aufwändige mathematische Berechnungen kommen mit Hilfe des GNU-C-Compilers der Fa. esd für RTOS-UH lauffähig gemachte Bibliotheken aus dem Internet, wie z.B. die GNU-Scientific-Library zum Einsatz.
• Herr Seebode berichtete des Weiteren über die Entwicklung eines Laders für Objektdateien im Executable-and-Linking-Format (ELF) mit dem u.a. die Ausgaben neuerer GNU-C-Compiler direkt unter RTOS-UH geladen werden können. Inzwischen wurde eine erste Version eines solchen ELF-Laders fertig gestellt und erfolgreich zum Testen von AltiVec-Code des Compilers gcc 4.2 eingesetzt.
• Eine RTOS-Implementierung für den MPC5554 steht zur Verfügung, die abweichende SPE-Einheit für Vectorbefehle und speziellen Floatingpoint Operationen wird zur Zeit jedoch noch nicht unterstützt.

TOP4: Berichte aus den Ingenieurbüros, Entwicklungsabteilungen und Forschungsinstituten

• In einer Diplomarbeit der FH Hannover soll in Kooperation mit der Fa. IEP ein preiswerter Einplatinencomputer auf Basis des 552-Prozessors aufgebaut werden. Dieser Prozessor hat im Vergleich zum 555 kein internes Flash und die resultierende Performance beträgt ca. 50% des 555. Das Board ist mit einem geplanten Preis von max. 100 € insbesondere für den Einsatz in der Lehre sowie für Studierende und Heimanwender gedacht. Aus dem Hochschulbereich wurde bereits Interesse an diesem preiswerten Einplatinencomputer für RTOS-UH geäußert.
• Neue RTOS-Tools der Fa. IEP sind: NTP Client/Server, DNS Auflösung sowie E-Mail Versand über den IEP TCP/IP-Stack. Die mit Java realisierte grafische Ausgabe eines RTOS-Rechners auf einem PC ist jetzt auch über ein Java-Applet im Browser möglich. Der P-Monitor wurde um Prozesslaufzeiten erweitert.

Torsten Lilge