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 waiting 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 these files and then 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 depentencies.

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 obx 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..