Hallo, ich plane ein kleines projekt zur Hauswasser-Anlagen Steuerung. Ich habe mich für den RS485 Bus entschieden. Später soll das Projekt dann erweitert werden. Dabei werde ich zwar eine Haupteinheit haben, aber auch Module, die nicht nur auf Anforderung senden werden. Ich habe mir nun ein kleines Protokoll ausgedacht mit Startbyte Adressen Daten und Checksumme. Ich dachte standardmäßig die Datenrichtung vom MAX485 auf Empfang zu stellen also alle Teilnehmer horchen. Will nun ein Teilnehmer Senden, wird auf Senden geschaltet, das Startbyte geschickt. Durch den Empfang wird Senden bei allen anderen Modulen gesperrt. Was passiert allerdings in der Zeitspanne zwischen dem Umschalten auf Sendebetrieb und dem vollständigen Empfang des ersten Zeichens bei den anderen Teilnehmern. Das dauert ja eine (kurze) Zeit. Wenn nun zufällig ein anderes Modul auch was mitteilen will und auf Senden schaltet kommt es doch zu einer Kollision. Wie fängt man sowas ab? Danke! Gruß Holger
Wenn zwei RS485 Transceiver gleichzeitig senden, ist das Signal auf dem Bus undefiniert. Das kann jeder Transceiver anders verstehen, das kann auch abhängig von seiner Position im Strang sein. Bei Multimaster-RS485 mit RS485-Transceivern besteht die Aufgabe also darin, diesen Zustand von vorneherein zu vermeiden, z.B. mit token passing. Steht RS485 als Protokoll unverrückbar fest, bleibt als Ausweg die Verwendung von CAN-Bus-Transceivern, da diese bei einer Kollision ein klar definiertes Verhalten haben.
Wie wäre es gleich mit CAN?
Das erfordert zwar etwas mehr Hardware (CAN-Controller), dafür muß man
sich aber nicht um Kollisionen auf dem kümmern...
>Wie fängt man sowas ab?
Indem man konstant auf dem Bus mithorcht und seine gesendeten Daten
wieder empfängt. Sowas geht allerdings nur richtig gut mit
CAN-Transceivern, da die besser darauf ausgelegt sind (reine
RS485-Transceiver sind u.U. zu niederohnimg beim Senden).
Wenn die Daten, die man auf den Bus gelegt hat, nicht das gleich
Aussehen haben, wie die, die man empfangen hat, schaltet man zurück auf
Empfang.
Unverrückbar.... sollte gar nix sein. Ich hab nur keine Ahnung von CAN Bus, bin glücklich daß ich in C den AVR so programmieren kann, daß die UART funktioniert und habe mich für den 485 Bus entschieden, weil ich ja dann einfach 'nen MAX485 an die AVR UART klemmen kann und alles ist chic. Muss ich halt doch mal gucken, wie CAN Bus funktioniert.... Danke für die Antworten! Gruß Holger
>Muss ich halt doch mal gucken, wie CAN Bus funktioniert.... Du kannst auch einen PCA82C250 als RS485-Transceiver benutzen und die Sendedaten gleichzeitig empfangen und vergleichen.
Daumenregel: Single-Master => RS485, Multi-Master => CAN. Das ist nicht zwingend, aber seit CAN günstig zu kriegen ist, lohnt sich der Software-Aufwand für Arbitrierung eigentlich nicht mehr. Ist auch eine Sache der Zuverlässigkeit, eine Arbitrierung wirklich zuverlässig hinzukriegen ist nicht trivial. Bei CAN haben andere Leute dieses Problem schon für einen erledigt.
Der entscheidende Kniff bei CAN-Transceivern ist, daß diese beim Senden recht hochohmig auf High (Pullup) und recht niederohmig auf Low (Transistor) ziehen. Dadurch ist der Buspegel bei Kollisionen immer definiert, nämlich Low. Ein CAN-Transceiver schaltet sich ab, wenn er beim High-Senden ein Low zurückliest -> Kollisionsvermeidung.
Wie wär's denn mit LIN. Da kannst du auch deine UART verwenden (mit etwas Modifikation siehe Atmel Applikation Note). Dein Master frägt zyklisch jeden slave ab und du hast immer eine definierte Zeit wie und wann welcher slave was sagen darf. Ich will auch gerade anfangen den Code aus dem App Note auf den Mega32 zu übertragen um mich an einem Hausinstallationsbus zu probieren.
>Nicht der Transceiver sondern der Controller kontrolliert das.
Das Abschalten, aber nicht die Hochohmigkeit (Impedanz müsste das
heissen, oder?) des Busses.
ich stehe auch gerade vor der selben Aufgabe... habe mehrere devices über UART und CAN-Treiber Bausteine verbunden. Habe gerade folgendes gefunden: http://ulan.sourceforge.net/index.php vielleicht auch für dich interessant.
Danke sehr für Eure Antworten! Es kristallisiert sich also raus: UART und Can Bus Treiberbausteine! OK. @Joerg klingt seeeehr interessant. Und das mit meinen miserablen Englischkenntnissen. Werde mal versuchen mich durchzubeißen. Gruß Holger
hi, na na na. wer wird denn da wieder aufgeben wollen in sachen RS485? ich stand vor einem aehnlichen problem rs485 oder can. ich habe mich vorlaeufig klar fuer rs485 entschieden. die hardwarekosten bei rs485 sind ohne bedeutung. lediglich die protokoll-definition ist nicht ganz ohne. das stichwort fuer multi-masterbetrieb lautet csma/cd. das netz ist voll davon mit genauen bechreibungen. das selber zu programmieren ist nicht ganz ohne, macht aber echt spass, wenn es denn laeuft. das ist kein statement gegen can!
CAN ist nur geeignet fuer ultrakuze Meldungen. Was Laengeres zu senden ist eher sehr muehsam damit. B
>CAN ist nur geeignet fuer ultrakuze Meldungen. Was Laengeres zu senden >ist eher sehr muehsam damit. Willst du etwa Video über CAN streamen? Es gibt ja auch schon diverse Protokolle, die auf CAN aufbauen. Sowas sollte sich benutzen lassen.
>Willst du etwa Video über CAN streamen?
Falls ja solltest du auf den MOST Bus aufsetzen. Ein relativ simpler
Baustein ist der OS8104.
Man kann zur Erkennung einer Kollision im Bus einen 1,2 Ohm Widerstand in die Spannungszuführung des RS485 Bausteins hängen. Mit einem Komparator kann man dann erkennen, wieviel Strom der Baustein zieht. Kommt es zu einer Kollision, wird der Baustein der eine 1 senden will höheren Strom ziehen, was den Komparator zuschlagen lässt.
Tag an alle, wollter mal fragen, welche Erfahrungen die Zeit und etwas Experimentieren mit sich gebracht haben.
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.