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