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.

Nicht der Transceiver sondern der Controller kontrolliert das.

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

Entschuldigung!

@Rainer: Auch LIN werde ich mir anschauen.

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.