mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS485 Kollision erkennen/vermeiden mit CAN-Treibern


Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich plane gerade, mir ein RS485-Bus aufzubauen. Zuerst wollte ich CAN 
nutzen, bin dann aber doch auf RS485 umgestiegen, da mir die Datenrate 
bei zu langer Leitungslänge zu gering war (wird am Ende etwa insgesamt 
1km Cat5-Kabel sein (mit allen Abzweigungen), und 250kbit/s hätte ich 
schon gerne). Die Bandbreite brauch ich halt, da ich teilweise auch 
Audio-Daten übertrage.
Außerdem erschien es mir doch einfacher für die doch stark ausgelasteten 
Controller der Slaves, ein simples UART-Protokoll zu handhaben anstelle 
von CAN. Zudem scheint es ja bei CAN keine Möglichkeit zu geben, bei 
insg. 1km Leitungslänge Datenraten von 250kbit/s zu erreichen, auch habe 
ich keine wirklichen Hubs für CAN gefunden, wie sie für RS485 existieren 
:/

Ich habe also vor, meinen RS485-Bus ähnlich DMX aufzubauen, d.h. ein 
Segment hat max. 300m, dann kommt ein Repeater, max 32. Slaves pro 
Segment, etc.
Das Protokoll ist recht simpel, es besteht aus 4 Byte, das erste Byte 
enthält die Adresse und die 3 anderen Bytes enthalten Daten. Theo. muss 
ein Slave nur schauen, ob seine Adresse übereinstimmt, falls nein die 
nächsten 3 Bytes ignorieren und dann nochmal nachschauen.

Es gibt im Bus einen Master, der über einen extra RS485-Kanal seine 
Daten an die Slaves sendet. Auf diesem Kanal sendet auch NUR der Master, 
von daher dürfte es hier zu keiner Kollision kommen.
Zugleich hab ich noch einen Rückkanal, der dazu dient, Daten von den 
Slaves zum Master zu senden, falls der Master Daten anfordert. Und dies 
ist mein Problem. Normalerweise dürfte ja nichts schief gehen, aber es 
könnte ja, aus irgendwelchen Gründen, plötzlich ein Slave auf die Idee 
kommen, Daten zu senden (oder sendet seine Daten zeitlich verzögert, 
sodass ein andere Slave bereits sendet) und es kommt zu einer Kollision.
Wie kann ich dies nun verhindern bzw. erkennen. Wie ich bisher in 
Erfahrung bringen konnte, geht dies mit RS485-Treiber nicht, da hier 
eine Kollision ein Kurzschluss ist. Also müsste ich für eine 
Kollision-Erkennung CAN-Treiber verwenden, richtig?

Am besten würde ich es jedoch finden, wenn ich irgendwie erkennen 
könnte, ob Daten bereits auf dem Rückkanal gesendet werden. Jedoch weiß 
ich nicht, wie. Wenn ich CAN-Treiber nutzen würde, könnte ich ja einfach 
Rx auf den RX-Pin des Atmegas legen, aber dummerweise ist der schon mit 
dem RS485-Kanal vom Master beleget. Von daher wollte ich mal Fragen, ob 
es eine Möglichkeit gibt, mithilfe eines "normalen" Pin eines Atmegas 
festzustellen, ob auf dem Bus gerade gesendet wird. Dann könnte der 
Slave ja einfach warten, bis niemand mehr sendet.

Hoffe, ihr könnt mir etwas weiterhelfen, oder mit evtl. doch wieder CAN 
schmackhaft machen, aber wie gesagt, Grundbedingung wäre, dass günstige 
HUBs verfügbar sind, sodass ich Segmente à 300m zu insgesamt etwa 1km 
Leitung zusammenschließen kann und trotzdem Datenraten von etwa 
250kbit/s erreiche.

So, viel Text, mal hoffen, dass es nicht abschreckt ;)

Viele Grüße
Julian

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:
> Am besten würde ich es jedoch finden, wenn ich irgendwie erkennen
> könnte, ob Daten bereits auf dem Rückkanal gesendet werden. Jedoch weiß
> ich nicht, wie.

Hallo Julian,

das verhindert Kollisionen nicht: hört ein Client auf zu senden, dann 
können 2 oder mehr andere Clients auf die Idee kommen, ihrerseits Daten 
zu senden. Wie man das einschränkt, ist bei Ethernet beschrieben (das 
ist CS - Carrier Sense - in CSMA-CD), aber damit werden Kollisionen nur 
seltener, nicht unmöglich. Deswegen ist trotzdem "Collision Detect" 
erforderlich (das CD ins CSMA-CD).

Ein deterministisch geregelter Zugriff ist nur möglich, wenn ein Token 
kreist oder in einer Master-Slave-Umgebung der Master bestimmt, wer wann 
senden darf.

Also zurück auf Los.

Gruss Reinhard

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Julian,

in einer ähnlichen Situation - aber ohne zwei Kanäle - haben wir uns 
entschlossen, CAN-Treiber, aber kein CAN-Protokoll zu verwenden. Die 
Treiber sind kollisionsfest, der zurückgelesene Wert ist eindeutig 
definiert - die Kollision ist sauber erkennbar.

Wir lesen das Echo zurück und senden das nächste Byte erst und nur, wenn 
das Echo des letzten angekommen ist. Also Byte-weise CD, wenn Du so 
willst.

Es gibt also Kollisionen, aber sie werden behandelt. Das geht natürlich 
zu Lasten des Durchsatzes, weil immer wieder gewartet und gelegentlich 
abgebrochen wird.

Das Gegenkonzept ist der Token, der das Senden sauber regelt. Wenn Du 
das richtig implementierst, kann es kaum zu Kollisionen kommen. Selbst 
wenn ein Client verzögert reagiert, liefert er ja erst zum Schluss den 
Token zurück - vorher darf keiner senden. Auch eine 
Master-Slave-Organisation würde zu diesem Effekt führen, Reinhard hat da 
völlig Recht.

In beiden Fällen musst Du aber andere Probleme lösen, das Recovery eines 
verlorenen Tokens oder ein ausgefallener Master.

Gruß
Jens

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man schon 2 separate differentielle Busse verwendet, dann kann man 
vielleicht auch so frech sein, echtes CAN für Steuerung und Arbitrierung 
und echtes RS485 für hohen Datendurchsatz zu kombinieren ;-).

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mist, geht also auch nicht. Eine Idee, die ich noch hatte, war einfach 
eine zusätzliche Leitung zu verlegen. Wenn ein Slave sendet, zieht er 
diese auf High und nachher auf Low.
Dummerweise müsste ich dafür nun eine zusätzliche Leitung ziehen und 
zudem weiß ich nicht, ob da nach 300m auch noch sicher High anliegt, 
also auch alles sehr "wackelig".

Das mit dem Token hab ich mir auch schon überlegt, aber das Problem mit 
dem verloren Token hasst du ja schon angesprochen. Der ausgefallene 
Master müsste ich nicht behandeln, dass wäre nämlich der SuperGAU und 
damit würde eh erst mal alles still stehen ;)

Also da würde ich ja fast wieder auf CAN zurückkommen, aber dafür müsste 
ich zwingend Segmente mit jeweils 300m so miteinander verbinden, sodass 
ich die 250kbit/s erreiche (wobei, da muss ich ja noch jede Menge 
Overhead durch Can abziehen...).
Und der einzige IC, der "gerade mal" 2 CAN-Segmente miteinander 
verbinden kann, kostet fast 13€ bei farnell, was mir etwas teuer ist :/
ON SEMICONDUCTOR - AMIS42770ICAW1RG
http://de.farnell.com/on-semiconductor/amis42770ic...

Oder was denkt ihr, ist es mit einem Atmega und mehreren CAN-Controllern 
möglich, 250kbit/s "durchzureichen", wobei dann auch Probleme mit 
Kollisionen auftreten könnten, ich puffern muss, ....

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wenn man schon 2 separate differentielle Busse verwendet, dann kann man
> vielleicht auch so frech sein, echtes CAN für Steuerung und Arbitrierung
> und echtes RS485 für hohen Datendurchsatz zu kombinieren ;-).

Das wäre noch eine Lösung, bei etwa 1km hätte ich bei CAN immerhin noch 
50kbti/s, die könnten reichen...

Autor: Jens Martin (jens-martin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:
> ich plane gerade, mir ein RS485-Bus aufzubauen.

Warum?

> Zuerst wollte ich CAN
> nutzen, bin dann aber doch auf RS485 umgestiegen, da mir die Datenrate
> bei zu langer Leitungslänge zu gering war

Bei CAN ist die Kollisionserkennung so gebaut das sich lange 
Leitungslängen und hohe Datenraten faktisch ausschließen

> (wird am Ende etwa insgesamt
> 1km Cat5-Kabel sein (mit allen Abzweigungen),

und du hast auch an den Wellenwiderstand die Leitungsreflektionen
an Abschlusswiderstände und Interferenzen gedacht?

> und 250kbit/s hätte ich
> schon gerne). Die Bandbreite brauch ich halt, da ich teilweise auch
> Audio-Daten übertrage.

Warum nimmst du dann nicht Ethernet?


> Außerdem erschien es mir doch einfacher für die doch stark ausgelasteten
> Controller der Slaves, ein simples UART-Protokoll zu handhaben anstelle
> von CAN.
Wenn die Slaves so stark ausgelastet sind wie sollen Sie auch noch die 
doch eher ineffizeinte ungesicherte RS485 Übertragung managen?


> Zudem scheint es ja bei CAN keine Möglichkeit zu geben, bei
> insg. 1km Leitungslänge Datenraten von 250kbit/s zu erreichen,

s.o.

> auch habe
> ich keine wirklichen Hubs für CAN gefunden,

Du brauchst auch eine Bridge.


> wie sie für RS485 existieren

Wobei die Frage wie die bei diesem Tempo mit der Adressierung umgehen 
was für Spezies ist.

Das ist sicher alles nicht falsch, nur hast du keinerlei 
Sicherungsschicht wenn Störungen auftreten (was bei dieser Leitungslänge 
sicher nicht ungewöhnlich wäre).

Einfacher ist es sicher die Daten asynchron auf die Reise zu schicken, 
nur was auf der anderen Seite bei dem Tempo ankommt hängt von den 
Umständen ab auf die deine Bitpäckche nunterwegs reffen.

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens Martin schrieb:
>> ich plane gerade, mir ein RS485-Bus aufzubauen.
>
> Warum?

Ist quasi mein "Pilot-Projekt" zur Hausautomatisierung

Jens Martin schrieb:
>> Außerdem erschien es mir doch einfacher für die doch stark ausgelasteten
>> Controller der Slaves, ein simples UART-Protokoll zu handhaben anstelle
>> von CAN.
> Wenn die Slaves so stark ausgelastet sind wie sollen Sie auch noch die
> doch eher ineffizeinte ungesicherte RS485 Übertragung managen?

Nunja, 99% der Nodes werden wohl "im Leerlauf" sein, nur der eine, der 
gerade mit den Audio-Daten "beschossen" wird, hat halt doch etwas zu 
arbeiten.

Jens Martin schrieb:
>> (wird am Ende etwa insgesamt
>> 1km Cat5-Kabel sein (mit allen Abzweigungen),
>
> und du hast auch an den Wellenwiderstand die Leitungsreflektionen
> an Abschlusswiderstände und Interferenzen gedacht?

Daher teile ich das ganze in Segmente der Länge 300m ein. Alle 300m wird 
dann, wie bei DMX, ein Repeater/Booster sein, der das Signal 
"auffrischt".

Jens Martin schrieb:
>> Zuerst wollte ich CAN
>> nutzen, bin dann aber doch auf RS485 umgestiegen, da mir die Datenrate
>> bei zu langer Leitungslänge zu gering war
>
> Bei CAN ist die Kollisionserkennung so gebaut das sich lange
> Leitungslängen und hohe Datenraten faktisch ausschließen

Daher wollte ich den CAN ja in 300m Segmente aufteilen, und dieses 
Segmente miteinander verbinden. Somit wäre jeder Bus nur 300m lang und 
doch wäre jeder Node erreichbar.
Dadurch würde wohl die Latenz etwas hochgehen, aber das wäre nicht so 
tragisch, ob das Licht jetzt 10ms nachdem ich den Schalter gedrückt 
habe, angeht oder nicht.

> Das ist sicher alles nicht falsch, nur hast du keinerlei
> Sicherungsschicht wenn Störungen auftreten (was bei dieser Leitungslänge
> sicher nicht ungewöhnlich wäre).

Daher wollte ich ja zuerst CAN einsetzten, da hier ja die Übertragung 
gesichert ist, nur mit der Leitungslänge gibt es da ja dummerweise 
Probleme.


Jens Martin schrieb:
>> und 250kbit/s hätte ich
>> schon gerne). Die Bandbreite brauch ich halt, da ich teilweise auch
>> Audio-Daten übertrage.
>
> Warum nimmst du dann nicht Ethernet?

Zum ersten mal ist das nicht ganz so günstig in Sachen Preis und 
Stromverbrauch, zum anderen wollte ich AVR Atmegas nutzen und da einen 
TCP/IP-Stack zu implantieren, ist erstens nicht ganz einfach und 
bestimmt nicht sehr ressourcensparend.



Wenn ich es schaffe würde, z.B. 3 CAN-Segmente mit je 300m 
zusammenzuschalten, also alle Nachrichten durchgereicht werden, dürfte 
ich doch trotzdem die 250kbit/s schaffen.
Klar, wenn eine Message durch alle 3 "CAN-Busse" gehen muss, bis sie 
ankommt, dürfte die Latenz etwas hoch gehen, aber das dürften doch noch 
im ms Bereich liegen. Die Frage ist halt nur, wie Verbinde ich 2 
CAN-Busse miteinander.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:
> Zum ersten mal ist das nicht ganz so günstig in Sachen Preis und
> Stromverbrauch, zum anderen wollte ich AVR Atmegas nutzen und da einen
> TCP/IP-Stack zu implantieren, ist erstens nicht ganz einfach und
> bestimmt nicht sehr ressourcensparend.

Auf Ethernet muss nicht zwingend IP gefahren werden. Und wenn der Switch 
STP kann gibts auch ein wenig Redundanz. Such dir dann aber bitte eine 
Ethernet-Protokoll-ID die keiner nutzt.

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter schrieb:
> Julian W. schrieb:
>> Zum ersten mal ist das nicht ganz so günstig in Sachen Preis und
>> Stromverbrauch, zum anderen wollte ich AVR Atmegas nutzen und da einen
>> TCP/IP-Stack zu implantieren, ist erstens nicht ganz einfach und
>> bestimmt nicht sehr ressourcensparend.
>
> Auf Ethernet muss nicht zwingend IP gefahren werden. Und wenn der Switch
> STP kann gibts auch ein wenig Redundanz. Such dir dann aber bitte eine
> Ethernet-Protokoll-ID die keiner nutzt.

Gut, aber ich bräuchte ja immer noch pro Node einen Port am Switch, und 
auch der Stromverbrauch von Ethernet ist nicht ganz unerheblich...

Autor: Jens Martin (jens-martin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:
> Wenn ich es schaffe würde, z.B. 3 CAN-Segmente mit je 300m
> zusammenzuschalten, also alle Nachrichten durchgereicht werden, dürfte
> ich doch trotzdem die 250kbit/s schaffen.

Nur hast du dann auch ein paar investitionen, musst die Bridges powern 
und die Telegramme auch  queuen.

> Klar, wenn eine Message durch alle 3 "CAN-Busse" gehen muss, bis sie
> ankommt, dürfte die Latenz etwas hoch gehen,

Wenn du mit 250kb/s die Bridge vollballerst und auf der anderen Seite 
gequasselt wird musst du erstmal das ganze in einem Fifo 
zwischenspeichern. Den dann mit 250kbs gleichzeitig zu füllen und zu 
leeren ist nun wahrlich keine Haustechnik mehr

Das ist aber bei TCP/IP Stacks und Struktur mit drin

> aber das dürften doch noch
> im ms Bereich liegen. Die Frage ist halt nur, wie Verbinde ich 2
> CAN-Busse miteinander.

Eine Bridge ist laut http://de.wikipedia.org/wiki/OSI-Modell genau als 
das Teil das definiert das zwei segmentierte aber sonst gleichartige 
Busse miteinander verbindert.

Ob diese schöne Theorie aber in der Praxis günstiger wird als das 
Massenkonsumerprodukt Ethernet wage ich zu bezweifeln?

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, angenommen, ich würde Ethernet benutzten, wie würde das da 
aussehen. Leider habe ich noch nie was mit Ethernet gemacht.
Einzig den ENC28J60 hab ich schon mal in dem Zusammenhang gehört.

Könntest du mir kurz erklären, wie so ein Netzwerk grob aussehen würde?

Verkablung wäre dann wohl Stern, also immer zum Switch hin. Die 
Möglichkeit eines Stranges dürfte wohl nicht bestehen.
Und wie sieht das mit der Ansteuerung aus, wenn ich nicht TCP/IP nutze, 
wie identifiziere ich die Nodes? Über die MAC?

Autor: Jens Martin (jens-martin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:
> Könntest du mir kurz erklären, wie so ein Netzwerk grob aussehen würde?

Julian, das Netz ist voll mit dem Zeugs, ich glauib das bekommst do ohne 
Hilfe hin.

Julian W. schrieb:
> Verkablung wäre dann wohl Stern, also immer zum Switch hin. Die
> Möglichkeit eines Stranges dürfte wohl nicht bestehen

Nun, wenn du CAT5 6 7  legst ist das doch eh egal.

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nunja, was ich aber immer im Netz finde (auch auf Bezug auf AVRs) sind 
TCP (IPv4 und IPv6) bzw. UDP-Stacks. Das ist ja scheinbar nicht dass, 
was ich haben will.
Außerdem wäre es für mich dann noch interessant, ob ich in dieses Netz 
noch meinen Windows-Rechner klemmen könnte oder würde das Probleme 
geben, z.B. mit Boradcast-Paketen?

Einzig auf Wikipedia hab ich was gefunden:
http://de.wikipedia.org/wiki/Ethernet

Das würde dann z.B. heißen, ich würde als EtherType z.B. einfach 0xAAAA 
nehmen und schon könnte ich einfach mithilfe der MAC-Adresse Daten 
versenden?

Und mit dem Kabel ist es nicht ganz egal, da pro Strang etwa 10 Nodes 
sein werden. Aber trotzdem bräuchte ich ja nur 1x 300m, wenn ich das 
ganze linear verlegen würde.
Wenn ich nun von jedem Node ein Kabel zum Switch legen muss, sind das am 
Ende 10 Kabel unterschiedlicher Länge, was im Endeffekt jedoch erheblich 
mehr sein dürfte, da schon alleine das Kabel des letzten Nodes 300m sein 
muss.

Autor: Jens Martin (jens-martin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:
> Nunja, was ich aber immer im Netz finde (auch auf Bezug auf AVRs) sind
> TCP (IPv4 und IPv6) bzw. UDP-Stacks. Das ist ja scheinbar nicht dass,
> was ich haben will.

Das ist auch alles andere als trivial, aber warum nicht die long 
dsitance mit der entsprechenden Technologie überbrücken und von dort 
seriell die Devices einbinden?

> Außerdem wäre es für mich dann noch interessant, ob ich in dieses Netz
> noch meinen Windows-Rechner klemmen könnte oder würde das Probleme
> geben, z.B. mit Boradcast-Paketen?

Wenn das ganze sauber aufgebaut ist macht es keinen Unterschied.
Hier schwirrt alles mögliche im Netz rum PCs Server ComServer embedded 
devices usw. usf

>
> Einzig auf Wikipedia hab ich was gefunden:
> http://de.wikipedia.org/wiki/Ethernet
>
> Das würde dann z.B. heißen, ich würde als EtherType z.B. einfach 0xAAAA
> nehmen und schon könnte ich einfach mithilfe der MAC-Adresse Daten
> versenden?

Nimm ein Ethernet Modul wo alles drin ist, (gibt es komplett in der 
Buchse) wenn du das ganze selbst aufbauen willst erfindest du das Rad 
zum 10. mal. Nr. 1-9 haben auch ein paar Jährchen gebraucht.


>
> Und mit dem Kabel ist es nicht ganz egal, da pro Strang etwa 10 Nodes
> sein werden. Aber trotzdem bräuchte ich ja nur 1x 300m, wenn ich das
> ganze linear verlegen würde.

Dann mach doch Multitechnologie, 2 paare 100mBit (mehr braucht Ethernet 
da nicht ist auch genormt wo die liegen ) paar 3 RS485 Paar 4 CAN. Dann 
kannst du per Pinbelegung entscheiden ob da nun ein Ring Stern oder 
sonstige Gewölle angeklemmt wird.

> Wenn ich nun von jedem Node ein Kabel zum Switch legen muss, sind das am
> Ende 10 Kabel unterschiedlicher Länge, was im Endeffekt jedoch erheblich
> mehr sein dürfte, da schon alleine das Kabel des letzten Nodes 300m sein
> muss.

Eine FO (Fiberoptik) Strecke bringt da schon einiges. Auch in Hinblick 
auf Masse Shield Ableitströme und das ganze andere feine Zeugs was man 
als Anfänger (manchmal schmerzhaft) erlernt

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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