Dynamische Adaption in heterogenen verteilten eingebetteten ...

4.5 Aufbau und Architektur
Anwendung Verwalter
Anwendung IRQ
Verwalter
Anwendung
Verwalter
REQ
peek
poke
...
resume
REQ
peek
poke
...
resume
T2
T1
T3
REQ
peek
poke
...
resume
(a) direkt im Task
(b) im IRQ-Handler
(c) durch neue Tasks
Abbildung 4.21: Abarbeitung der Befehle im Rahmen einer Unterstützungsanforderung
Teilabbildung (a) zeigt die Abarbeitung der Befehle durch den Task der Anwendung. Im Rahmen von Unterstützungsanforderungen
ist dies eine sinnvolle Realisierung, da der Task auf die Fertigstellung der Operationen angewiesen ist. Die
Bearbeitung von unaufgeforderten, asynchron eintreffenden Befehlen ist mit diesem Ansatz jedoch nur möglich, wenn
der Task regelmäßig und aktiv die Kommunikation überprüft.
Teilabbildung (b) zeigt die Bearbeitung der Operationen direkt im Rahmen der Unterbrechungsbehandlung. Nachteil
dabei ist, dass während der Abarbeitung keine anderen Unterbrechungen bearbeitet werden können. Gleichzeitig ergibt
sich daraus jedoch auch der Vorteil, dass die Operationen nicht mit anderen Aufgaben koordiniert werden müssen.
In Teilabbildung (c) wird für jeden eintreffenden Befehl eine neue Aufgabe (Task) erzeugt, die nebenläufig zur Anwendung
ausgeführt wird. In Systemen, die nur einen Aktivitätsträger anbieten, kann dieser Ansatz nicht bei der Bearbeitung von
Unterstützungsanforderungen angewandt werden, da hierzu ein weiterer Aktivitätsträger zur parallelen Abarbeitung der
Aufgaben zur Verfügung stehen müsste.
dabei aus derselben Codebasis für verschiedene Architekturen gebaut. Grundsätzlich hängt die Größe
des RCMs von der Funktionalität ab. Das hier verwendetet RCM enthält das beschriebene Kommunikationsprotokoll
zur zuverlässigen Übertragung und eine flexibel erweiterbare Befehlsverarbeitung, die
bei der Version für AVR Mikrocontroller genutzt wurde, um zusätzliche peek und poke Befehle für
den Zugriff auf den Programmspeicher anzubieten.
Architektur .text .rodata .data .bss Total
Atmel AVR ATmega 1314 38 20 263 1635 Byte
Renesas H8/300 1150 96 0 8 1254 Byte
Intel x86 888 116 0 14 1018 Byte
Tabelle 4.5: Größe eines flexiblen Fernwartungsmoduls (RCM) in Byte
Die Tabelle zeigt die Größen eines RCMs für verschiedene Architekturen in Byte. Auffällig ist, dass die Version für
AVR-Mikrocontroller deutlich größer ist. Das liegt daran, dass hier separate peek und poke Befehle implementiert
wurden, um auf den Programmspeicher zuzugreifen, da es sich um eine Harvard-Architektur handelt.
Da der Programmspeicher als Flashspeicher realisiert ist, wird außerdem spezieller Code benötigt, um diesen seitenweise
zu beschreiben. Dieser Code nimmt mehr Platz in Anspruch als das einfache Setzen einer Speicherstelle auf den
beiden anderen Architekturen. Zusätzlich wird Datenspeicher in der Größe einer Seite (hier: 256 Byte) benötigt, um die
Daten vor dem Schreiben zwischenzuspeichern.
Im Vorfeld wurden auch einfachere Versionen des RCMs erstellt, die deutlich machen, wie viel
Speicherplatz man einsparen kann, wenn man mit minimalem Funktionsumfang auskommt. So wurde
ein Fernwartungsmodul erstellt, welches ein sehr einfaches Kommunikationsprotokoll verwendet, das
keine Übertragungsfehler erkennt oder toleriert. Außerdem ist der Befehlsumfang dieses RCM fest
vorgegeben und nicht flexibel erweiterbar. In Tabelle 4.6 sind die Größen für diese Implementierungen
angegeben.
87