CSMA/CD oder Token bei RS485

Hallo zusammen,

ich bin gerade im Anfangsstadium eines kleines Projekts. Es geht um ein Bussystem (phyiskalisch: RS845) f=FCr 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=FCrlich die Frage, wie regele ich den Multimaster-Buszugriff. P-NET basiert auf einen Token (Virtuell kein Tokenaustausch =FCber 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=E4ngeradresse, CRS und ACK nutze, gar nicht erkennen? Die Buslast ist =E4u=DFerst gering! =

Vielen Danke schon mal im voraus!

Gru=DF J=FCrgen

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

Reply to
=?iso-8859-1?Q?J=FCrgen?= Leeb
Loading thread data ...

Jürgen Leeb schrieb:

Also geringe Buslast und keine Echtzeitfähigkeit notwendig.

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.

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

Reply to
Holger Blum

"Holger Blum" schrieb

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

Reply to
Marc Keller

Danke f=FCr Deine Antwort!

in

Ja, so ist es.

Ja dachte daran das Protokoll in etwa so aufzubauen: Empf=E4ngerADR, QuellADR, Protokolltyp, Daten, CRC; Der Empf=E4nger muss dann auch ein ACK-Protokoll zur=FCckschicken.

ring.

r

gung.

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=E4tzlichen Schaltungsaufwand? Oder gibt es spezielle Treiberbausteine?

- Ich denke gerade an I2C. Hier ist das mit dem Multimaster so geregelt, da=DF das 1 Signal vorrang hat. D.h. fangen zwei Master an zu senden (Vorher der Bus auf Leerlauf gepr=FCft), dann sind die Daten solange g=FCltig, 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=FCr 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=F6glich?

- Brauche ich =FCberhaupt ein Collision Detection? Reicht es nicht aus, da=DF der Master ein Telegramm schickt und auf ein Ack. vom Empf=E4nger wartet. Erh=E4lt er es, so ist alles O.K.. Wenn nicht war etwas falsch. Vielleicht gab es eine Kollision. Auf alle F=E4lle wartet er eine gewisse=

Zeit und probiert es dann erneut.

Reply to
=?iso-8859-1?Q?J=FCrgen?= Leeb

Hallo Marc

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=FCr Ethernet. Es gibt auch andere Bussystem, die mit RS485 arbeiten (s. LON);

Reply to
=?iso-8859-1?Q?J=FCrgen?= Leeb

Jürgen Leeb schrieb:

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...

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.

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

Reply to
Holger Blum

Hallo Jürgen!

Schön Dich wieder zu sehen :-)

Jürgen Leeb wrote:

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.

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.

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 :-)

Reply to
Ulrich Prinz

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

Reply to
=?iso-8859-1?Q?Michael_Sch=F6b

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.

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.

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.

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

Reply to
Ulrich Prinz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.