Under the assumption, that it will be mostly other software which talks to the interface, the command structure was made simple, but flexible.

To archive this, the interface knows only two different kind of inputs, data or parameters

input:

data <CR>

where data is defined as (in EBNF- Syntax)

data = hex , { hex };
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
hex = "A" | "B" | "C" | "D" | "E" | "F" |"a" | "b" | "c" | "d" | "e" | "f" | digit ;

input:

p key value <CR>

where the definion is as follows

p = "p" | "P" ;
key = number ;
value = number ;
number = digit , {digit } | "$" , hex , { hex } ;

Sending 11 bytes of data

input:

 112233445566778899AABB

if the number of input chars is not even, the last char is handled as MSB of the last byte, so

 112233445566778899AAB

is send as

 112233445566778899AAB0

Set the parameter 127 to 64:

p 127 64

the same, but with hexadecimal notation:

p $7F $40

The format of the data given back on a data or parameter input is depending on the actual active protocol and bus implementation.

Important Sending data locks the input until the receive tasks times out.

The OOBD interface is designed to allow generic protocols and busses. For that reason only some parameters can be common for all possible cases (the so called global parameters). All other ones are protocol or bus specific.

max: implementation specific (unsigned long)