Hallo Leute, Ich möchte ein Bussystem mit 3-4 Devices aufbauen. Diese sollten im Multi-Master Betrieb miteinander plaudern. Hat da jemand schon Erfahrung damit? Die Infos über Single-Master habe ich schon gelesen. Konkret geht es darum, Kollisionen auf dem Bus zu vermeiden. Verwenden werde ich MEGA103 oder MEGA161. ich bin für jeden hinweis dankbar!!! Thomas
Ich verwende für so etwas das CAN. Prinzipiell kann man das auch über RS485 laufen lassen, wenngleich das auch wenig Vorteile bietet.
Jochen hat recht. Der RS-485 ist ein reiner Single-Master-Bus, d.h. er hat keinerlei Arbitrierungsmöglichkeiten. Man kann das nur simulieren, indem man ein Token kreisen läßt und solange einer das Token hat ist er der Master. Kollisionen sind absolut zu vermeiden, da je nach Stärke der Leitungstreiber und Größe des Leitungswiderstandes die beiden kollidierenden Master die Kollision nicht mal bemerken müssen. Erst, wenn ein Leitungstreiber wegen Überhitzung abschaltet, merkt dessen Master das. Der CAN-Bus dagegen erlaubt eine sehr komfortable Arbitrierung in der Weise, daß Kollisionen erkannt und behoben werden, d.h. ein Master gewinnt und kann seine Daten unzerstört weitersenden. Der andere löst danach automatisch ein Retry aus, ohne das Du das extra per Software starten must. Zusätzlich übernimmt die CAN-Hardware die Fehlererkennung und CRC-Erzeugung. Die Software ist also im Vergleich zu RS-485 popeleinfach, da Du Dich um keinerlei Protokollquatsch kümmern must. Das macht ja alles die Hardware. Ich nehme gern den Atmel T89C51CC01 mit internem CAN und wahlweise über RS-232 oder CAN-Bootloader programmierbar. Als separater CAN-Controller wird gern der SJA1000 genommen, der dann wie externer Speicher angeschlossen wird (hat aber schon das nötige Adreßlatch intern). Peter
hallo zusammen, besten dank für die infos. ich habe beschlosse, da timing kein thema ist und ich den aufwand so nieder als möglich halten will, daß ich rs485 nehme und im polling-betrieb die slaves abfrage. ich bau da so eine steuerung für mein wohnmobil, dort kommt das zeug's hinein. besten dank nochmals, thomas
Hallo Thomas, Einen richtigen Multimaster-Bus wist Du wie ja schon geschrieben nicht mit der RS485 hinbekommen. Falls es dir darauf ankommen sollte, das einer der "Slaves" etwas sagen können sollte, dann überwache einfach die Signale auf dem Bus(natürlich bei jedem Controller). Wenn eine bestimte Zeitspanne (längste mögliche Kommunikationssequenz) nichts auf dem Bus passiert, dann kann der Controller senden. Evtl. (was bei 4 Controllern theorethisch fast ausgeschlossen werden kann) doch zwei gleichzeitig gesendet haben, dann gibt es kein ACK vom aktuellen Host, da Datenmüll angekommen ist. Also neuer Versuch. --> nochmal von vorn. MfG Steffen
hallo steffen, danke für die info. so was ähnliches ist mir auch schon durch den kopf gegangen. mir ist nur unklar, was passiert, wenn zwei gleichzeitg senden. wenn einer hi der andere lo sendet, dann haben wir ja einen feinen kurzschluß am bus, oder? daß die paar controller gleichzeitig senden ist wirklich unwahrscheinlich, jedoch möchte ich nicht nächstes jahr am nordkap stehen, und die wasserpumpe läßt sich nicht mehr einschalten ... ich will nämlich so ziemlich alles über die controller steuern und schalten, damit ich sowas wie laufzeitbeschränkung der pumpe oder "Licht vergessen" ausschließen kann. gruß, thomas
Ich würde das Ganze als 4-Draht verdrahten, d.h. der Master-TX geht an alle Slave-RX. Damit kann der Master immer was sagen und die Slaves aber nur, wenn sie vorher adressiert wurden. Und eine Fehlersicherung (CRC) solltest Du auf alle Fälle machen. Peter
Also soweit ich weiß, ist RS485 ja nur die Spezifikation. Ein Profibus kann z.B. als multimaster-system laufen und benutzt die rs485 spezifikation! MfG
> was passiert, wenn zwei gleichzeitg senden. wenn einer hi der andere lo sendet, dann haben wir ja einen feinen kurzschluß am bus, oder? Genau, und deswegen nimmt man Bustreiber, die damit umgehen können. CAN-Bustreiber können sowas, z.B. PCA82C250 (1,85EUR @Reichelt). Da du ja zurücklesen kannst, was du gerade schreibst, erkennst du auch wenn ein anderer Busteilnehmer einen anderen Pegel anlegt. Achso, es gibt 2 Buspegel (dominant und rezessiv...). Dominant "überstimmt" immer den rezessiven Pegel -> elektrisch passiert dabei nix schlimmes... Aber das lies dir besser in irgendwelchen CAN-Spezifikationen/Webseiten durch. Zu aufwendig mit dem Rücklesen? Dann Peters Vorschlag mit 4 Adern verwenden. Oder gleich einen µC mit integriertem CAN-Interface nehmen. Schmittchen.
CAN lässt sich übrigens auch mit AVR-Controller ohne CAN Vorrichtung realisieren. http://caraca.sourceforge.net/ Theo
@Theo Runner: Was ist denn eine CAN Vorrichtung? Weiterer Link: http://www.canathome.de/ @Schmittchen: Besser den PCA82C251 nehmen, den empfiehlt Philips auch selber, da er ein paar entscheidende Vorteile hat: geringerer Stromverbrauch, verkraftet grössere Transienten, kann grössere Lasten treiben, etc.
Wow ! Das müssen ja zig-tausende Zeilen an Code sein und das nur um etwas Hardware 100-mal langsamer in Software nachzubilden. Ob das wirklich alles richtig funktioniert ? Erinnert mich irgendwie an alte Zeiten, wo Leute nur so zum Spaß eine Digitaluhr ausschließlich aus hunderten von 7400-Gattern aufgebaut hatten. So genau hab ich mich nie mit den CAN-Internas beschäftigt. Ich weiß nur, wie ich die Baudrate einstelle, wo ich die Sendedaten reinschreiben muß und wo ich die Empfangsdaten auslesen kann. Der T89C51CC01 hat auch noch einen kleinen Bruder, den T89C51CC02 (PLCC-28, SOIC-24 Gehäuse). Die Idee von Schmittchen, statt RS-485 die CAN-Treiber an seine UART ranzuhängen ist auch super. Man spart sich die Transmit-Enable-Steuerung und im Fehlerfall kommt es nicht zu unzulässig hohen Strömen. Peter
Das zwei Controller gleichzeitig senden ist ausgeschlossen, da sie nur antworten, wenn sie gefragt werden. Ein RS485-Treiber nimmt es einem auch nicht krumm, wenn mal ausversehen zwei Controller senden. MfG Steffen
jetzt hab ich doch zwei Fragen verwechselt. Den ersten Satz aus meiner letzten Antwort könnt Ihr streichen. MfG Steffen
> Den ersten Satz aus meiner letzten Antwort könnt Ihr streichen.
Den zweiten Satz nicht? ;)
Wenn 2 RS485-Treiber senden, ist nicht definiert, welchen Pegel andere
Teilnehmer einlesen. Bei CAN ist das definiert. Elektrisch geht
vielleicht/wahrscheinlich nix kaputt, aber sauber ist das nicht.
Kleine Spitzfindigkeit am Rande:
"Aus Versehen" senden gibs nicht - eher senden zwei Teilnehmer
"zufällig" gleichzeitig. Aber da man das ja weiss bzw. so implementiert,
kann/muß man darauf Rücksicht nehmen.
Schmittchen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.