Während man die OOBD Scripte 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.

In opposite to most other Lua implementations OOBD does not use the ASCII source code directly, for performance reason it loads precompiled Lua files instead.

These precompiled files are generated by the luac compiler, which is part of the lua package. But this luac compiler has one big disadvantage, as it totally ignores include commands in the source files, and it's quite disappointing to always add all these different dependencies by hand to the build process.

To automate this, olp was written. It just reads the initial source file, identifies the dofile() commands in it, reads also recursively the files to include and finally writes the whole source tree as one single text to stdout, where it can be picked up by the luac compiler and compiled to a single binary, containing all dependencies.

Thanks to the efforts of the ODX standardization its possible to describe the command sets of an electric control module in a formal syntax.

But to use these information in OOBD or other tools, it's nessesary to transform these ODX syntax into a format which is understood by the tools.

This is what OpenDiagX do. Honestly OpenDiagX is nothing more as a simple XSLT transformer, but as the ODX input format and output format needed for OOBD (and SKDS) are so different, the author decided to wrap some software around the translation process - which means that an XSLT specialist could maybe do the whole translation only in xslt - but the author can't..

The software is available in two variants: OpenDiagXGUI and OpenDiagXCL. The GUI version is mainly for testing purposes, while the CL (Command Line) is made to use in batch or make files. Both programs do basically the same, so we have a very short look into the command line syntax

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

and look deeper into the GUI variant, as this explains it all:

When the program is started, it first scans its two subfolders “input” and “output” for contained *.xslt files. The found files are then shown in the two selection boxes “Input-Format” and “Output-Format”.

Then the user chooses the “Input” file by using the file browser button on the right and presses “Start”

Then the following sequence starts:

1. The input file is loaded. It must be a valid XML file
2. The input is transformed via XSLT using the transformation rules given by the selected “Input-Format”
3. After that OpenDiagX goes though the internal file representation and makes it's own format out of it. Also this internal format is an XML tree
4. Finally this internal XML is transformed via the “Output-Format” rules and displayed in the text field.
5. From there the result can be saved as file.

When using the output format “plain” (included in the OOBD software repository), the output is a 1:1 copy of the internal data representation.

Also the input format “mdx” is also just a 1:1 translation of the input, because the program reads in reality the MDX format (a OEM specific dialect) instead of “real” ODX. But when having a working ODX-MDX XSLT file handy, this can be copied into the “input” folder and than OpenDiagX could read ODX files directly.

This little utility is used to generate a list of files in a directory in a makefile compatible format.

It's called as vbs script via

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

But let's take an example - having a directory content like this

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

then the call

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

would generate the following file output text:

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

where this output file can than easily included in e.g. makefiles

OOBD uses an own file format for its key → value lookup table databases. These files can be generated with oodbcreate.

To allow the easy re- use of common source code structures inside the OOBD firmware, we've made our own tailored source code template tool oobdtemple