UART-CAN-Protokoll: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
KKeine Bearbeitungszusammenfassung |
|||
Zeile 1: | Zeile 1: | ||
[[en:UART-CAN-Protocol]] | |||
Das UART-CAN-Protokoll (UCP) dient der Übertragung von CAN-Nachrichten über andere Medien, wie zum Beispiel einer Telefonleitung oder über das Internet. | Das UART-CAN-Protokoll (UCP) dient der Übertragung von CAN-Nachrichten über andere Medien, wie zum Beispiel einer Telefonleitung oder über das Internet. | ||
Version vom 16. Oktober 2012, 09:55 Uhr
Das UART-CAN-Protokoll (UCP) dient der Übertragung von CAN-Nachrichten über andere Medien, wie zum Beispiel einer Telefonleitung oder über das Internet.
Im Jahr 2005 wurde UCP von der Firma BÖHNKE + PARTNER GmbH entwickelt und offen gelegt. Das Protokoll hat zzt. noch keinen endgültigen Status erreicht und es können sich noch Änderungen ergeben.
Über den aktuellen Status des Protokolls informiert die Englische Version dieser Webseite.
Telegrammaufbau
Datenrahmen
Flag | Address | Information | CRC | Flag |
---|---|---|---|---|
8-Bits | 8-Bits | n * 8-Bits | 16-Bits (lo,hi) | 8-Bits |
Steuerzeichen
Flag | 0x7E |
ESC | 0x7D |
Transparenz
Flag | ESC + (Flag ^ 0x20) => 0x7D,0x5E |
ESC | ESC + (ESC ^ 0x20) => 0x7D,0x5D |
Checksumme (CRC-16, siehe RFC-1662)
X^16 + X^12 + X^5 + 1
Address
0 | Daten vom Gateway (A) |
1 - 8 | CAN-Telegramm vom Netzwerk 1 .. 8 |
9 - 127 | reserviert |
128 | Daten für Gateway (B) |
129 - 136 | CAN-Telegramm für Netzwerk 1 .. 8 |
137 - 254 | reserviert |
255 | CAN-Telegramm für alle Netzwerke (broadcast) |
Information (CAN Nachricht, siehe SJA1000)
Descriptor 1 | Descriptor 2 | Data (RTR = 0) |
8-Bits | 8-Bits | DLC * 8-Bits |
Descriptor 1
Bit 15 | Bit 14 | Bit 13 | Bit 12 | Bit 11 | Bit 10 | Bit 9 | Bit 8 |
---|---|---|---|---|---|---|---|
ID.11 | ID.10 | ID.9 | ID.8 | ID.7 | ID.6 | ID.5 | ID.3 |
Descriptor 2
Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
---|---|---|---|---|---|---|---|
ID.2 | ID.1 | ID.0 | RTR | DLC.3 | DLC.2 | DLC.1 | DLC.0 |
ID IdentifierRTR remote transmission requestDLC data length code
Aufbau Daten Telegramm A
Descr. 1 | Descr. 2 | Data 0 | Data 1 | Data 2 | Data 3 | Data 4 | Data 5 |
---|---|---|---|---|---|---|---|
0 | 6 | reserviert | Anzahl Empfangsfehler | Anzahl Sendefehler |
Aufbau Daten Telegramm B
Descr. 1 | Descr. 2 | Data 0 | Data 1 | Data 2 | Data 3 | Data 4 | Data 5 |
---|---|---|---|---|---|---|---|
0 | 6 | Netz ein | Netz aus | reserviert | reserviert |
Verbindungsaufbau
Ablauf der Einwahl mit Passwort
- Nach dem Connect sendet das Gateway den Text "Password: "
- Der Anrufer sendet sein Passwort, mit <CR> abgeschlossen
- Das Gateway sendet bei korrektem Login "Login accepted."
- Bei falschem Login sendet das Gateway "Login error!" und legt auf
- Steuerzeichen <CR> und <LF> sind nicht dargestellt, auch kann das Gateway am Anfang oder Ende einen beliebigen Text ausgeben
- Die Wartezeit beträgt 10 s. Erfolgt innerhalb dieser Zeit keine Eingabe, so sendet das Gateway "Login error (Timeout)!" und legt auf.
- Das Gateway wartet auf eine Aktion vom Anrufer
Ablauf der Einwahl ohne Passwort:
- Nach dem Connect kann das Gateway einen beliebigen Text senden und wartet dann auf eine Aktion vom Anrufer
Verbindungsaufbau und -überwachung:
- Der Anrufer beginnt die Datenübertragung, indem er ein CAN-Telegramm oder das Telegramm B sendet. Das Gateway weiß somit, von welchem CAN-Netzwerk der Anrufer CAN-Telegramme empfangen möchte. Somit wird auch der Heartbeat vom Gateway (Telegramm A) aktiviert.
- Sind keine CAN-Telegramme zu senden, so wird das Telegramm A oder B übertragen. Der Empfänger kann so erkennen, ob die Verbindung noch aktiv ist. Das Timeout beträgt 15 s.