Die OOBD Hilfsmittel

Während man die OOBD Skripte prepariert, gibt es verschiedenste Daten die transformiert werden müssen, um innerhalb von OOBD benutzbar zu sein. Um dies einfacher zu gestalten, gibt es einige Hilfmittel, die diesen Zweck erfüllen. Hier wird erklärt, welche das sind, für was sie gut sind und wie man sie benutzt.

Die Firmware auf dem CAN-Invader kann im Arbeitsumfeld mittels Bluetooth-Schnittstelle neu programmiert werden. Das ist aber etwas gefährlich, wenn man ein Gerät über eine kabelose unsichere Verbindung aktualisiert. Deshalb müssen wir einen gewissen Schutz einbauen, damit nichts passiert, wenn während der Programmierung die Verbindung abbricht.

Wir haben dies gemacht, in dem wir den Bootloader in die Lage versetzt haben, herauszufinden ob das Gerät valide Firmware enthält oder nicht. Wenn sie valide ist, startet der Bootloader die Firmware bis zum Abschluss des Programmiervorgangs. Ist sie nicht valide, springt der Bootloader in die Programmierroutine und wartet darauf das die korrekte Firmware ankommt.

Um dies abzuspeichern, wird die Firmware mit einer zusätzlichen Checksumme geschützt. Das Programm cortex_crc32 berechnet diese Summe und fügt sie an das Binärfile der Firmware. Damit kann danach das Gerät programmiert werden.

Im Gegensatz zu den meisten anderen Lua Implementationen, benutzt OOBD den ASCII Quellkode nicht direkt, sondern lädt aus Performancegründen anstelle Dessen die vorkompilierten Lua Dateien.

Diese vorkompilierten Dateien werden durch den luac Kompilierer erzeugt, welcher Teil des Lua Pakets ist. Aber dieser luac Kompilierer hat einen großen Nachteil. Er ignoriert total irgendwelche include Kommandos in den Quelldateien und es ist sehr ernüchternd diese verschiedenen Abhängigkeiten per Hand zusammenzubinden.

Um dieses zu automatisieren, wurde olp geschrieben. Es liest eine initiale Quelldatei, identifiziert die dofile() Kommandos in Diesem, liest also rekursiv die Dateien die inkludiert werden sollen und schreibt dann zum Schluss den gesammten Quellbaum auf die Standart Ausgabeschnittstelle. In dieser wird es von dem luac Kompilierer aufgenommen und übersetzt in ein einziges Binärfile das alle Abhängigkeiten enthält.

Dank der Bemühungen der ODX Standardisierung ist es möglich, die Kommandosammlung eines elektrischen Kontrollmoduls in einer formaler Syntax zu beschreiben.

Aber um diese Information in OOBD oder anderen Werkzeugen zu nutzen, ist es notwendig diese ODX Syntax in ein Format zu transformieren, das von den Werkzeugen verstanden wird.

Dies ist etwas was OpenDiagX für Dich tut. Ehrlich gesagt ist OpenDiagX nichts anderes als ein simpler XSLT Transformer. Aber weil das ODX Ein- und Ausgabeformat welches für OOBD (and SKDS) benutzt wird so unterschiedlich ist, entschied der Autor etwas Software um den Übersetzungsprozess zu bauen - was bedeutet das ein XSLT Spezialist diese Übersetzung wohlmöglich ausschlieslich in xslt ausgestalten könnte - aber der Autor kann's leider nicht..

Die Software ist verfügbar in zwei Varianten: OpenDiagXGUI und OpenDiagXCL. Die GUI Version ist hauptsächlich für Testzwecke gedacht, während die CL (englisch: Kommandozeile) erfunden worden ist, um in Stapelbearbeitungsdateien oder in Makefiles genutzt zu werden. Beide Programme machen grundsätzlich das Gleiche, und so können wir einen kurzen Blick in die Kommandozeilensyntax werfen

opendiagxcl input-xslt-file output-xslt-file inputfile outputfile

und ein tieferer Blick in die GUI Variante, erklärt dies allumfassend:

Wenn das Programm gestartet ist, untersucht es zuerst seine sich in den Unterordnern “input” und “output” befindliche .xslt Dateien. Die gefundenen Dateien werden dann in den zwei Auswahlboxen “Input-Format” und “Output-Format” angezeigt.

Danach wählt der Benutzer die “Input” Dateien aus, in dem er den Dateibrowserknopf zur Rechten auswählt und dann den “Start” Knopf drückt

Danach startet die folgende Sequenz:

1. Die Eingabedatei wird geladen. Dies muß eine valide XML Datei sein
2. Die Eingabe wird dann mittels XSLT transformiert, wobei die Tranformationsregeln durch das im “Input-Format” Ausgewählte bestimmt wird
3. Danach geht OpenDiagX durch die interne Datenrepräsentation und erstellt sein eigenes Format daraus. Das interne Format ist ein XML Baum
4. Zuletzt wird dieses interne XML mit Hilfe der in “Output-Format” eingestellten Regeln transformiert und in dem Textfeld dargestellt.
5. Von dort kann das Ergebnis als Datei abgespeichert werden.

Wenn das Ausgabeformat “plain” genutzt wird (enthalten im OOBD Software Repository) ist die Ausgabe eine 1:1 Kopie der internen Datenrepräsentation.

Ebenso ist das Eingabeformat “mdx” auch nur eine 1:1 Übersetzung der Eingabe, weil das Programm in der Realität das MDX Format (Ein OEM spezifischer Dialekt) einliest, anstelle von “richtigem” ODX. Aber wenn man eine handliche ODX-MDX XSLT-Datei erzeugen möchte, kann man dieses in den “Input”-Ordner kopieren und dann kann OpenDiagX die ODX Dateien direkt lesen.

Dieses kleine Hilsmittel wird benutzt, um eine Liste von Dateien in einem Verzeichnis in einem Makefile kompatiblen Format zu erzeugen.

Es wird aufgerufen als vbs Skript via

cscript filelist.vbs directory_to_scan Prefix1 fileext1 [Prefix2 fileext2] > outputfile.txt

Aber lasst uns ein Beispiel betrachten - Wir haben einen Verzeichnisinhalt wie diesen hier

script1.lua
spec1.mdx
spec2.mdx
script2.lua
spec3.mdx
somethingelse.foo

dann rufen wir

cscript filelist.vbs . "SOURCES=" lua "SPECS=" mdx >output.txt

auf, welches den folgenden Datenausgabetext erzeugt:

SOURCES= script1.lua script2.lua
SPECS= spec1.mdx spec2.mdx spec3.mdx

wobei diese Ausgabedatei dann sehr leicht in z.B. Makefiles eingebunden werden kann

OOBD nutzt ein eigenes Datenformat für seine Schlüssel → Wert Lookuptabellen Datenbanken. Diese Dateien kann man mit tools_oodbcreate erzeugen.

Um eine einfache Wiedernutzung von gemeinsamen Kodestrukturen zu ermöglichen, haben wir unser eigenes zugeschnittenes Quellkodetemplate Werkzeug tools_oobdtemple erstellt

+ + OOBDcmd ermöglicht es, sich mit dem OOBD Dongle über die Kommandozeile zu unterhalten, hauptsächlich um automatische Testskripts zur Anwendung zu bringen.