Hallo Kollegen
ich bin dabei, ein paar Sensor-Nodes zu bauen, welche ich gerne über CAN
miteinander verbinden möchte. Die Sensoren haben ADCs drauf und sollen
an verschiedenen Punkten ein paar Werte messen und diese dann über den
Bus an den zentralen Node senden, der die Daten speichern soll. Soweit
alles klar.
Nur habe ich jetzt in meiner Berechnung herausgefunden, dass ich eine
Samplingrate von ca. 1 kHz brauche. D.h. ich muss im Takt von 1 ms die
Messwerte (4 Bytes) übertragen. Mir erscheint das sehr sportlich, da CAN
maximal 1 MBit/s hat. Was meint ihr?
Ich habe maximal drei Nodes, also gäbe es 3 x 4 Bytes / ms zu
übertragen. Rein theoretisch sollte es reichen, und mein CAN-Kabel ist
geschirmt und alles, sodass eigentlich keine Übertragungsfehlet
auftreten sollten.
Was sagt ihr dazu, ist das realistisch? Ich kommt auf ca. 60% Buslast.
Erscheint mir hoch. Andererseits sieht man in der Industriellen
Automation auch immer öfter, dass ganze Regelkreise über CAN geschlossen
werden, d.h. so langsam ist der Bus auch wieder nicht. Im moment kann
ich es ganz schlecht einschätzen und wäre mal auf ein paar
Erfahrungswerte von euch gespannt.
Wie wäre es, wenn man CAN mit 2 MBit/s betreibt? mein STM32F407 erlaubt
das rein Hardwaremässig jedenfalls, denn wenn ich die Register
entsprechend setze dann läuft das.
(Einen Test mit maximaler Buslast kann ich allerdings im Moment noch
nicht machen, weil ich nur einen Node habe.)
Gruss
Passt doch locker.
bei 4 Datenbytes hast du 78Bits/frame (ohne stuffbits), also 78µs bei
1MBit. Also keine 25% bei regulärem Betrieb.
In deinem Fall denk ich trotzdem ausnahmsweise, das RS485 die bessere
Wahl wäre. Die Funktionalität von CAN brauchst du bei deinem System
eigentlich nicht, die Botschaften selbst sind nur halb so lang. Wenn
noch mehr dazukommt, kannst du bis 12MBit hochgehen
Moin moin
die Länge des Bus ist definitiv kleiner als 1m. So einige 10 cm. Sagen
wir mal, 40cm. Nach meinen Berechnungen sollte dann 1Mbit locker drin
liegen.
CAN habe ich deshalb gewählt, weil CRC usw. schon in der Hardware
erledigt wird. Von RS485 bin ich eigentlich nicht so ein Fan, obwohl,
ich könnte ja an eine Variantenbestückung meiner LP denken (ich werde
davon ein paar Leiterplatten anfertigen lassen) um beides testen zu
können.
Bei dieser Buslänge brauchst Du kein CRC. Nimm UARTs, hänge daran
CAN-Transceiver (ja, das geht problemlos), und höre beim Senden mit.
Solange Du jedes Byte, das Du sendest, auch wieder empfängst, ist alles
in Ordnung. Der Einsatz von CAN-Transceivern anstelle von
RS485-Transceivern erspart Dir das Ansteuern des DE-Einganges (Driver
Enable) vom Transceiver.
fchk
Du kannst da sogar ein triviales Protokoll sprechen. Alle Sensoren
zählen die empfangenen Bytes mit, und wissen somit, wann sie senden
dürfen. Der "Master" schickt ein Zeichen zum Start (z.Bsp. Break)
Dadurch vereinfacht sich das zu einer ISR die folgendes macht.
USART meldet Break -> x=0
USART empfängt Byte ->
x=Startwert zum Senden?
ja=>1. Datenbyte senden
nein=> Byte verwerfen
x:=x+1
USART hat Byte verschickt
noch ein Datenbyte zum schicken da?
ja=>Datenbyte schicken
Somit schickt der Master ein Break und bekommt dann, fast mit maximaler
Geschwindigkeit, nacheinander alle Datenbytes von allen Sensoren.
Ach ja, und mit einem Dioden-Und (oder einem Dioden-Oder) kannst Du das
sogar quasi als "Open-Collector" betreiben. Für Deine Kabellängen sollte
das reichen, da ginge sogar CAN. :)
Tim schrieb:> Hmm aber was spricht denn gegen CAN?
Naja, für Deine Anwendung ginge auch CAN, ja sogar I2C.
Aber schau Dir mal CAN, besonders die elektrischen Spezifikationen an,
und probiere vielleicht auch mal real existierende Komponenten aus.
Tim schrieb:> So einige 10 cm. Sagen wir mal, 40cm. Nach meinen Berechnungen sollte> dann 1Mbit locker drin liegen.
So lang etwa, wie ein PATA HD Kabel. Und wurden da nicht 16MHz mit
einfachen Bustreibern gemacht?
MfG Klaus
Christian Berger schrieb:> Du kannst da sogar ein triviales Protokoll sprechen. Alle Sensoren> zählen die empfangenen Bytes mit, und wissen somit, wann sie senden> dürfen. Der "Master" schickt ein Zeichen zum Start (z.Bsp. Break)>> Dadurch vereinfacht sich das zu einer ISR die folgendes macht.> USART meldet Break -> x=0> USART empfängt Byte ->> x=Startwert zum Senden?> ja=>1. Datenbyte senden> nein=> Byte verwerfen> x:=x+1> USART hat Byte verschickt> noch ein Datenbyte zum schicken da?> ja=>Datenbyte schicken
Hört sich bisschen wie LIN an ;-)
X2 schrieb:> Christian Berger schrieb:>> Du kannst da sogar ein triviales Protokoll sprechen. Alle Sensoren>> zählen die empfangenen Bytes mit, und wissen somit, wann sie senden>> dürfen. Der "Master" schickt ein Zeichen zum Start (z.Bsp. Break)>>>> Dadurch vereinfacht sich das zu einer ISR die folgendes macht.>> USART meldet Break -> x=0>> USART empfängt Byte ->>> x=Startwert zum Senden?>> ja=>1. Datenbyte senden>> nein=> Byte verwerfen>> x:=x+1>> USART hat Byte verschickt>> noch ein Datenbyte zum schicken da?>> ja=>Datenbyte schicken>> Hört sich bisschen wie LIN an ;-)
..hatte ich am Anfang auch gedacht. Ein paar Sensorwerte einsammeln ist
doch Ideal für einen LIN Bus.
Wozu einen teuren CAN-Bus verwenden der gar nicht benötigt wird? Bei der
Leitungslänge kannst du auch einfach eine stinknormale UART nehmen und
zur Not hängst du ein CRC Byte mit rein ;-)
