mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik "Dominante Bits" bei RS485 möglich?


Autor: Manuel C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ersetze die RS485 Transceiver durch CAN Transceiver und du kriegst exakt 
das was du suchst.

Autor: Gast XIV (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Günther Frings (taraquedo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Manuel C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups Ffalscher Thread! Bitte löschen!

Autor: Manuel C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Günther Frings (taraquedo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Manuel C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: H.j.Seifert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Günther Frings (taraquedo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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".

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.