CSMA/CD oder Token bei RS485

[Jürgen Leeb]

Hallo zusammen,

ich bin gerade im Anfangsstadium eines kleines Projekts. Es geht um ein
Bussystem (phyiskalisch: RS845) für Multimaster access. Die Master
werden AVRs und steuern die Rollos.
Ich habe mir gerade ein paar verschiedene Systeme angesehen. LON,
ARCNET, P-NET. Nun stellt sich natürlich die Frage, wie regele ich den
Multimaster-Buszugriff.
P-NET basiert auf einen Token (Virtuell kein Tokenaustausch über Bus)
ARCNET basiert auf einen "echten Token" und LON auf CSMA.

Ich will eigentlich auf das aufwendige Token .. verzichten und CSMA
verwenden. Nur wie erkenne ich Collisionen? Oder muss ich sie, wenn ich
ein Protokoll mit Sender-, Empfängeradresse, CRS und ACK nutze, gar
nicht erkennen? Die Buslast ist äußerst gering!


Vielen Danke schon mal im voraus!

Gruß Jürgen



P.S. vielleicht kennt jemand von Euch andere Protokolle, die ich mir
ansehen sollte?

[Holger Blum]

Post by Jürgen Leeb
ich bin gerade im Anfangsstadium eines kleines Projekts. Es geht um ein
Bussystem (phyiskalisch: RS845) für Multimaster access. Die Master
werden AVRs und steuern die Rollos.

Also geringe Buslast und keine Echtzeitfähigkeit notwendig.

Post by Jürgen Leeb
Ich habe mir gerade ein paar verschiedene Systeme angesehen. LON,
ARCNET, P-NET. Nun stellt sich natürlich die Frage, wie regele ich den
Multimaster-Buszugriff.
P-NET basiert auf einen Token (Virtuell kein Tokenaustausch über Bus)
ARCNET basiert auf einen "echten Token" und LON auf CSMA.

Wenn das ein autonomes System sein soll dann stricke dir dein eigenes
Einfachst-Protokoll. Die Token-Geschichten kannst du dir sparen, da die
Steuerung zeitunkritisch ist.

Post by Jürgen Leeb
Ich will eigentlich auf das aufwendige Token .. verzichten und CSMA
verwenden. Nur wie erkenne ich Collisionen? Oder muss ich sie, wenn ich
ein Protokoll mit Sender-, Empfängeradresse, CRS und ACK nutze, gar
nicht erkennen? Die Buslast ist äußerst gering!

In deinem Fall ist CSMA/CD die einfachste Lösung.
Durch die geringe Buslast ist die Gefahr von Kollisionen äußerst gering.
Tritt dennoch eine auf, so erkennt dies der Sender, indem er den
Buspegel mit seinen Sendedaten vergleicht. Findet er auf dem Bus nicht
den erwarteten Pegel vor so sendet er ein Jam-Signal und die Empfänger
verwerfen die bis dahin empfangenen Daten.
Er wartet eine zufällige Zeit und versucht dann erneut eine Übertragung.

Mehr braucht es bei deiner unkritischen Anwendung nicht!

Viele Grüße,
Holger

[Marc Keller]

Post by Holger Blum
In deinem Fall ist CSMA/CD die einfachste Lösung.
Durch die geringe Buslast ist die Gefahr von Kollisionen äußerst gering.
Tritt dennoch eine auf, so erkennt dies der Sender, indem er den
Buspegel mit seinen Sendedaten vergleicht. Findet er auf dem Bus nicht
den erwarteten Pegel vor so sendet er ein Jam-Signal und die Empfänger
verwerfen die bis dahin empfangenen Daten.
Er wartet eine zufällige Zeit und versucht dann erneut eine Übertragung.
Mehr braucht es bei deiner unkritischen Anwendung nicht!
Viele Grüße,
Holger

Bingo!
Und das ist im Volksmund bekannt als "Ethernet"... :-)
Heute eigentlich gar nicht mehr wegzudenken.
Carrier Sense (lauschen am Kabel) Multiple acces (alle teilen sich das
kabel)
collistion detect (kollistionserkennung).
Eigentlich ne blöe Abkürzung für so was geniales.

cu Marc

[Jürgen Leeb]

Hallo Marc

Post by Marc Keller
Bingo!
Und das ist im Volksmund bekannt als "Ethernet"... :-)

Nicht ganz richtig. CSMA/CD ist ein Zugriffsverfahren. Ethernet (2. Osi
schicht glaube ich) nutzt nur dieses Verfahren. CSMA/CD ist aber kein
Synonym für Ethernet. Es gibt auch andere Bussystem, die mit RS485
arbeiten (s. LON);

Post by Marc Keller
Heute eigentlich gar nicht mehr wegzudenken.
Carrier Sense (lauschen am Kabel) Multiple acces (alle teilen sich das
kabel)
collistion detect (kollistionserkennung).
Eigentlich ne blöe Abkürzung für so was geniales.
cu Marc

[Jürgen Leeb]

Danke für Deine Antwort!

Post by Holger Blum

Post by Jürgen Leeb
ich bin gerade im Anfangsstadium eines kleines Projekts. Es geht um ein
Bussystem (phyiskalisch: RS845) für Multimaster access. Die Master
werden AVRs und steuern die Rollos.

Also geringe Buslast und keine Echtzeitfähigkeit notwendig.

Ja, so ist es.

Post by Holger Blum
Wenn das ein autonomes System sein soll dann stricke dir dein eigenes
Einfachst-Protokoll. Die Token-Geschichten kannst du dir sparen, da die
Steuerung zeitunkritisch ist.

Ja dachte daran das Protokoll in etwa so aufzubauen:
EmpfängerADR, QuellADR, Protokolltyp, Daten, CRC;
Der Empfänger muss dann auch ein ACK-Protokoll zurückschicken.

Post by Holger Blum
In deinem Fall ist CSMA/CD die einfachste Lösung.
Durch die geringe Buslast ist die Gefahr von Kollisionen äußerst gering.
Tritt dennoch eine auf, so erkennt dies der Sender, indem er den
Buspegel mit seinen Sendedaten vergleicht. Findet er auf dem Bus nicht
den erwarteten Pegel vor so sendet er ein Jam-Signal und die Empfänger
verwerfen die bis dahin empfangenen Daten.
Er wartet eine zufällige Zeit und versucht dann erneut eine Übertragung.

Dazu gleich nochmal 3 Fragen:
- Der Vorschlag beinhaltet echte Collision Detection. Kann ich mit dem
Treiberbaustein (MAX485 o.a) den Buspegel abfragen, oder bedarf es hier
noch zusätzlichen Schaltungsaufwand? Oder gibt es spezielle
Treiberbausteine?
- Ich denke gerade an I2C. Hier ist das mit dem Multimaster so geregelt,
daß das 1 Signal vorrang hat. D.h. fangen zwei Master an zu senden
(Vorher der Bus auf Leerlauf geprüft), dann sind die Daten solange
gültig, wie sie die selben Bits senden. Erst wenn einer ein anderes Bit,
als der Andere schickt, wird erkannt, das zwei Teilnehmer auf den Bus
zugreifen. Da High Vorrang hat merkt es der Master, der 1 schickt nicht.
Für ihn ist alle in Ordnung. Der der 0 schickt erkennt, das der Bus 1
ist. Er ist somit sofort still und werden wieder auf das freiwerden des
Busses. Der andere Teilnehmer bekommt vom Ganzen gar nichts mit. Ist
dieses Vorgehen bei RS485 auch möglich?
- Brauche ich überhaupt ein Collision Detection? Reicht es nicht aus,
daß der Master ein Telegramm schickt und auf ein Ack. vom Empfänger
wartet. Erhält er es, so ist alles O.K.. Wenn nicht war etwas falsch.
Vielleicht gab es eine Kollision. Auf alle Fälle wartet er eine gewisse
Zeit und probiert es dann erneut.

[Juergen Hannappel]

Jürgen Leeb <***@bar.de> writes:


[...]

Post by Jürgen Leeb
- Brauche ich überhaupt ein Collision Detection? Reicht es nicht aus,
daß der Master ein Telegramm schickt und auf ein Ack. vom Empfänger
wartet. Erhält er es, so ist alles O.K.. Wenn nicht war etwas falsch.

Ich denke das das reicht, und DU wirst (wegen der kleinen Buslast)
auch auf den CD (Carrier Detect) verzichten koennen, obwohl den der
Empfaenger auf dem Bus (braucht Du ja sowieso) fast liefert.

[Holger Blum]

Hallo Jürgen,

Post by Juergen Hannappel
Ich denke das das reicht, und DU wirst (wegen der kleinen Buslast)
auch auf den CD (Carrier Detect) verzichten koennen, obwohl den der
Empfaenger auf dem Bus (braucht Du ja sowieso) fast liefert.

zu der Überzeugung bin ich jetzt auch gekommen...
Aber CD steht für Collision Detection, der Carrier steckt im CSMA
(Carrier Sense Multiple Access).

Viele Grüße,
Holger

[Holger Blum]

Post by Jürgen Leeb
- Der Vorschlag beinhaltet echte Collision Detection. Kann ich mit dem
Treiberbaustein (MAX485 o.a) den Buspegel abfragen, oder bedarf es hier
noch zusätzlichen Schaltungsaufwand? Oder gibt es spezielle
Treiberbausteine?

Zusätzliche Hardware brauchst du nicht, in dem Baustein haben Receiver
und Transmitter unabhängige Enable-Eingänge. Der Treiber muss eben immer
am Bus lauschen indem /RO fest auf Masse gelegt wird, der Rest ist
natürlich Software.
Bleibt nur die Frage, wie die Pegel bei einer Kollision aussehen...

Post by Jürgen Leeb
- Ich denke gerade an I2C. Hier ist das mit dem Multimaster so geregelt,
daß das 1 Signal vorrang hat. D.h. fangen zwei Master an zu senden
(Vorher der Bus auf Leerlauf geprüft), dann sind die Daten solange
gültig, wie sie die selben Bits senden. Erst wenn einer ein anderes Bit,
als der Andere schickt, wird erkannt, das zwei Teilnehmer auf den Bus
zugreifen. Da High Vorrang hat merkt es der Master, der 1 schickt nicht.
Für ihn ist alle in Ordnung. Der der 0 schickt erkennt, das der Bus 1
ist. Er ist somit sofort still und werden wieder auf das freiwerden des
Busses. Der andere Teilnehmer bekommt vom Ganzen gar nichts mit. Ist
dieses Vorgehen bei RS485 auch möglich?

Das nennt man dann CSMA/CA, also collision avoidance. Hier ist es
sinnvoll, die Quelladresse zuerst zu übertragen, da durch diese die
Priorität des Teilnehmers festgelegt ist. Wenn zwei Teilnehmer
gleichzeitig senden stoppt der niederpriore die Übertragung, sobald er
auf dem Bus einen abweichenden Pegel erkennt. Es ist beim I2C-Bus die 0
dominant, da der Bus über einen Pull-up auf high gehalten wird und die
Ausgänge als Wired-AND verschaltet sind. Das heißt der Buspegel wird 0,
sobald ein Teilnehmer eine 0 sendet.

Ich weiß aber ehrlich gesagt nicht, wie es mit CD oder CA am RS485-Bus
aussieht, insbesondere welche Pegel sich auf der Leitung bei einer
Kollision einstellen.

Wenn dich das interessiert informierst du dich am besten einmal über den
CAN-Bus, dieser basiert wenn ich mich recht erinnere auf RS485 und
verwendet CSMA/CA.

Post by Jürgen Leeb
- Brauche ich überhaupt ein Collision Detection? Reicht es nicht aus,
daß der Master ein Telegramm schickt und auf ein Ack. vom Empfänger
wartet. Erhält er es, so ist alles O.K.. Wenn nicht war etwas falsch.
Vielleicht gab es eine Kollision. Auf alle Fälle wartet er eine gewisse
Zeit und probiert es dann erneut.

Wenn ich es mir recht überlege kannst du dir das alles sparen, bei der
Anwendung hast du ja alle Zeit der Welt um nach einem Timeout oder
CRC-Fehler das Datagramm neu zu übertragen.

Aber gut, dass wir darüber gesprochen haben ;)

Viele Grüße,
Holger

[Ulrich Prinz]

Hallo Jürgen!

Schön Dich wieder zu sehen :-)

Post by Jürgen Leeb
EmpfängerADR, QuellADR, Protokolltyp, Daten, CRC;
Der Empfänger muss dann auch ein ACK-Protokoll zurückschicken.

Post by Holger Blum
In deinem Fall ist CSMA/CD die einfachste Lösung.
Durch die geringe Buslast ist die Gefahr von Kollisionen äußerst gering.
Tritt dennoch eine auf, so erkennt dies der Sender, indem er den
Buspegel mit seinen Sendedaten vergleicht. Findet er auf dem Bus nicht
den erwarteten Pegel vor so sendet er ein Jam-Signal und die Empfänger
verwerfen die bis dahin empfangenen Daten.
Er wartet eine zufällige Zeit und versucht dann erneut eine Übertragung.

Da der Bus Push-Pull Getrieben wird, ist es eine Frage der
Schmitttrigger, was gerade als logischer Wert anliegt. Also mehr dem
Zufall überlassen.
Doch wozu eine Kontrolle der Sendedaten? Zum einen geben die Treiber das
nicht her, weil zwischen Senden und Empfangen meist nur mit einer
Steuerleitung umgeschaltet wird. Man müßte dann also zwei oder einen
Dual-Tranceiver einsetzen.

Dazu kommt, dass doch eine CRC übertragen wird. Diese stellt doch
sicher, dass eine Kollision erkannt wird. In dieser einfachen Anwendung
kann man es also einfach krachen lassen und bei ausbleibendem ACK die
Message nach einer Zeit wiederholen. So wird das auch bei EIB gemacht.

Um eine Dauer-Kollision zu vermeiden, sollte man der Wartezeit zwischen
den Wiederholungen einen Zufallsfaktor hinzufügen.

Post by Jürgen Leeb
- Der Vorschlag beinhaltet echte Collision Detection. Kann ich mit dem
Treiberbaustein (MAX485 o.a) den Buspegel abfragen, oder bedarf es hier
noch zusätzlichen Schaltungsaufwand? Oder gibt es spezielle
Treiberbausteine?
- Ich denke gerade an I2C. Hier ist das mit dem Multimaster so geregelt,
daß das 1 Signal vorrang hat. D.h. fangen zwei Master an zu senden
(Vorher der Bus auf Leerlauf geprüft), dann sind die Daten solange
gültig, wie sie die selben Bits senden. Erst wenn einer ein anderes Bit,
als der Andere schickt, wird erkannt, das zwei Teilnehmer auf den Bus
zugreifen. Da High Vorrang hat merkt es der Master, der 1 schickt nicht.
Für ihn ist alle in Ordnung. Der der 0 schickt erkennt, das der Bus 1
ist. Er ist somit sofort still und werden wieder auf das freiwerden des
Busses. Der andere Teilnehmer bekommt vom Ganzen gar nichts mit. Ist
dieses Vorgehen bei RS485 auch möglich?

IMHO nicht, da der Bus nach Push-Pull getrieben wird, also im
Kollisionsfall ein Mittelwert aus den angelegten Spannungen anliegt. Wie
dieser Wert dann interpretiert wird, ist allein von Zufälligen Faktoren,
wie Groundshift, Schmitttrigger-Schwellwerte und Versatz der Kollision
mit entsprechenden Ein- und Ausschwingzeiten abhängig.

Post by Jürgen Leeb
- Brauche ich überhaupt ein Collision Detection? Reicht es nicht aus,
daß der Master ein Telegramm schickt und auf ein Ack. vom Empfänger
wartet. Erhält er es, so ist alles O.K.. Wenn nicht war etwas falsch.
Vielleicht gab es eine Kollision. Auf alle Fälle wartet er eine gewisse
Zeit und probiert es dann erneut.

Das ist doch eine Kollision-Detection. Wenn man einen Defekt der
Software ausschließen kann, dann bedeuten CRC-Fehler Störungen in der
Übertragung. Diese können durch äußere Einflüsse passieren, aber eben
auch durch Kollisionen. Nur weil der CRC noch andere Fehler abfangen
kann, heißt das nicht, dass er nicht auch eine Collision-Detection erlaubt.


Gruß,

Ulrich

Ps. Meld Dich ddoch mal wieder per PM. Mein plötzliches Verstummen war
nicht freiwillig :-)

[Michael Schöberl]

Post by Jürgen Leeb
- Brauche ich überhaupt ein Collision Detection? Reicht es nicht aus,
daß der Master ein Telegramm schickt und auf ein Ack. vom Empfänger
wartet. Erhält er es, so ist alles O.K.. Wenn nicht war etwas falsch.

ja - es gibt noch ein weiteres Verfahren das noch "primitiver" ist ...


ALOHA: einfach senden, falls kein Ack durchkommt, dann irgendwann
(random delay) nochmal senden - alles ohne Check ob Bus frei ist

... max. Auslastung des Busses bei 18% rechnerisch
wenn du also im Mittel pi mal Daumen nur 1% der max. Übertragungsrate
brauchst, dann reichts)

Der Empänger muss eine Checksumme empfangen und prüfen - falls diese
falsch ist Nachricht verwerfen - sonst Ack zurücksenden



Slotted Aloha: Die Sendestarts werden Synchronisiert - die Nachrichten
überlappen also entweder voll oder garnicht. Dadurch werden rechnerisch
36% möglich..
(die Sync herzustellen ist hier aber wohl mehr Aufwand als der Nutzen)




weitere Verbesserungen wurden bereits angesprochen

- vor dem Senden horchen ob der Bus frei ist (CSMA)
auch hier ist noch eine Ack-Nachricht zur Rückmeldung nötig und
erneutes verzögertes Senden falls kein Ack kam
man könnte also erst mal Aloha implementieren und dann ein "Sensing
vor dem Senden" nachrüsten ...


- während dem Senden auf Kollision achten (CSMA/CD) und
ggf Abbrechen+Jam
das stelle ich mir komplizierter vor - gleichzeitig senden und wieder
empfangen? kann man dann überhaupt noch die serielle Schnittstelle im
Atmel verwenden?




bye,
Michael

[Ulrich Prinz]

Post by Michael Schöberl

Post by Jürgen Leeb
- Brauche ich überhaupt ein Collision Detection? Reicht es nicht aus,
daß der Master ein Telegramm schickt und auf ein Ack. vom Empfänger
wartet. Erhält er es, so ist alles O.K.. Wenn nicht war etwas falsch.

ja - es gibt noch ein weiteres Verfahren das noch "primitiver" ist ...
ALOHA: einfach senden, falls kein Ack durchkommt, dann irgendwann
(random delay) nochmal senden - alles ohne Check ob Bus frei ist
... max. Auslastung des Busses bei 18% rechnerisch
wenn du also im Mittel pi mal Daumen nur 1% der max. Übertragungsrate
brauchst, dann reichts)
Der Empänger muss eine Checksumme empfangen und prüfen - falls diese
falsch ist Nachricht verwerfen - sonst Ack zurücksenden

Das entspricht meinem Vorschlag, zumal damit für die Aufgabenstellung
mit einer einzigen CRC-Prüfung alle anderen Probleme erschlagen sind.
Also volle Kollision, Überlappung und Verkabelungsfehler.

Trotzdem könnte man das verfeinern. Das Protokoll nach
Ziel-Adr, Quell-Adr, ByteCount, Daten, CRC
aufbauen.
Per einfacher Statemachine in jedem Teilnehmer kann damit ein 'Bus Frei'
einfach detektiert werden:
Ziel-Adr <> eigener Adr? Dann Bytecount rausfischen und mitzählen bis
Telegramm vollständig durch. Dann auf das ACK des Zieles warten und
schon ist der Bus frei. Letzteres mit einem TImeout, falls das Telegramm
ungültig oder zerstört war.

Post by Michael Schöberl
Slotted Aloha: Die Sendestarts werden Synchronisiert - die Nachrichten
überlappen also entweder voll oder garnicht. Dadurch werden rechnerisch
36% möglich..
(die Sync herzustellen ist hier aber wohl mehr Aufwand als der Nutzen)

Das würde aber bedeuten, dass da jemand den Takt vorgeben muss, oder
alle Teilnehmer sich zozusagen in eine Liste eintragen, anhand der sie
ersehen kömnnen, wann sie an der Reihe sind. Wenn man dann auch noch mit
harten Slots arbeitet, dann müssen lange Telegramme auch noch aufgeteilt
werden, was die Software in jedem Teilnehmer ordentlich aufbläst. Denn
der muss ja zum einen speichern, was er noch zu sagen hatte und zum
Anderen auch schon wieder empfangsbereit sein.

Post by Michael Schöberl
weitere Verbesserungen wurden bereits angesprochen
- vor dem Senden horchen ob der Bus frei ist (CSMA)
auch hier ist noch eine Ack-Nachricht zur Rückmeldung nötig und
erneutes verzögertes Senden falls kein Ack kam
man könnte also erst mal Aloha implementieren und dann ein "Sensing
vor dem Senden" nachrüsten ...

Das würde aber bedeuten, dass man mind. die länge eines Bytes + Start
oder Stop abwarten muss um sicher zu gehen, dass da nicht gerade viele
'0'en gesendet werden.

Post by Michael Schöberl
- während dem Senden auf Kollision achten (CSMA/CD) und
ggf Abbrechen+Jam
das stelle ich mir komplizierter vor - gleichzeitig senden und wieder
empfangen? kann man dann überhaupt noch die serielle Schnittstelle im
Atmel verwenden?

Natürlich kann der AVR zeitgleich senden und empfangen. Aber die
normalen RS485 Chips sind unidirektional. Aber wenn man sucht, wird es
da auch einen Chip mit abschaltbarem Sender und immer laufendem
Empfänger geben. Dann kann man das gesendete Byte mit dem Empfangenen
vergleichen und damit eine Kollision direkt erkennen anstatt ersteinmal
alles zu senden und dann auf ein ACK zu warten.

Diese Methode zusammen mit der vorher angesprochenen StateMachine ist
sicherlich die effizienteste Methode. Wenn man dann noch eine Ppriorität
einführt wird das ganze optimal. Gemeint ist, dass man durch das
Mitlauschen der eigenen Sendung erkennen kann, ob man gestört wurde,
oder selber der Störer ist. Wurde man gestört ( vorhergehende Bytes
wurden korrekt übertragen) nimmt man sich eine kurze Wartezeit um einen
weiteren Versuch zu starten. Ist man der Störer ( erstes Byte schon
defekt), dann nimmt man eine mittellange Wartezeit und ist man Lauscher,
der was neues zu sagen hat, dann ist man mit langer Wartezeit am Start,
damit vorher Störer und Gestörter ihre Kommunikation abschließen können.

Das verhindert zudem, dass ein sehr gesprächiges Device alle langsamen
mundtot machen könnte.

Gruß,

Ulrich