Moin, ich benutze einen MAX485 und habe mir am Oszi mal die Leitungen angesehen. Auf der RO-Leitung habe ich ein exaktes Echo von der DI-Leitung. Ich finde dazu nichts im Datenblatt, habe aber eine Ahnung, woran das liegt: Sobald der MAX485 Input von der USART-Seite bekommt, liegt auf dem differentiellen RS485-Paar das entsprechende umgewandelte Signal an. Da nun dort wiederum ein Signal anliegt, macht der MAX485 das, wofür er da ist und wandelt diese Daten um auf USART-Pegel, die eben auf die RO-Leitung gehen. Wenn ich dieses Echo nicht haben möchte, bleibt mir nur, das per Softare zu ignorieren oder die Senderleitung mit !RE! vorübergehend zu deaktivieren. Sehe ich das richtig so? Grüße Peter
wenn Empfänger und Sender gleichzeitig aktiv sind (RE und TE), dann passt das so.
Richtig. Einfach DE und /RE verbinden und zwischen Senden und Empfangen umschalten.
Peder schrieb: > Wenn ich dieses Echo nicht haben möchte, bleibt mir > nur, das per Softare zu ignorieren oder die Senderleitung mit !RE! > vorübergehend zu deaktivieren. Ja. Und wenn Du Pin 2 und 3 verbindest, erreichst Du letzteres, beim Senden geht der Receiver aus. In dem Fall unbedingt RO mit einem Pullup versehen, bei abgeschaltetem Receiver ist der hochohmig, so dass Du ansonsten Müll empfangen kannst.
Danke, das ging schnell! Die beiden Pins zu verbinden, ist irgendwie offensichtlich, wenn man erstmal darauf gestoßen wird. Gesehen hab ich die Option aber tatsächlich nicht... Also noch mal danke!
Ist aber gar nicht so schlecht das Echo zu empfangen. Man weiss ja was man gesendet hat und kann damit vergleichen ob es zu Kollisionen kam. Programmieraufwand gering, Nutzen u.U. gross. Schädlich praktisch nie.
H.Joachim S. schrieb: > Ist aber gar nicht so schlecht das Echo zu empfangen. Man weiss ja was > man gesendet hat und kann damit vergleichen ob es zu Kollisionen kam. > Programmieraufwand gering, Nutzen u.U. gross. Schädlich praktisch nie. Beim CAN wird doch genau das verwendet. Wobei RS485-Ausgänge u.U. zu niederohmig sind, eine Kollision "überreden" und so nicht merken, dass eine vorliegt.
Rahul D. schrieb: > Beim CAN wird doch genau das verwendet Nicht ganz. Bei CAN wird die Kollision on the fly aktiv verhindert. Bei RS485 kannst du höchstens nachträglich eine Kollision feststellen.
H.Joachim S. schrieb: > Man weiss ja was man gesendet hat und kann damit vergleichen ob es zu > Kollisionen kam. Unsinn, eine sichere Kollisionserkennung ist mit RS-485 nicht garantiert. Bei RS-485 entstehen bei mehreren aktiven, gegeneinander treibenden Sendern auf Grund der Push-Pull Ausgangsstufen undefinierte Pegel, d.h. eine Kollisionserkennung ist ein Glücksspiel. Rahul D. schrieb: > Beim CAN wird doch genau das verwendet. Um dies zu ermöglichen, verwendet CAN ganz andere Bustreiber mit Open-Drain Ausgang. Bei CAN gewinnt daher immer der dominante Pegel, d.h. auch bei einer Kollision sind saubere Pegel garantiert.
Rainer W. schrieb: > Bei CAN gewinnt daher immer der dominante Pegel, d.h. auch bei einer > Kollision sind saubere Pegel garantiert. Der Controller mit dem recessive-Bit ist dann aber auch still, wenn er die Kollision erkannt hat. Die Kollision wird bei RS485 eben nicht unbedingt erkannt. Da "redet" der Controller dann vielleicht doch noch weiter.
:
Bearbeitet durch User
Rainer W. schrieb: > Unsinn, eine sichere Kollisionserkennung ist mit RS-485 nicht > garantiert. Eine, die mit der von CAN vergleichbar ist, nicht, aber das simple Verfahren, das Sendeecho auszuwerten, hilft definitiv viel mehr als "senden und vergessen". Nicht jeder Kollisionsfall ist so komplex, daß gleich mehrere Geräte gleichzeitig lossabbeln, und selbst dann dürfte das Sendeecho meistens eines sein: Kaputt.
Rahul D. schrieb: > Der Controller mit dem recessive-Bit ist dann aber auch still, wenn er > die Kollision erkannt hat. Das hat aber nichts mit dem grundsätzlichen Unterschied in der Bitübertragung (physikalisch Schicht) zu tun, sondern ist bereits Bestandteil einer höheren Schicht im OSI Modell (Transport). Harald K. schrieb: > ... hilft definitiv viel mehr als "senden und vergessen" Sagen wir mal so, je nach verwendeten Treibern besteht die Möglichkeit, dass Kollisionen erkennbar sind, aber das ist alles andere als sicher, weil dabei irgendwelche Zwischenpegel auftreten können. > Nicht jeder Kollisionsfall ist so komplex, daß gleich mehrere Geräte > gleichzeitig lossabbeln Was soll das für ein Kollisionsfall sein, bei dem nicht mehrere Geräte senden? Wenn nur eins sendet, gibt es keine Kollision ;-)
:
Bearbeitet durch User
Rainer W. schrieb: > Das hat aber nichts mit dem grundsätzlichen Unterschied in der > Bitübertragung (physikalisch Schicht) zu tun, sondern ist bereits > Bestandteil einer höheren Schicht im OSI Modell (Transport). Und wie ist das bei einer RS485-Übertragung? Der Sender, der die Kollision erkennt, stellt den Sendebetrieb doch auch ein ==> gleicher Vorgang, oder? Natürlich kann ein CAN-Controller auch einfach weiter sabbeln. Da setzt sich dann immer das dominante Bit durch - bis nur noch das auf dem Bus liegt, und alle Controller das Senden einstellen.
Rahul D. schrieb: > Und wie ist das bei einer RS485-Übertragung? > Der Sender, der die Kollision erkennt, stellt den Sendebetrieb doch auch > ein ==> gleicher Vorgang, oder? Da bei RS-485 eine Kollision wegen den möglicherwiese auftretenden Zwischenpegeln nicht sicher erkennbar ist, ist es eben nicht der gleiche Vorgang. Bei CAN erfolgt die Kollisionsauflösung außerdem noch innerhalb des Bit, bei RS-485 wäre das frühestens nach dem Stop-Bit des kollidierenden Zeichens möglich. > Natürlich kann ein CAN-Controller auch einfach weiter sabbeln. Nein, bei CAN wird darüber während der Arbitrierung die Nachrichtenpriorisierung sicher gestellt. Der Controller hat dafür zu sorgen, dass der Sender mit der niedriger priorisierten Nachricht nach einer Kollisionserkennung sofort (noch innerhalb des Bits) die Schnauze hält. Falls es zu einer Kollision von Data Frame und Remote Frame kommt, hat der Data Frame Priorität. Bei CAN passiert die Kollisionshandhabung ohne Datenverlust, d.h. die priorisierte Nachricht kommt heil durch.
:
Bearbeitet durch User
Rainer W. schrieb: > Was soll das für ein Kollisionsfall sein, bei dem nicht mehrere Geräte > senden? n > 2, ich hätte gedacht, daß das irgendwi klar ist. Die Erfahrung (die manch einer macht) zeigt, daß eine Kollision das zu empfangende Echo oft ausreichend weit stört, daß sie erkannt wird. Undefinierte Pegel sind ja schon mal ein Anfang - wenn eine UART bei undefinierten Pegel am Eingang des RS485-Transceivers weder Parity- noch Framing-Fehler feststellt und die Daten den gesendeten entsprechen, dann sind die Pegel vielleich doch nicht so undefiniert.
Wenn man das Datensignal invertiert an den Driver-Enable Anschluss legt, kann man auf dem Bus mit RS485-Treibern auch mit dominanten und rezessiven Pegeln arbeiten. Dann gibt es auch keine "Zwischenpegel". Und der, der rezessiven Pegel senden möchte, kann erkennen, dass gerade dominant auf dem Bus ist und seine Sendung einstellen. Gruß Jobst
Jobst M. schrieb: > Und der, der rezessiven Pegel senden möchte, kann erkennen, dass > gerade dominant auf dem Bus ist und seine Sendung einstellen. Man müsste die Ausgabe per Bit-Banging machen. Ein UART ist nicht in der Lage, während der Zeichenübertragung einzugreifen und auf den Zustand einzelner Bits zu reagieren. Bei Konflikten kann man nur im Nachhinein erkennen, dass Bits gestört wurden, aber die Übertragung wird korrumpierte, ganz im Gegensatz zu CAN, wo die höher priorisierte Nachricht heil durch kommt.
Rainer W. schrieb: > Man müsste die Ausgabe per Bit-Banging machen. Oder man spendiert der Schaltung ein EXOR, welches einen IRQ auslöst, worauf hin die UART abgeschaltet wird. Das geht auch mitten in der Übertragung. Gruß Jobst
Jobst M. schrieb: > Oder man spendiert der Schaltung ein EXOR, Du meinst an DI und RO? Das wird wohl bei jedem Pegelwechsel ein Signal erzeugen aufgrund der Verzögerungszeiten.
H.Joachim S. schrieb: > Jobst M. schrieb: >> Oder man spendiert der Schaltung ein EXOR, > > Du meinst an DI und RO? Das wird wohl bei jedem Pegelwechsel ein Signal > erzeugen aufgrund der Verzögerungszeiten. Filtern? Es gibt keinen Grund zur Eile! Gruß Jobst
Also bisschen mehr als nur ein EXOR :-)
:
Bearbeitet durch User
H.Joachim S. schrieb: > Schädlich praktisch nie. Entweder Du opferst einen Großteil der Übertragungsleistung oder es ist nur eine Diagnose ohne Anspruch auf Wirkung. Bei 485 sollte Dein lokales Signal stärker sein, als externe Störer. Oder Du definierst 3 (oder mehr) statt 2 Pegel. Bei CAN ist die Übertragungsleistung (in m*kBaud/Ader) viel zu gering, um für irgendwas anderes verwendet zu werden. Bei Ethernet hat man zwar 30 Jahre gebraucht, ist aber lange weg von jeglicher gemeinsamer Leitung (CSMA). Egal, was Du Dir an schlauen Reaktionen überlegst, es ist auf höheren Ebenen besser angesiedelt.
Angehängte Dateien:
Peder schrieb: > ich benutze einen MAX485 und habe mir am Oszi mal die Leitungen > angesehen. Auf der RO-Leitung habe ich ein exaktes Echo von der > DI-Leitung. Ich finde dazu nichts im Datenblatt, Das steht schon im Datenblatt. Einfach mal die Bilder anschauen :)
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.