SLCAN-FD Protokoll

Erweiterung des SLCAN Protokolls für CAN-FD

1. Vorwort

SLCAN (Serial Line CAN Protocol) erlaubt die Übertragung von CAN-Nachrichten über eine serielle Schnittstelle, RS232 oder USB, z. B. mit einem FTDI-Chip. Ursprünglich von der Firma Lawicel für „Classical CAN“ entwickelt, ist das sehr einfache ASCII-Zeichen-basierte Protokoll vollständig dokumentiert, was es bei Bastlern und in der Open-Source-Szene sehr beliebt macht. Eine Suche auf GitHub nach „slcan“ liefert 60 Ergebnisse, viele Hardware-Projekte, zum Großteil auf Arduino-Basis, und auch ein „socketcan“-basierter Kernel-Treiber für Linux ist dort zu finden. USBtin ist ein quelloffener USB-CAN-Adapter von Thomas Fischl, der nicht auf GitHub veröffentlicht ist, eine sehr bekannte SLCAN-Implementierung. Im Zuge der Erweiterung unseres Open Source CAN-Bus Analysetools – CANcool – um CAN-FD haben wir auch das SLCAN-Protokoll um CAN-FD erweitert. So können neben den Tiny-CANs auch Hobbyisten das Programm weiterhin mit ihrer eigenen Hardware nutzen. Die Nachteile des SLCAN-Protokolls sollen hier trotzdem nicht verschwiegen werden. Daten werden als ASCII-Hex-Zahlen übertragen, aus einem Datenbyte werden zwei Zeichen, die Menge der zu übertragenden Daten wird somit verdoppelt. Dem Protokoll fehlt jegliche Datenflusskontrolle. Empfangene CAN-Nachrichten werden einfach an den PC gesendet, auch wenn dieser gar nicht für den Empfang bereit ist. Der Versand von CAN-Nachrichten wird zwar bestätigt, dies geschieht aber für jede Nachricht einzeln. Bei USB bedeutet das bedingt durch das Polling eine Pause von größer 1 ms zwischen jeder Nachricht. Zu guter Letzt sind viele Funktionen in dem Protokoll nicht implementiert, z. B. CAN-Fehlernachrichten. Für den professionellen Einsatz ist SLCAN daher leider nicht geeignet. Bei unseren Tiny-CAN-Modulen greifen wir auch auf die höchst zuverlässigen USB-Chips von FTDI zurück, verwenden aber ein sehr aufwendiges Binärprotokoll mit Datensicherungsschicht und Datenflusskontrolle. Für Windows gibt es eine andere Möglichkeit, CAN-Hardware und -Software auf der Applikationsebene kompatibel zu machen. Die Norm J2534 von SAE definiert eine einheitliche Treiber-API für PC-Diagnoseadapter, auch PassThru Device genannt. CANcool unterstützt übrigens auch die PassThru API und kann somit mit fast allen am Markt erhältlichen CAN-Bus-Adaptern verwendet werden.

2. Protokollbeschreibung

Wie bereits erwähnt, benutzt das Protokoll nur ASCII-Zeichen, Zahlen und Daten werden im Hex-Format übertragen. Ein Kommando beginnt mit einem Zeichen, das das Kommando identifiziert, gefolgt von Parametern und einem abschließenden CR. Die Hardware muss in der Lage sein, mindestens zwei Befehlssequenzen zwischenzupuffern, z. B. wird der Status parallel abgefragt, wenn eine gesendete Nachricht noch nicht quittiert worden ist.

2.1. Befehlstabelle

Die nachfolgende Tabelle beschreibt alle Kommandos, die der PC zum CAN-Adapter sendet, mit den entsprechenden positiven Acknowledgements. Im Fehlerfall gibt jedes Kommando [BELL] ohne Parameter zurück.

CMD Syntax ACK Beschreibung
KONFIG
'S' Sn[CR] [CR] CAN nominal Bitrate, Werte für n:
  • '0' = 10 kBit/s
  • '1' = 20 kBit/s
  • '2' = 50 kBit/s
  • '3' = 100 kBit/s
  • '4' = 125 kBit/s
  • '5' = 250 kBit/s
  • '6' = 500 kBit/s
  • '7' = 800 kBit/s
  • '8' = 1 MBit/s
  • '9' = 33,3 kBit/s*
  • 'A' = 40 kBit/s*
  • 'B' = 62,5 kBit/s*
  • 'C' = 75 kBit/s*
  • 'D' = 93,3 kBit/s*
  • 'E' = 200 kBit/s*
  • 'F' = 205 kBit/s*
* Optional, wird nicht von jeder Hardware unterstützt.
Bei nicht unterstützten Geschwindigkeiten gibt das Kommando [BELL] zurück.
 Power Up / Default: '4' = 125 kBit/s
's' sinnnnnnnn[CR] [CR] Konfiguration NBTR (BTR) Register
  • 'i' = CAN Clock Index
  • 'nnnnnnnn' = NBTR Wert
'c' cinnnnnnnndddddddd[CR] [CR] Konfiguration NBTR, DBTR Register
  • 'i' = CAN Clock Index
  • 'nnnnnnnn' = NBTR Wert
  • 'dddddddd' = DBTR Wert
'f' fn[CR] [CR] CAN-FD Data Bitrate, Werte für n:
  • '0' = 125 kBit/s
  • '1' = 250 kBit/s
  • '2' = 500 kBit/s
  • '3' = 1 MBit/s
  • '4' = 1,5 MBit/s
  • '5' = 2 MBit/s
  • '6' = 3 MBit/s
  • '7' = 4 MBit/s
  • '8' = 5 MBit/s
  • '9' = 6 MBit/s
  • 'A' = 7 MBit/s
  • 'B' = 8 MBit/s
  • 'C' = 9 MBit/s
  • 'D' = 10 MBit/s
  • 'E' = 11 MBit/s
  • 'F' = 12 MBit/s
Nicht alle Geschwindigkeiten werden von jeder Hardware unterstützt. Bei nicht unterstützten Geschwindigkeiten gibt das Kommando [BELL] zurück.
Power Up / Default: '0' = 125 kBit/s
'Z' Zn[CR] [CR] Set Timestamp Mode für empfangene CAN-Nachrichten, Werte für n:
  • '0'= Timestamp aus
  • '1'= 16 Bit Timestamp 0x0000 – 0xEA5F (0 – 60 Sek.)
  • '2' = 16 Bit Timestamp 0x0000 – 0xFFFF
Power Up / Default: '0' = Timestamp aus
'X' Xn[CR] [CR] Auto Poll Mode für empfangene Nachrichten konfigurieren, Werte für n:
  • '0' = Manuell empfangene Nachrichten müssen mit dem Kommando 'P' oder 'A' aus dem Empfangs-FIFO gelesen werden.
  • '1' = Auto Poll, empfangene Nachrichten werden automatisch zum PC gesendet.
Power Up / Default: '1' = Auto Poll
ÖFFNEN / SCHLIESSEN
'O' O[CR] [CR] CAN-Bus öffnen
'L' L[CR] [CR] CAN-Bus im "Listen Only Mode" öffnen
'C' C[CR] [CR] CAN-Bus schließen
SENDEN
't' tiiildd...[CR] z[CR] Standard (11 Bit) CAN-Nachricht senden
  • 'iii' = CAN ID
  • 'l' = Datenlänge 0 – 8 Byte
  • 'dd'..'dd' = Daten
'T' Tiiiiiiiildd...[CR] Z[CR] Extended (29 Bit) CAN-Nachricht senden
'r' riiil[CR] z[CR] Standard (11 Bit) CAN-RTR-Nachricht senden
'R' Riiiiiiiil[CR] Z[CR] Extended (29 Bit) CAN-RTR-Nachricht senden
'd' diiildd...[CR] z[CR] Standard (11 Bit) CAN-FD-Nachricht senden, Interpretation von l, Datenlänge:
  • '0' – '8' = 0 – 8 Byte
  • '9' = 12 Byte
  • 'A' = 16 Byte
  • 'B' = 20 Byte
  • 'C' = 24 Byte
  • 'D' = 32 Byte
  • 'E' = 48 Byte
  • 'F' = 64 Byte
'D' Diiiiiiiildd...[CR] Z[CR] Extended (29 Bit) CAN-FD-Nachricht senden
'b' biiildd...[CR] z[CR] Standard (11 Bit) CAN-FD-Nachricht senden, BRS aktiv
'B' Biiiiiiiildd...[CR] Z[CR] Extended (29 Bit) CAN-FD-Nachricht senden, BRS aktiv
EMPFANGEN
'P' P[CR] [CR] Eine Nachricht aus dem Empfangs-FIFO lesen (polling)
'A' A[CR] [CR] Alle Nachrichten aus dem Empfangs-FIFO lesen (polling)
INFO
'F' F[CR] Fss[CR] Statusflags lesen
  • Bit
  • 0 = CAN-Empfangs-FIFO voll
  • 1 = CAN-Sende-FIFO voll
  • 2 = CAN-Bus im Zustand "Error warning"
  • 3 = Empfangs-FIFO-Überlauf
  • 4 = CAN-Sende-FIFO nicht leer (pending data)
  • 5 = CAN-Bus im Zustand "Error Passive"
  • 6 = CAN-Bus "Bus Off" dedektiert*
  • 7 = CAN-Bus "Error" dedektiert*
* Wird bei Abfrage des Status gelöscht
'V' V[CR] Vhhff[CR] Hardware- und Firmware-Version abfragen
  • hh = Hardware Version (h.h = major.minor)
  • ff = Firmware Version (f.f = major.minor)
'v' v[CR] v...[CR] Hardware-Infoabfragen:
  • 'v';;[CR]
'N' N[CR] N...[CR] Hardware-Seriennummer abfragen. Die Seriennummer wird als ASCII-String ausgegeben, maximale Länge 12 Zeichen.
'i' i[CR] i...[CR] CAN Controller-Info abfragen:
  • 'i';;;
    • FD/C:
      • FD = CAN-FD-Hardware
      • C = Classical CAN
    • Controller:
      • SAMC = Microchip SAMC Serie
    • Clock 0 .. n in MHz
Beispiel: FD;SAMC;80;24
FIRMWARESPEZIFISCH / RESERVIERT
'!' ![CR]
'!' Startet ein Kommando mit mehr als einem Zeichen, herstellerspezifisch, wird z. B. für Firmware-Updates benutzt.

Die folgenden Kommandos sind neu und nicht im Original-Lawicel-Protokoll enthalten:
'd', 'D', 'b', 'B', 'i', 'c', 'f', 'v', '!'.
 Die folgenden Kommandos wurden gegenüber dem Lawicel-Protokoll geändert:
'S', 's', 'F', N', 'Z'.
 Die Kommandos 'd', 'D', 'b', 'B', 'c', 'f' sind nur bei CAN-FD-Adaptern vorhanden. Die Kommandos 'P', 'A' und 'X' sind optional und stammen vom Lawicel RS232-Adapter. Der Lawicel USB-CAN-Adapter stellt diese Kommandos nicht mehr zur Verfügung.

Nicht mehr unterstützte, veraltete Kommandos:
CMD Syntax ACK Beschreibung
'W' Wn[CR] [CR] Filtermode konfigurieren
'M' Mxxxxxxxx[CR] [CR] Acceptance Code Register (SJA1000) setzen
'm' mxxxxxxxx[CR] [CR] Acceptance Mask Register (SJA1000) setzen
'U' Un[CR] [CR] Baudrate für die serielle Schnittstelle konfigurieren
'Q' Qn[CR] [CR] Auto Startup konfigurieren

[CR] = ASCII-Code Dezimal 13, Hex 0D
[BELL] = ASCII-Code Dezimal 7, Hex 07
Die Übertragungsgeschwindigkeit auf der seriellen Schnittstelle ist fest auf 57600 Baud oder 3M Baud konfiguriert. Default ist 3M Baud. Die Konfiguration der Übertragungsgeschwindigkeit ist herstellerspezifisch.

2.2 CAN-Nachrichtenempfang

Empfangene CAN-Nachrichten werden ohne Aufforderung nach Öffnen mit dem Kommando 'O' oder 'L' zum PC gesendet, der PC bestätigt den Empfang der Nachrichten nicht. Ist das 'X'-Kommando vorhanden, muss „Auto Poll“ als Voreinstellung aktiviert sein.

Empfangene CAN-Nachrichten:

Timestamp deaktiviert Timestamp aktiviert Beschreibung
tiiildd...[CR] tiiildd...tttt[CR] Standard (11 Bit) CAN-Nachricht
  • 'iii' = CAN ID
  • 'l' = Datenlänge 0 – 8 Byte
  • 'd' = Daten
  • 'tttt' = 16-Bit-Timestamp
Tiiiiiiiildd...[CR] Tiiiiiiiildd...tttt[CR] Extended (29 Bit) CAN-Nachricht
riiil[CR] riiiltttt[CR] Standard (11 Bit) CAN-RTR-Nachricht
Riiiiiiiil[CR] Riiiiiiiiltttt[CR] Extended (29 Bit) CAN-RTR-Nachricht
diiildd...[CR] diiildd...tttt[CR] Standard (11 Bit) CAN-FD-Nachricht
Interpretation von l, Datenlänge:
  • '0' – '8' = 0 – 8 Byte
  • '9' = 12 Byte
  • 'A' = 16 Byte
  • 'B' = 20 Byte
  • 'C' = 24 Byte
  • 'D' = 32 Byte
  • 'E' = 48 Byte
  • 'F' = 64 Byte
Diiiiiiiildd...[CR] Diiiiiiiildd...tttt[CR] Extended (29 Bit) CAN-FD-Nachricht
biiildd...[CR] biiildd...tttt[CR] Standard (11 Bit) CAN-FD-Nachricht, BRS set
Biiiiiiiildd...[CR] Biiiiiiiildd...tttt[CR] Extended (29 Bit) CAN-FD-Nachricht, BRS set

Ist der Timestamp aktiv, wird dieser als 16-Bit-Hex-Zahl jeder Nachricht angehängt. Das Protokollformat für empfangene CAN-Nachrichten entspricht ansonsten exakt dem für gesendete CAN-Nachrichten.

3. Test

Die ersten Gehversuche mit einer Hardware sollte man mit einen Terminalprogramm machen. Ich empfehle dafür das Programm Hterm, es ist kostenlos und erfordert keine Installation auf dem PC. Siehe Abschnitt „4. Links/Quellen“ zum Download.

Rot markierte Einstellungen beachten. In unserem Beispiel werden folgende Kommandos an ein Tiny-CAN I-XL mit SLCAN-Firmware gesendet:

V[CR]Hardware- und Firmware-Version abfragen
i[CR]CAN-Controller-Info abfragen
v[CR]Hardware-Info abfragen
N[CR]Hardware-Seriennummer abfragen
S5[CR]CAN-Bitrate auf 250kBit/s einstellen
O[CR]CAN-Bus-Interface öffnen
t1230[CR]CAN-Nachricht (Std.-Frame-Format, Id: 0x123, DLC: 0) senden
T123456780[CR]CAN-Nachricht (Ext.-Frame-Format, Id: 0x12345678, DLC: 0) senden

Der Screenshot zeigt unter „Received Data“ die Antworten; die Kommandos „S5[CR]“ und „O[CR]“ werden nur mit [CR] bestätigt. Die beiden gesendeten CAN-Nachrichten werden mit „z[CR]“ und „Z[CR]“ bestätigt. In der letzten Zeile empfängt die Hardware eine CAN-Nachricht: Std.-Frame-Format, Id: 0x456, DLC: 2, Daten: 0x55, 0xAA.

4. Links/Quellen

CANcool
https://github.com/MHS-Elektronik/CANcool
Open Source CAN-Bus Analyse- und Simulationssoftware mit CAN-FD-Unterstützung.

Download der SL-Firmware für die Tiny-CAN-Module
https://www.mhs-elektronik.de/index.php?module=download&action=file&id=39
Voraussetzung ist die Installation des Tiny-CAN-Softwarepaketes, es enthält den FTDI-Systemtreiber und die DLLs zum Flashen der Tiny-CAN-Module.
https://www.mhs-elektronik.de/index.php?module=download
Die Original Tiny-CAN-Firmware wird mit dem Programm Tiny-CAN Check zurückgeflasht. Das Softwarepaket enthält übrigens auch CANcool.

Terminalprogramm „Hterm“ von Tobias Hammer
https://www.der-hammer.info/pages/terminal.html

SLCAN auf GitHub
https://github.com/search?q=slcan

USBtin – USB-CAN-Interface von Thomas Fischl
https://www.fischl.de/usbtin

Das ursprüngliche SLCAN-Protokoll stammt von der Firma Lawicel SE aus Schweden:
http://www.canusb.com
Die Originaldokumentation von Lawicel ist hier zu finden:
SLCAN für USB-Adapter: http://www.can232.com/docs/canusb_manual.pdf
SLCAN für RS232-Adapter: http://www.can232.com/docs/can232_v3.pdf

5. Linux

SLCAN-FD-Implementierung für SocketCAN von Jacob Schloss/Suburban Embedded
https://github.com/suburbanembedded/linux/blob/slcan_canfd/drivers/net/can/slcan.c