Der Threadtitel ist vermutlich etwas blöde gewählt, aber mir ist keine
bessere Beschreibung eingefallen. Mir fehlen ein bisschen die
Fachbegriffe, daher erkläre ich einfach mal etwas ausführlicher was ich
meine:
Ich habe mir ein paar RS485-Transceiver bestellt, und möchte nun am
Wochenende mal ein bisschen damit herumexperimentieren.
Ich habe schon ein bisschen was über RS485 gelesen, auch dass
Multimaster-Fähigkeit zwar theoretisch durchaus möglich ist - aber
komplexen Protokoll-Aufwand erfordert. U.A. weil man unter allen
Umständen sicherstellen muss dass nicht zwei Geräte gleichzeitig senden,
weil es quasi einen Kurzschluss gäbe wenn das eine Gerät eine logische 0
sendet und das andere eine logische 1.
Da ich mich in der Vergangenheit auch schon mal mit dem I2C-Bus
beschäftigt habe, kam mir irgendwann der Gedanke, ob es denn nicht
möglich wäre einen RS485-Bus so zu beschalten, dass dieses Problem
ähnlich wie bei I2C gelöst wird. Da werden die Busleitungen ja über
einen Pullup-Widerstand standardmässig auf high-Pegel gezogen, und die
an den Bus angeschlossenen Geräte senden ja quasi immer nur 0-Bits,
indem sie die Leitung nach Ground ziehen. Für 1-Bits senden sie einfach
gar nicht. Und wenn zwei Geräte gleichzeitig senden ist das kein
Problem, weil sie dann immer beide das gleiche senden, nämlich eine
logische 0. Die 0-Bits sind auf diese Weise auch noch dominant, was sich
gut für die Busarbitration ausnutzen lässt.
Ginge so etwas ähnliches nicht auch bei RS485? Also ungefähr so: die
eine Signalleitung wird per Pullup standardmässig auf high-Pegel
gezogen, die andere per Pulldown auf low-Pegel, so dass alle
angeschlossenen Geräte wenn gerade niemand sendet immer eine logische 1
auf dem Bus sehen.
Wenn nun ein Gerät sendet, dann immer nur so, dass der Standardzustand
genau umgedreht wird: Die normalerweise per Pullup auf high-Pegel
gezogene Leitung wird vom Transceiver nach Ground gezogen, an der
normalerweise per Pulldown auf low-Pegel gezogenen Leitung hingegen wird
vom Transceiver ein High-Pegel angelegt. Wenn nun zwei Geräte
gleichzeitig senden, so legen sie an beide Leitungen trotzdem das
gleiche Signal an. Der Mikrocontroller selbst schaltet eigentlich immer
nur die Write-Enable-Leitung des Transceivers um.
Ich habe noch nicht so viel Erfahrung von Elektronik und bin mir
ziemlich sicher dass ich irgendwo einen Denkfehler habe, denn ich wäre
garantiert nicht der erste der auf diese Idee kommt. Aber wo ist der
Denkfehler/das Problem?
>Aber wo ist der Denkfehler/das Problem?
Da ist kein Denkfehler. RS485 ist dafür einfach nicht gedacht.
Die Hersteller haben einfach keine Open Collector Treiber eingebaut.
Du kannst dir jederzeit deinen Bus so aufbauen, aber eben nicht mit
Geräten von jedem Hersteller.
Hallo,
komisch. Genau gerade mein Projekt. Also auf CAN-Treibern basierend. Da
kann ich euch vielleicht mal nach Erfahrungswerten fragen:
Wieviel Flash braucht man eigentlich so über den Daumen gepeilt, wenn
man ein einfaches Protokoll in Software mit diesem Treiber implementiert
(nicht CAN, was eigenes, akademisches halt)? Tinys gehen bis 4k Wörter-
ich hoffe das reicht.
An einem Atmel Tiny, der nur das eigene Protokoll machen soll und über
SPI mit dem "Hauptcontroller" spricht, hat man zu wenig IO-Pins.
Ärgerlich. Kann ich den internen RC-Oszillator nutzen? Dann könnte es
gerade gehen. Kann man über den Daumen peilen bei wie vielen
Bits/Sekunde man da landet? Ich meine es müsste eigentlich immer gehen,
wenn man die Geschwindigkeit runter dreht. Kann ich die Leitung mit
R'=6mOhm/m und C'=6mF/m abschätzen? Dann könnte man die Leitungslänge
über die Umschaltzeit bestimmen, weil es in meinem Protokoll kein
"Reinquatschen" á la ACK bei CAN gibt.
Klar, später werde ich mir alles mit dem Oszi anschauen, dann erledigt
sich das rechnen und rumraten ;-)
Grüße!
Danke schon mal für die schnelle Antwort.
Leider beantwortet sie meine eigentliche Frage aber nicht. Ich möchte in
erster Linie einfach verstehen wo mein Denkfehler liegt, für die
Anwendung die ich irgendwann damit umsetzen will ist
Multimaster-Fähigkeit eh unnötig.
Manuel C. schrieb:
> Danke schon mal für die schnelle Antwort.> Leider beantwortet sie meine eigentliche Frage aber nicht. Ich möchte in> erster Linie einfach verstehen wo mein Denkfehler liegt
Die Treiber können keinen dominanten Pegel liefern, das liegt an deren
Innenschaltung.
Dominant ist der Pegel des Treibers, bei dem zuletzt die
Überlastabschaltung anspricht.
Die Überlastabschaltung dient aber nur zum Schutz des Treibers, sollte
also nicht als definierter Betriebszustand auftreten.
Peter
>Wieviel Flash braucht man eigentlich so über den Daumen gepeilt, wenn>man ein einfaches Protokoll in Software mit diesem Treiber implementiert>(nicht CAN, was eigenes, akademisches halt)? Tinys gehen bis 4k Wörter->ich hoffe das reicht.
Ich hoffe für Dich, daß Du auf diese Frage keine Antwort erwartest. Und
wenn doch eine kommen sollte, diese nicht irgendwelche Entscheidungen
von Dir beeinflusst.
Das ist so ne klassiche Glaskugelfrage. Gehts genauer, gibts genauere
Aussagen zum Projekt? Hast Du schon mal so etwas gemacht, dann solltest
Du Erfahrungen darin haben.
Ist der Prozessor zu klein, zu langsam, hat zu wenig IO-Ports: Nimm
einfach einen anderen und quäl Dich nicht mit Beschränkugen rum. 50 Cent
mehr und der Prozessor hat doppelt so viel Speicher, ist doppelt so
schnell, hat mehr IO-Ports. Ist das irgendeine Überlegung wert mit
Resourcen zu sparen?
Vielen Dank an Gast XIV und Peter Danegger, das ist ziemlich genau das
was ich hören wollte!
Habe es zwar noch nicht 100%ig verstanden, aber das liegt einfach nur
daran dass ich noch ein ziemlicher Elektronik-Laie bin. Ich denke wenn
ich nochmal nachlese was "Open Collector" genau bedeutet wird es mir
klarer.
Vielen Dank, ist echt super wie schnell einem hier kompetent geholfen
wird!
Hallo!
kurz schrieb:
>>Wieviel Flash braucht man eigentlich so über den Daumen gepeilt, wenn>>man ein einfaches Protokoll in Software mit diesem Treiber implementiert>>(nicht CAN, was eigenes, akademisches halt)? Tinys gehen bis 4k Wörter->>ich hoffe das reicht.> Ich hoffe für Dich, daß Du auf diese Frage keine Antwort erwartest.
Na nachdem ich das abgeschickt hatte ist mir auch aufgefallen von
wievielen Parametern das abhängt. Stimmt, ist ne doofe Frage. Aber es
könnte ja sein, dass 4k Befehle unter allen Umständen zu wenig sind.
Mich nervt irgendwie, dass ich bei Atmel Controller bis 4k entdecke mit
schön wenig Pins (also klein), dann aber mit etwas mehr Flash gleich
Dutzende Beinchen mehr dran sind. So ein Zwischending zwischen Mega und
Tiny sehe ich gar nicht.
Aber meine Überlegung zum RC-Oszillator war hoffentlich in soweit
richtig, als das es immer geht. Halt entsprechend langsam.
Grüße!
P.S.: Gibt es hier eine Hierarchie im Thread? Warum denn der falsche?
Eben ist mir noch eine Frage eingefallen:
Wäre es eigentlich theoretisch möglich, einen differentiellen Busses
ähnlich RS485 so aufzubauen, dass direkt an den Bus angeschlossene AVRs
selbst als Transceiver arbeiten? Wenn ich diese RS485-Transceiver-ICs
richtig verstehe, ist der Empfangsteil ja nicht weiter als ein
Komparator, und so etwas hat soweit ich weiss doch auch (fast?) jeder
AVR.
Nun habe ich noch nie gehört habe dass so etwas mal gemacht wurde. Gehe
ich Recht in der Annahme, dass das aus ähnlichen Gründen wie weiter oben
nicht klappt, dass also die I/O-Pins des AVRs wegen ihrer interenen
Funktionsweise (Open Collector o.Ä.) nicht als Bustreiber geeignet sind?
Das willst du nicht wirklich...
Leitungstreiber haben einige Eigenschaften, die man dafür auch braucht,
zumindest bei nennenswerten Leitungslängen.
Prinzipiell sollte es aber gehen, da die Pinstruktur der AVRs recht
flexibel ist, praktisch aber eher nicht.
Hi!
Also man hat in der Anfangszeit von CAN die Transceiver diskret
aufgebaut. Aber das ist wirklich etwas mehr als nur ein Op, denn du
musst ja auch noch Störungen filtern, Eingangsimpedanzen einhalten,
Transienten abwehren usw. Könnte mir vorstellen, dass man da ein paar
Dutzend Bauteile braucht und auch Platz verschwendet. Wenn du dich noch
nicht so mit Elektrotechnik auskennst, dann würde ich dir es erst etwas
einfacher vorschlagen*. Sonst wirst du den Spaß am Basteln schnell
verlieren...
Grüße!
* Es sei denn man findet so eine Bauanleitung fertig, dann ist es
natürlich ein gutes Studienobjekt
@peda
>Die Treiber können keinen dominanten Pegel liefern, das liegt an deren
Innenschaltung.
Die Treiber können NUR dominante Pegel liefern - oder hochohmig sein!
Diese Hochohmigkeit kann man als rezessiven Pegel missbrauchen, indem
bei Nichtaktivität aller Sender ein H-Pegel zurückgelesen wird. Bei der
Busanforderung muss man dann nur zwischen aktiv L-Pegel und hochohmig
H-Pegel schalten. So wird bei der Zugriffsverhandlung nie H gegen L
"kämpfen" sondern nur dominant L gegen L. Dazu braucht man einen
geeigneten Algorithmus. Wenn dann klar ist, wer als Master senden darf,
kann man auch mit beiden dominanten Pegeln weiter machen.
Ich habe sowas für meinen Hausbus realisiert; und wenns um Codegröße
geht: 1 Atmel 89C2051 mit 2 Kilobyte macht das allein, aber gleichzeitig
noch DCF-77 Zentraluhr und DS1820 als Außentemperatursensor. In jeder
vollen Minute wird neben der Uhrzeit die Temperatur und zur vollen
Stunde noch das Datum als Broadcast an alle gesandt. 57,6 KBaud.
Assembler.
Fairerweise muss ich sagen, ich habe zwischenzeitlich die RS485 Treiber
durch CAN-Treiber ersetzt, bei gleichem Protokoll, weil ich den IO-Pin
für die Tristate-Schalterei brauchte.
Hallo,
die Verwendung von Open Collector Treibern hat natürlich auch
wesentliche Nachteile: sie schalten Low-High wesentlich langsamer als
Totem Pole Treiber, und das noch in starker Abhängigkeit von der
Kabellänge bzw. Kapazität. Will man die Schaltgeschwindigkeit erhöhen,
landet man bei irre hohem Stromverbrauch.
OC-Treiber sind daher für Leitungen mit definierte Impedanz und
überhaupt für hohe Geschwindigkeiten ungeignet. RS485 hat also durchaus
eine Daseinsberechtigung.
Gruss Reinhard
@Reinhard
Das hatte ich auch bemerkt. Deshalb (und auch aus anderem Grund) ist die
Busanforderungsphase bei mir ca. 10 mal langsamer als die eigentliche
Datenübertragung bei 57,6 Kbit/s.
Ich hatte noch vergessen: 2*16 LC-Display und externer Watchdog ist auch
noch dabei. Momentan genau 1733 Byte - ohne Optimierung, es ist also
noch "Luft".
