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?
Ersetze die RS485 Transceiver durch CAN Transceiver und du kriegst exakt das was du suchst.
>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".
Thread beobachten
Seitenaufteilung abschaltenBitte 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.