While preparing the OOBD scripts, there are several data which needs to be transformed to be usable inside OOBD. To make this easier, there are a few tools made for these purpose. This page explains which they are, for what they are good for and how to use them.

The firmware of our OOBD cup, the tiny OBD Bluetooth adaptor can be updated in the field via its Bluetooth interface. But as it is a little bit dangerous to flash a device over a wireless unsecure connection, we need to do some protection in case the connection breaks during flashing.

We did it that way that the bootloader is able to identify if the device contains valid firmware or not. If it is valid, the bootloader starts the firmware ready to run, but if it isn't, the bootloader jumps into the flash routine and waits for correct firmware to arrive.

To archive this, the firmware is armended with a additional checksum. The tool cortex_crc32 calculates this sum and add this to the firmware binary, which then can be used for flashing.

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