Kommandos (zum Chip):
Ergebnisse (vom Chip):
Das Benutzerinterface zum ELM-Adpater ist eine einfache, zeilenorientierte ASCII Konsole. Nachfolgend sind die Regeln und erlaubten Zeichen detailliert beschrieben. Da Interface ist auf Effizienz gebaut und vermeidet unnötige Datentransfers zwischen ELM-Chip und Clientsoftware. Grundsätzlich kann es aber auch über ein Terminalprogramm genutzt werden.
Beim start des ELM-Chips stellt dieser über seinen internen UART eine serielle Schnittstelle bereit. Die beiden Leitungen RX/TX werden meist über einen Pegelwandler an einer RS232 Schnittstelle, oder mittels speziellem Chipsatz über USB, Bluetooth oder WLAN am Computer verwendet. Letztlich emulieren diese mit einem entsprechenden Treiber eine serielle Schnittstelle (COM-Port) im Betriebssystem.
Standardmässig startet der ELM-Chip mit 38.400 Baud, 8 Datenbits, keinem Parity-Bit und 1 Stopp-Bit (=38400 8N1).
Die Clientsoftware darf erst Befehle zum Chip senden, wenn dieser die Empfangsbereitschaft mit dem Prompt-Zeichen > angezeigt hat. Das Zeichen steht allein in einer eigenen Zeile.
Der Chip erwartet nun Kommandos in ASCII Kodierung. Dabei wird nicht zwischen Groß- und Kleinschreibweise unterschieden. Whitespace, also Leerzeichen, Tabulatorzeichen und sogar NULL-Zeichen (0x00) werden einfach ignoriert und können daher beliebig zur besseren Lesbarkeit mit übertragen werden.
Jeder Befehl muss mit einem Carriage-Return (nachfolgend dargestellt mit <CR>, \r oder ASCII 0x0D) abgeschlossen werden. Erst dann versucht der Chip diesen Befehl zu verstehen und auszuführen. Aus Kompatibilitätsgründen zu Windows Terminalprogrammen darf hinter dem Return-Zeichen auch noch ein Linefeed-Zeichen (<LF> oder \n oder ASCII 0x0A) folgen, welches jedoch ignoriert wird.
Eine leere Zeile, ohne einen Befehl bedeutet für den Chip, das der zuletzt erhaltene Befehl wiederholt werden soll.
Beginnt ein Kommando mit AT so erwartet der Chip Steuerbefehle. Alle anderen werden als OBD-Kommandos angesehen und dienen der Fahrzeugkommunikation. Sie dürfen nur die Zeichen [0-9A-F] in Form von HEX-Digits enthalten.
CMD := ( AT_CMD | DATA_CMD ), CR ;
AT_CMD := AT_PREFIX, [ { WS } ], AT_KEY, { [ { WS } ], HEX_BYTE } ;
AT_KEY := LETTER { LETTER } ;
AT_PREFIX := ( 'a' | 'A' ), ( 't' | 'T' ) ;
HEX_BYTE := HEX_DIGIT, HEX_DIGIT ;
HEX_DIGIT := NUMBER | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' ;
LETTER := 'A' | 'B' | ... | 'Z' | 'a' | 'b' | ... | 'z' ;
NUMBER := '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
WS := ' ' | '\t' | 0x00 ;
CR := '\r' [ '\n' ] ;
[b]Scanner[/b] Dann braucht es den Scanner welcher in meinem Fall vom UART liest, aber vielleicht auch so gebaut sein sollte das man ihn durch eine File-Scanner ersetzen könnte. Somit hätte man gleich die Möglichkeit „Skripte“ ausführen zu lassen.
[b]Lexer[/b] Der Lexer soll dann die Strings in Tokens umwandeln. Aus einem „AT“ wird dann wohl sowas wie ein AT_CMD symbol.
[b]Parser[/b] Aufgabe des Parsers wäre es dann die Syntax zu prüfen und aus der Tokensequenz eine Syntaxstruktur (Baumartik) zu erstellen die der Compiler versteht.
[b]Compiler[/b] Dieser führt dann die Tokens aus, ruft die jeweiligen Prozeduren auf und übergibt ihnen die syntaktisch zugehörigen Tokens. Das Ergebnis der Funktion wird dann an die UART zurückgeschrieben (oder in eine Datei, im Falle eines Skripts).
Nach erfolgter Ausführung liefert ELM entweder einen Statustext wie OK, NO DATA, ?, oder Daten in Hexadezimalschreibweise 03 19 8F 00 00 00 00 00, gefolgt von einem <CR>. Unbekannte Kommandos werden mit ? quittiert. Erfolgreich ausgeführte mit OK. Ein interner Timer bricht eine Befehlseingabe nach 20 Sekunden inaktivität ab und schreibt ein „?“ zurück.