|
|
 |
|
Echtzeitsysteme (EZS) - WS 2005/06
Entwickklungsumgebung
Übersicht
Werkzeuge
Entwicklungsbaum
Make
Als Werkzeuge kommen zum Einsatz:
- GNU H8/300-Cross-Toolchain von KPIT/Cummins
- GNU make
- RCXSimulator
- Subversion
| Verzeichnis |
Beschreibung |
debug |
Bibliothek zum schreiben von Testfällen. Enthält z.B. Makros und Funktionen zum gezielten Auslösen von Unterbrechungen, zur Zeitmessung oder um eine bestimmte Zeitspanne zu warten. |
devices |
Gerätetreiber. Hier finden sich alle Gerätetreiber, sowohl abstrakte Geräte, die eine einheitliche Schnittstelle zur Anwendung ermöglichen, als auch die Abbildung von real existierender Peripherie auf Software-Konstrukte. |
gen |
In diesem Verzeichnis landet alles, was in durch einen Aufruf von make erzeugt wird - Objektdateien, Doxygen-Dokumentation ... |
infra |
Typdefinitionen für EZ-Stubs und andere kleine Helfer, die in den Implementierungsdateien von EZ-Stubs verwendet werden, sich aber nicht sinnvoll zu anderen Modulen zuordnen lassen. |
interrupt |
Unterbrechungsbehandlung und Unterbrechungssynchronisation. |
make |
Alles was nötig ist, um EZ-Stubs zu bauen. |
object |
Eine kleine Hilfsbiblothek für EZ-Stubs, enthält z.B. eine verkettete Liste. |
shutdown |
Alles was EZ-Stubs herunterfährt. |
startup |
Alles was EZ-Stubs zum starten benötigt. |
tests |
Testfälle |
thread |
Der Thread-Abstraction-Layer. Hier findet man die Fadenimplementierung, den Dispatcher, den Scheduler ... |
Für alle Header- und Implementierungsdateien in diesem Verzeichnisbaum sind Dateiendungen wie folgt zu verwenden: .h für Header-Dateien, .cc für C++-Implementierungsdateien und .s für Assembler-Implementierungsdateien.
Zum Übersetzen, Binden und Ausführen von EZ-Stubs und den enstprechenden Testfällen steht eine Makefile zur Verfügung. Bevor diese Makefile jedoch benutzt werden kann, müssen noch einige Parameter eingetragen werden:
In der Datei make/variables_h8.mk:
Die Variable TOOL_PATH enthält den Pfad, in sich dem der H8/300-Cross-Compiler befindet, d.h. TOOL_PATH = <pfad> und der Pfad für den h8300-elf-gcc lautet <pfad>/bin/h8300-elf-gcc, im CIP-Pool wäre das dann /proj/i4ezs/tools/gcc.
In der Datei make/variables_h8_rcx.mk:
- Die Variable
RCX_DIR deutet auf das Verzeichnis, in dem alles für den RCX zu finden ist, im CIP-Pool wäre das dann /proj/i4ezs/tools/RCX.
- Die Variable
RCXTTY gibt das Linux-Gerät an, über das man den Lego-USB-Tower ansprechen kann. Diese Variable muss nicht unbedingt gesetzt sein, wenn man das Testprogramm nur auf dem Simulator ausführen bzw. debuggen will, weil es dafür nicht notwendig ist, das Programm über irgendeine Schnittstelle auf die Zielplattform zu laden.
- Die Variable
JAVA deutet auf die JVM, die zum Ausführen des RCXSimulator verwendet wird, wenn eine Java-JVM im Pfad liegt, wird diese Variable automatisch richtig gesetzt (Achtung Java-Version => 1.4).
- Die Variable
GDBPORT gibt an, auf welchem Port der RCXSimulator auf eine Verbindung vom GDB wartet, diese Variable ist auf die eigene User-Id zu setzen (die erfährt man mittels id).
Es stehen folgende Make-Targets zur Verfügung:
| Target |
Beschreibung |
help |
Gibt die verfügbaren Make-Targets zusammen mit einer Erläuterung auf der Konsole aus (entspricht in etwa dieser Tabelle). |
all |
Übersetzt den Quelltext von EZ-Stubs und erzeugt die EZ-Stubs-Bibliothek. |
doxygen |
Erzeugt die HTML-Quelltext-Dokumentation. |
showtests |
Zeigt die verfügbaren Testfälle an. |
<test>.elf |
Übersetzt und bindet den Testfall <test>. |
<test>.clean |
Räumt den Testfall <test> auf. |
<test>.sim_exec |
Führt den Testfall <test> auf dem RCXSimulator aus. |
<test>.sim_gdb |
Führt den Testfall <test> auf dem RCXSimulator aus und startet den GDB-Debugger. |
<test>.sim_ddd |
Führt den Testfall <test> auf dem RCXSimulator aus und startet den DDD-Debugger. |
<test>.target_exec |
Lädt den Testfall <test> auf den RCX und führt in dort aus. |
<test>.target_debug |
Lädt den Testfall <test> auf den RCX und startet den Debugger (Steht für den RCX leider NICHT zur Verfügung!!!). |
Das Fragment <test> ist der Pfad zu einer Testfallimplementierung ohne die entsprechende Dateiendung. Hat man z.B. in der Datei tests/test1/test1.cc einen Testfall implementiert, so ist <test> durch tests/test1/test1 zu ersetzen.
|
|
|
|
