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:
1
/*
2
* The SLCAN ASCII representation of these different frame types is:
3
* <type> <id> <dlc> <data>*
4
*
5
* Extended frames (29 bit) are defined by capital characters in the type.
6
* RTR frames are defined as 'r' types - normal frames have 't' type.
7
* CANFD frame are use 'x'/'X' after frame type, 'x' will enable BRS,
8
* 'X' will disable BRS.
9
*
10
* t => 11 bit data CAN frame
11
* r => 11 bit RTR CAN frame
12
* T => 29 bit data CAN frame
13
* R => 29 bit RTR CAN frame
14
* tx => 11 bit data CAN-FD frame(with BRS)
15
* Tx => 29 bit data CAN-FD frame(with BRS)
16
* tX => 11 bit data CAN-FD frame(without BRS)
17
* TX => 29 bit data CAN-FD frame(without BRS)
18
*
19
* The <id> is 3 (standard) or 8 (extended) bytes in ASCII Hex (base64).
20
* The <dlc> is a one byte Hex number ('0' - 'f')
21
* The <data> section has at much ASCII Hex bytes as defined by the <dlc>
22
* No RTR in CAN-FD frame.
23
*/
Probleme hier: 2 Byte Kommandos, Konfiguration fehlt, der verwendete
Controller Type kann nicht erkannt werden.
Mein Vorschlag für die Erweiterung des SLCAN Protokolls:
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.
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
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.
> 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.
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.
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.
1
'f' | fn | CAN-FD DataBitrate, Werte für n:
2
| | 0 = 250 kBit/s
3
| | 1 = 500 kBit/s
4
| | 2 = 1 MBit/s
5
| | 3 = 1,5 MBit/s
6
| | 4 = 2 MBit/s
7
| | 5 = 3 MBit/s
8
| | 6 = 4 MBit/s
9
| | 7 = 5 MBit/s
10
| | 8 = 6 MBit/s
11
| | 9 = 7 MBit/s
12
| | A = 8 MBit/s
13
| | B = 9 MBit/s
14
| | 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.
Thread beobachten
Seitenaufteilung abschalten