doc:lua_make-your-own-scripts
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
doc:lua_make-your-own-scripts [2014/03/10 07:48] – admin | doc:lua_make-your-own-scripts [2019/04/08 18:43] (current) – [The IO Commands] admin | ||
---|---|---|---|
Line 5: | Line 5: | ||
- | ===== What is Lua? ===== | ||
- | Simply said, [[http:// | ||
- | |||
- | |||
- | This allows to make a program now but change its behavior later as needed. This is widely used in the OOBD script engine: The script engine is there from the beginning, but what it does is defined by the script which is loaded at runtime. Another script, another functionality.. | ||
- | |||
- | |||
- | Luckely Lua became quite popular in the last years, so it's available for all major platforms, like Desktop PCs, Smartphone and Mobile Phones. | ||
- | |||
- | |||
- | There are tons of documentation about Lua available in the internet, so we'll not explain the wheel here once more, we'll just focus on how Lua works inside OOBD. | ||
Line 147: | Line 136: | ||
- | ==== The Communication | + | ==== The Communication Commands ==== |
OOBD uses (actual) serial communication to talk to the diagnostic device. To allow Lua to send and receive data from the serial port, a few extended Lua functions exists: | OOBD uses (actual) serial communication to talk to the diagnostic device. To allow Lua to send and receive data from the serial port, a few extended Lua functions exists: | ||
+ | |||
=== serFlush() === | === serFlush() === | ||
+ | |||
It just clears the input buffer (from anything which was maybe received in the meantime and which is not needed anymore) | It just clears the input buffer (from anything which was maybe received in the meantime and which is not needed anymore) | ||
Line 157: | Line 149: | ||
=== serWrite(String) === | === serWrite(String) === | ||
- | |||
- | Sends //String// to the output (which is normally the serial port) | ||
+ | Sends //String// to the output (which is normally the serial port) | ||
=== serSleep(milliseconds) === | === serSleep(milliseconds) === | ||
- | waits // | ||
+ | waits // | ||
=== serReadLn(msTimeout) === | === serReadLn(msTimeout) === | ||
+ | |||
reads from input until a LF (dez. 10 hex 0x0A) appears and returns that input as String | reads from input until a LF (dez. 10 hex 0x0A) appears and returns that input as String | ||
+ | |||
=== serWait(OptionString, | === serWait(OptionString, | ||
+ | |||
In case you want to wait for some input strings, of which several could appear, you fill the // | In case you want to wait for some input strings, of which several could appear, you fill the // | ||
- | ==== | + | ==== The IO |
- | === serDisplayWrite(String) === | ||
+ | FIXME the whole IO command section is in pure experimental state. There' | ||
+ | |||
+ | |||
+ | OOBD uses its own scheme for file IO, mainly driven by the restriction of a remote user and the need of complex data buffer handling. | ||
+ | |||
+ | |||
+ | Similar to the LUA simple IO model, OOBD has always only just input and output file handle. As long as not redirected, these are stdin and stdout. | ||
+ | |||
+ | |||
+ | As OOBD knows more as only one type of data sources, the parameter '' | ||
+ | |||
+ | |||
+ | . | ||
+ | |||
+ | |||
+ | === ioInput(file_name , | ||
+ | |||
+ | |||
+ | Tries to open the file accourding to the following parameter combinations: | ||
+ | |||
+ | |||
+ | ^ filename | ||
+ | |/ | ||
+ | |/ | ||
+ | |URL like '' | ||
+ | |URL like '' | ||
+ | |||
+ | |||
+ | After opening the file with IOInput(), it can be read with ioRead() | ||
+ | |||
+ | === ioRead(" | ||
+ | |||
+ | |||
+ | Read one line of the input file ending with either< | ||
+ | === ioRead (" | ||
+ | |||
+ | |||
+ | Read the whole file as string | ||
+ | |||
+ | |||
+ | === ioRead (" | ||
+ | |||
+ | |||
+ | Here it's assumed that the input file consists of a JSON string containing data. This string is translated into a lua table structure and returned | ||
+ | |||
+ | |||
+ | === ioRead (" | ||
+ | |||
+ | |||
+ | This mainly for testing purposes. It returns the sha256 checksum of that file | ||
+ | |||
+ | |||
+ | \\ | ||
+ | |||
+ | ==== The Buffer Commands ==== | ||
+ | |||
+ | |||
+ | FIXME this whole Buffer section is not implemented and actual just here as a reference for discussion | ||
+ | |||
+ | |||
+ | === loadbuffer === | ||
+ | len, newfilename= loadbuffer(start , filelen , file_name , file_extension , message) | ||
+ | |||
+ | Reads the file " | ||
+ | |||
+ | The data source can be defined as explained for the ioInput command. | ||
+ | |||
+ | The number of bytes read will be returned in " | ||
+ | |||
+ | The following conditions apply: | ||
+ | * The selected filename will be returned in " | ||
+ | * If filename is 0, the whole file will be read. If the length exceeds the telegram length, an error will be raised. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === savebuffer === | ||
+ | len, newfilename = savebuffer(start , filelen , file_name , file_extension , message) | ||
+ | |||
+ | Writes the telegram buffer starting at position " | ||
+ | |||
+ | The number of bytes written will be returned in " | ||
+ | |||
+ | The following conditions apply: | ||
+ | * The selected file name will be returned in " | ||
+ | * If len is 0, the whole telegram buffer will be written. | ||
+ | |||
+ | === setbuffer === | ||
+ | setBuffer(bufferNr , newSize ) | ||
+ | |||
+ | Changes the actual buffer used to buffer number " | ||
+ | |||
+ | If newsize is <> 0, the old buffer is deleted and new memory with size newmem is allocated | ||
+ | |||
+ | |||
+ | === copyBuffer === | ||
+ | copyBuffer(bufferNr ) | ||
+ | |||
+ | Copies the content of buffer | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === BlitBuffer === | ||
+ | BlitBuffer(frombuffer , startpos , topos , blocklen | ||
+ | |||
+ | Copies a memory block from the buffer " | ||
+ | |||
+ | In case the buffer len needs to be bigger, the buffer len is increased accourdingly. | ||
+ | |||
+ | === SetBufferLen === | ||
+ | |||
+ | |||
+ | | ||
+ | |||
+ | All other buffer commands can increase the ' | ||
+ | |||
+ | SetBufferLen sets the ' | ||
+ | |||
+ | The success of the SetBufferLen - operation is returned as function result as follows: | ||
+ | |||
+ | ^ input value of newSize | ||
+ | | < = 0 | available size of the buffer in bytes. This can be used to read the real allocated memory size of that buffer | ||
+ | | 1.. available size | new available size (= requested size) | | ||
+ | | > available size | available size of the buffer as **negative value ** . This is a fault condition | | ||
+ | |||
+ | As seen, a negative value given back indicates a fault condition, all other returned values are positive. | ||
+ | |||
+ | |||
+ | === SendBuffer === | ||
+ | Sends the actual buffer | ||
+ | |||
+ | |||
+ | |||
+ | ==== WriteString Command Syntax ==== | ||
+ | |||
+ | As default the command | ||
+ | |||
+ | serDisplayWrite(String) | ||
+ | |||
+ | |||
+ | writes //String// to the build in output console. But with an optional secound parameter as command this behavior can be changed: | ||
+ | |||
+ | serDisplayWrite(parameter, | ||
+ | |||
+ | The different commands have the following effects: | ||
+ | |||
+ | ^ parameter | ||
+ | | buffername | ||
+ | | - | clear | clears actual buffer content | | ||
+ | | - | clearall | ||
+ | | filename | ||
+ | | filename | ||
+ | | filename | ||
+ | | filename | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== Miscellaneous | ||
- | Writes //String// to the build in output console. | ||
=== dbLookup(db-File , searchstring) === | === dbLookup(db-File , searchstring) === | ||
- | Searches in the //db-file// for all entries with index // | + | |
+ | Searches in the //db-file// for all entries with index // | ||
dbLookup() returns a Lua table | dbLookup() returns a Lua table | ||
- | | + | |
- | myTable = dbLookup(" | + | |
+ | < | ||
+ | myTable = dbLookup(" | ||
+ | </ | ||
// | // | ||
- | * if // | ||
- | * if // | ||
- | * if // | ||
- | When something has been found, than //myTable// contains two sections, //header// and //data//. | + | |
+ | * if // | ||
+ | * if // | ||
+ | * if // | ||
+ | |||
+ | |||
+ | When something has been found, than // | ||
The header section is needed in case you don't know in which column your wanted result is stored; you can identify the column by its column header name instead: | The header section is needed in case you don't know in which column your wanted result is stored; you can identify the column by its column header name instead: | ||
- | col= myTable.header[" | ||
- | print (col) | ||
- | 2 | ||
- | |||
- | // | ||
+ | < | ||
+ | col= myTable.header[" | ||
+ | print (col) | ||
+ | 2 | ||
+ | </ | ||
- | The //data// section then contains the found data itself, arranged as a two dimensional array, sorted by rows and columns. | ||
- | | + | // |
- | + | ||
- | **ATTENTION**: | + | |
+ | The // | ||
+ | |||
+ | |||
+ | < | ||
+ | | ||
+ | </ | ||
+ | |||
+ | |||
+ | **ATTENTION**: | ||
+ | |||
+ | |||
+ | < | ||
+ | column=3 | ||
+ | row=2 | ||
+ | result=myTable.data[tostring(row)][tostring(column)]) | ||
+ | </ | ||
+ | |||
+ | |||
+ | Here after all a piece of sample code | ||
- | column=3 | ||
- | row=2 | ||
- | result=myTable.data[tostring(row)][tostring(column)]) | ||
- | | ||
- | | ||
- | Here after all a piece of sample code | ||
<code lua> | <code lua> | ||
myTable= dbLookupCall(" | myTable= dbLookupCall(" | ||
+ | |||
print (" | print (" | ||
for k,v in pairs (myTable.header) do | for k,v in pairs (myTable.header) do | ||
print (k," | print (k," | ||
end | end | ||
+ | |||
nrOfColumns = myTable.header.size | nrOfColumns = myTable.header.size | ||
nrOfRows = myTable.len | nrOfRows = myTable.len | ||
+ | |||
print ("Rows x Columns:" | print ("Rows x Columns:" | ||
- | + | ||
+ | |||
for row = 1 , nrOfRows , 1 do | for row = 1 , nrOfRows , 1 do | ||
for column = 1 , nrOfColumns, | for column = 1 , nrOfColumns, | ||
- | | + | |
print (cy, cx, myTable.data[tostring(row)][tostring(column)]) | print (cy, cx, myTable.data[tostring(row)][tostring(column)]) | ||
end | end | ||
end | end | ||
</ | </ | ||
+ | |||
+ | |||
+ | === openXCVehicleData(lua table) === | ||
+ | |||
+ | |||
+ | OOBD can work as VehicleDatasource for [[http:// | ||
+ | |||
+ | |||
+ | To do so, a lua table is filled with the right indentifiers and correct formated values accourding to the [[https:// | ||
+ | |||
+ | |||
+ | With that table openXCVehicleData() is called and the data are been transferred to the openXC backbone task for further handling. | ||
+ | |||
+ | |||
+ | < | ||
+ | openXCVehicleData({timestamp= 1332794087.675514, | ||
+ | </ | ||
+ | |||
+ | |||
+ | So everything which is understood by openXC can be generated out of a OOBD lua script. | ||
===== Some Programming Tricks ===== | ===== Some Programming Tricks ===== |
doc/lua_make-your-own-scripts.txt · Last modified: 2019/04/08 18:43 by admin