Kommunikationsprotokoll

Kommandos (zum Chip):

• ELM-Commands beginnen mit „AT“, Modulparameter mit „ST“

• Jeder Befehl umfasst genau ein Zeile. Erst nach dem übermitteln des Zeilenende-Zeichens findet eine Befehlsauswertung und Ausführung statt.
• Das Zeilenende-Zeichen (Carriage-return) ist 0x0D („\r“) (Symboldarstellung: <CR>). Ein evtl. nachfolgendes (Linefeed) 0x0A („\n“) ist erlaubt und wird ignoriert.
• Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.
• Whitespace wird ignoriert (Space/Tab und alle anderen nicht -ASCII Controlzeichen, z.B. 0x00) („ATZ“ ist also dasselbe wie „AT Z“ oder „AT Z“)
• Nach dem ersten Kommando darf der Client immer erst weitere Kommandos senden, wenn er das Prompt-Zeichen '>' empfangen hat. Das Prompt-Zeichen steht in einer eigenen Zeile (aso erst „\r“ und dann „>“).
• ELM-Kommandos („AT …“) folgt ein ein oder mehrere Zeichen langes Schlüsselwort und ggf. ein oder mehrere Parameter (z.B. „AT E0“ für Echo aus, „ATE1“ für Echo ein, oder „AT CPHR 770 4a 33 7e 00“)
• OBD-Kommandos dürfen nur die Zeichen [0-9A-F ] in Form von HEX-Digits enthalten
• Ein interner Timer bricht unvollständige Zeilen (=fehlendes CR) nach 20 Sekunden inaktivität ab

Ergebnisse (vom Chip):

• Nach erfolgter Ausführung liefert ELM entweder einen Statustext („OK“, „NO DATA“, „?“) oder Daten („03 19 8F“) gefolgt von einem <CR>
• Anschließend wird das Prompt-Zeichen („>“) wieder dargestellt. Dem Prompt wird ein <CR> vorab gesendet.
• Unbekannte Nachrichten werden mit einem einfachen „?“ in der Antwort quittiert. Erfolgreich ausgeführte mit „OK“.
• Ein interner Timer bricht unvollständige Zeilen (=fehlendes CR) nach 20 Sekunden inaktivität ab und schreibt ein „?“ zurück.

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.