Forum: Fahrzeugelektronik SLCAN Protokoll für CAN-FD erweitern


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Klaus D. (Firma: MHS-Elektronik GmbH & Co. KG) (mhs-elektronik)


Bewertung
1 lesenswert
nicht lesenswert
SLCAN Protokoll für CAN-FD erweitern

Ich möchte das SLCAN Protokoll um CAN-FD erweitern. Der Hintergrund ist 
das CANcool
auch weiterhin für Drittanbietern offen bleibt und CAN-FD Hardware 
unterstützt wird.
https://github.com/MHS-Elektronik/CANcool

Es gibt da schon etwas von Suburban Embedded, nur wurde das leider nicht 
ganz bis zu ende gedacht:
https://github.com/suburbanembedded/hadoucan-fw
Konfiguration sehr aufwendig, der verwendete Controller Type kann nicht 
erkannt werden, BRS fest konfiguriert

Die 2. Lösung die ich gefunden habe überzeugt auch nicht:
https://github.com/feilongfl/slcanfd

Hier die Protokoll Beschreibung von dem:
/*
 * The SLCAN ASCII representation of these different frame types is:
 * <type> <id> <dlc> <data>*
 *
 * Extended frames (29 bit) are defined by capital characters in the type.
 * RTR frames are defined as 'r' types - normal frames have 't' type.
 * CANFD frame are use 'x'/'X' after frame type, 'x' will enable BRS,
 * 'X' will disable BRS.
 *
 * t => 11 bit data CAN frame
 * r => 11 bit RTR CAN frame
 * T => 29 bit data CAN frame
 * R => 29 bit RTR CAN frame
 * tx => 11 bit data CAN-FD frame(with BRS)
 * Tx => 29 bit data CAN-FD frame(with BRS)
 * tX => 11 bit data CAN-FD frame(without BRS)
 * TX => 29 bit data CAN-FD frame(without BRS)
 *
 * The <id> is 3 (standard) or 8 (extended) bytes in ASCII Hex (base64).
 * The <dlc> is a one byte Hex number ('0' - 'f')
 * The <data> section has at much ASCII Hex bytes as defined by the <dlc>
 * No RTR in CAN-FD frame.
*/

Probleme hier: 2 Byte Kommandos, Konfiguration fehlt, der verwendete 
Controller Type kann nicht erkannt werden.


Mein Vorschlag für die Erweiterung des SLCAN Protokolls:
/*
CMD | Syntax            | Beschreibung
----+-------------------+-------------------------
'd' | diiildd...        | Standard (11bit) CAN-Fd Nachricht
'D' | Diiiiiiiildd...   | Extended (29bit) CAN-Fd Nachricht
'b' | biiildd...        | Standard (11bit) CAN-Fd Nachricht, BRS set
'B' | Biiiiiiiildd...   | Extended (29bit) CAN-Fd Nachricht, BRS set
'i' | i                 | CAN Controller Info Abfragen:
    |                   |    <FD/C>;<Controller Family>;<Clock in MHz>
    |                   |     FD/C :
    |                   |         FD = CAN-FD Hardware
    |                   |         C = Classical CAN
    |                   |     Controller Family: 
    |                   |         SAMC = Microchip SAMC Serie 
    |                   |     Clock in MHz
    |                   | Beispiel: FD;SAMC;80
'c' | cnnnnnnnndddddddd | Configuration NBTR, DBTR Register 
    |                   |   nnnnnnnn = NBTR Wert
    |                   |   dddddddd = DBTR Wert
'f' | fn                | CAN-FD DataBitrate, Werte für n: 
    |                   |    0 = 250 kBit/s
    |                   |    1 = 500 kBit/s
    |                   |    2 = 1 MBit/s
    |                   |    3 = 1,5 MBit/s
    |                   |    4 = 2 MBit/s
    |                   |    5 = 3 MBit/s
    |                   |    6 = 4 MBit/s
    |                   |    7 = 5 MBit/s
    |                   |    8 = 6 MBit/s 
    |                   |    9 = 7 MBit/s
    |                   |    A = 8 MBit/s
    |                   |    B = 9 MBit/s
    |                   |    C = 10 MBit/s
*/

Grüße
Klaus

von Dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und was ist die Frage?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Interessant, ich habe da auch gerade was in der Pipeline:
https://github.com/RudolphRiedel/USB_CAN-FD

von Klaus D. (Firma: MHS-Elektronik GmbH & Co. KG) (mhs-elektronik)


Bewertung
0 lesenswert
nicht lesenswert
Dirk schrieb:
> Und was ist die Frage?

Eine direkte Frage gibt es da nicht, ihr könnt Vorschläge, Anregungen, 
usw. einbringen.
Ich mache ja die Hardware nicht, meine Tiny-CANs verwenden ein ganz 
eigenes Binär-Protokoll.

von Klaus D. (Firma: MHS-Elektronik GmbH & Co. KG) (mhs-elektronik)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Rudolph

> https://github.com/RudolphRiedel/USB_CAN-FD

Sieht interessant aus, wenn ich auch die Verwendung von FreeRTOS für so 
eine kleine Anwendung für etwas übertrieben halte.
Ich habe die Entwicklung von meinen neuen Tiny-CAN FD im Prinzip schon 
abgeschlossen, nur Doku fehlt noch so einiges :-)

Ich verwende übrigens auch einen Atmel Controller, den SAMC, anbei der 
Schaltplan und ein Bild der Hardware.

Wie ist das bei dem WinUSB mit der Performance und Stabilität, habt ihr 
da schon Erfahrungen ?

Bei FTDI lässt die Stabilität kaum mehr wünsche offen! Das läuft Wochen 
(vermutlich sogar Monate) lang ohne einen einzigen Fehler. Bei der 
Performance gibt es gerade bei CAN-FD noch Luft :-)

Grüße
Klaus

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Klaus D. schrieb:
> Sieht interessant aus, wenn ich auch die Verwendung von FreeRTOS für so
> eine kleine Anwendung für etwas übertrieben halte.

Ich auch, das Problem das zu dem FreeRTOS geführt hat war der USB-Stack 
und mit Tiny-USB war dann auch das FreeRTOS im Boot.

> Ich verwende übrigens auch einen Atmel Controller, den SAMC, anbei der
> Schaltplan und ein Bild der Hardware.

Die benutze ich auch gerne, für übliche 500k/2MBit sind die auch super.
Nur 4 MBit machen mit maximal 12 Time-Quanten schon nicht mehr so viel 
Sinn.

> Wie ist das bei dem WinUSB mit der Performance und Stabilität, habt ihr
> da schon Erfahrungen ?

Noch nicht genug und ich habe mit der eigentlichen Software in dem 
Projekt jetzt gar nicht mal so viel zu tun.
Die Software die ich dafür gemacht habe zielt mehr so darauf ab die 
Hardware zu testen und benutzt den USB nicht.

> Bei FTDI lässt die Stabilität kaum mehr wünsche offen! Das läuft Wochen
> (vermutlich sogar Monate) lang ohne einen einzigen Fehler. Bei der
> Performance gibt es gerade bei CAN-FD noch Luft :-)

Die FT230 benutze ich auch gerne, maximal 3 Mbaud wäre nur etwas dünn, 
da wir ja zwei CAN-FD Kanäle haben.
Ob die 12 MBit von dem FS-USB überhaupt reichen muss sich noch zeigen.
Mit HS-USB und CAN-FD gibt es aber nur die ATSAMx70 ab 100 pins 
aufwärts.

Daran dafür das SLCAN Protokoll zu benutzen habe ich aber auch schon 
gedacht.

: Bearbeitet durch User
von Klaus D. (Firma: MHS-Elektronik GmbH & Co. KG) (mhs-elektronik)


Bewertung
0 lesenswert
nicht lesenswert
> Die benutze ich auch gerne, für übliche 500k/2MBit sind die auch super.
> Nur 4 MBit machen mit maximal 12 Time-Quanten schon nicht mehr so viel
> Sinn.
Ich arbeite normal mit den Cypress MB9BFxxx (inzwischen Infineon, vorher 
Fujitsu), Cortex M3/M4 die mit 5V laufen, gerade wenn man mit CAN 
arbeitet ist das halt schon super. Nur leider gibt es da keine CAN-FD 
Derivate, beim suchen nach kleinen CAN-FD Controllern habe ich außer dem 
SAMC nichts gefunden. Das Tiny-CAN FD ist mein 1. Design mit den Atmel 
Controllern, in neueren Designs werde ich aber die Cortex M4 von Atmel 
verwenden.


>
>> Wie ist das bei dem WinUSB mit der Performance und Stabilität, habt ihr
>> da schon Erfahrungen ?
>
> Noch nicht genug und ich habe mit der eigentlichen Software in dem
> Projekt jetzt gar nicht mal so viel zu tun.
> Die Software die ich dafür gemacht habe zielt mehr so darauf ab die
> Hardware zu testen und benutzt den USB nicht.
>
Ist es ein Windows oder ein Firmware Problem, habt ihr das raus bekommen 
?

>
> Die FT230 benutze ich auch gerne, maximal 3 Mbaud wäre nur etwas dünn,
> da wir ja zwei CAN-FD Kanäle haben.
> Ob die 12 MBit von dem FS-USB überhaupt reichen muss sich noch zeigen.
> Mit HS-USB und CAN-FD gibt es aber nur die ATSAMx70 ab 100 pins
> aufwärts.
Hier bin ich auch noch auf der Suche nach einer Lösung, FTDI bietet
ja auch HS-USB Bausteine an, aber die Serielle Schnittstelle wird halt
zum Flaschenhalls.
Bei mehr als 6MBit/s habe ich es nicht mehr stabil bekommen :-(
Ich denke jetzt über Ethernet als Schnittstelle nach...

>
> Daran dafür das SLCAN Protokoll zu benutzen habe ich aber auch schon
> gedacht.
Hat sich halt als ein gewisser Standard entwickelt, gerade unter Linux
wird das viel benutzt. Ich bin eigentlich kein Freund davon.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Klaus D. schrieb:
> Ich arbeite normal mit den Cypress MB9BFxxx (inzwischen Infineon, vorher
> Fujitsu), Cortex M3/M4 die mit 5V laufen, gerade wenn man mit CAN
> arbeitet ist das halt schon super.

Als ich mit den ATSAMC anfing fand  ich die 5V noch wichtiger.
Aber stimmt schon, nur ein Regler ist schon mal einfacher.

> Nur leider gibt es da keine CAN-FD
> Derivate, beim suchen nach kleinen CAN-FD Controllern habe ich außer dem
> SAMC nichts gefunden.

Vor allem unter einfach so zu bekommen, Alternativ in Automotive-Version 
und mit nicht beschnittenen CAN-FD fällt mir nichts ein.
In nicht zu bekommen, nicht Automotive, stark eingeschränkt und/oder 
erst ab 64 Pins aufwärts gibt es noch ein paar Kandidaten. :-)

> Das Tiny-CAN FD ist mein 1. Design mit den Atmel
> Controllern, in neueren Designs werde ich aber die Cortex M4 von Atmel
> verwenden.

Der CAN-Controller ist schon mal komplett identisch, und auch sonst 
merkt man an allen Ecken das die aus der gleichen Generation sind.
So im Gegensatz zu den ATSAMx70.
Leider gibt es kein 48-Pin TQFP von dem ATSAME51, nur QFN.

> Ist es ein Windows oder ein Firmware Problem, habt ihr das raus bekommen
> ?

Ist was ein Windows oder ein Firmware Problem?

> Ich denke jetzt über Ethernet als Schnittstelle nach...

An Ethernet haben wir auch schon gedacht, es gibt ja auch die ATSAME54.
Nur wird das auf der Software-Seite nicht leichter, statt USB-Stack 
braucht man eben einen Ethernet-Stack.
Und Ethernet ist für Gadgets direkt am Rechner eher hinderlich, so ohne 
Versorgung.
Selbst die einfachste Variante mit zusätzlichem Versorgungs-Anschluss 
ist schwer lästig gegenüber USB.

Es gibt ja USB/Ethernet Bridges, nur sind die eher anders gedacht.
Statt USB/RMII<->RMII/MAC/Controller sieht es eher so aus:
USB/MAC/Phy<->Phy<->MAC/Controller
Oder gar USB/MAC<->PHY<->PHY<->MAC/Controller

Zumindest habe ich spontan keinen Chip gefunden der dafür gedacht ist 
einen Controller der nur Ethernet hat an USB zu klemmen.

>> Daran dafür das SLCAN Protokoll zu benutzen habe ich aber auch schon
>> gedacht.
> Hat sich halt als ein gewisser Standard entwickelt, gerade unter Linux
> wird das viel benutzt. Ich bin eigentlich kein Freund davon.

Ja, die Software dazu für den Rechner ist ein leidiges Thema.
Wir haben eine proprietäre Software an die wir uns anklemmen wollen, das 
nützt nur niemandem sonst was.

von Jacob Schloss (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hi,

Jacob from Suburban Embedded - Sorry my German is very bad so I'll post 
in English - I'm flexible to changes on the slcan protocol, I'd like to 
be compatible with whatever ends up being up-streamed in the linux 
kernel. I've started a patch to slcan here: 
https://github.com/suburbanembedded/linux/blob/slcan_canfd/drivers/net/can/slcan.c, 
but has not been tested or worked on recently.

Konfiguration sehr aufwendig - Very true. I'm not sure how to balance 
allowing custom time quanta tables with simple configuration. Probably 
adding more shorthand commands to change single config parameters at a 
time would help.

BRS fest konfiguriert - I think this means that BRS can't be enabled on 
a packet by packet basis - it actually can be turned on and off freely 
with a b/B command. The static BRS configuration just is whether BRS is 
enabled at all, eg to allow or prohibit BRS frames to be received.
'f' | fn                | CAN-FD DataBitrate, Werte für n: 
    |                   |    0 = 250 kBit/s
    |                   |    1 = 500 kBit/s
    |                   |    2 = 1 MBit/s
    |                   |    3 = 1,5 MBit/s
    |                   |    4 = 2 MBit/s
    |                   |    5 = 3 MBit/s
    |                   |    6 = 4 MBit/s
    |                   |    7 = 5 MBit/s
    |                   |    8 = 6 MBit/s 
    |                   |    9 = 7 MBit/s
    |                   |    A = 8 MBit/s
    |                   |    B = 9 MBit/s
    |                   |    C = 10 MBit/s

I like this 'f' command idea. My device supports up to 12Mbit/s BRS, 
maybe D = 12Mbps?

>> Daran dafür das SLCAN Protokoll zu benutzen habe ich aber auch schon
>> gedacht.
> Hat sich halt als ein gewisser Standard entwickelt, gerade unter Linux
> wird das viel benutzt. Ich bin eigentlich kein Freund davon.

I have been thinking about supporting multiple protocols. slcan for 
backwards compatibility and maybe a new binary protocol with new 
features.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.