Hallo,
ich spiele z.Z. mit einem Waveshare ESP32-S3-Touch-LCD-7 herum. Grafik und Co funktioniert auch so weit (Lvgl).
Aber wenn ich den RS485 Eingang des Board verwende kann ich nur vom PC zum Board senden. Board zu PC funktioniert nicht. (Hängt natürlich ein USB-RS485 Adapter dazwischen).
Aber wenn ich den RS485 Eingang des Board verwende kann ich nur vom PC
zum Board senden. Board zu PC funktioniert nicht.
Solange DI fest auf low liegt, kann das Board auch nichts über RS485 senden.
Solche Kästchensymbole wie für den SP3485EN sind zwar schnell und bequem anzulegen, haben aber in einem Schaltplan den ganz entscheidenden Nachteil, dass sich nichts über die Funktion verraten. Die Arbeit, die man einmal beim Anlegen des Symbols spart, steckt man mehrfach beim Debuggen von Schaltungen wieder rein. Ohne Datenblatt ist der Schaltplan unlesbar.
Deshalb frage ich ja ob es da einen Trick gibt. Die werden ja nicht Boards produzieren, einen Treiber drauf setzen, einen Stecker drauf und keine Funktion testen.
Trick wofür?
Guck dir wenigstens die erste Seite des Datenblattes an. Dort ist in vernünftigen Symbolen dargestellt, wie alles funktionell zusammen hängt. Senden auf den Bus geht nur über DI und das Signal ist in deinem Plan oben auf Gnd gelegt - nix senden.
Senden auf den Bus geht nur über DI und das Signal ist in deinem Plan
oben auf Gnd gelegt - nix senden.
Es sei denn sie machen das Senden über die Richtungsumschaltung 🤮
Mich irritiert auch etwas, dass man den RO (Receiver Output) Pin des RS485 Treiber mit RS485_TXD bezeichnet.
Das müsste doch eigentlich der RX Pin des ESP32 sein...
Es sei denn sie machen das Senden über die Richtungsumschaltung 🤮
Dann müsste der ESP RS485_RXD auch bidirektional benutzen. Getrennte Signal über RS485_RX_PIN und RS485_TX_PIN geht mit dem Board jedenfalls nicht, ohne einen Lötkolben zu bemühen.
Wenn man sich übrigens das DB des ESP32-S3-Wroom-1 anschaut gibt es auf IO15 nur U0RTS und auf IO16 nur U0CTS.
Wie das mit RX/TX laufen soll erschließt sich mir auch nicht ganz.
@Holger: Hast du Mal das RS485 Example das im Wiki zu dem Board hinterlegt ist ausprobiert?
Definiere Mal folgendes:
RS485_TXD(IO15) als Input und als RX Pin für deine UART.
RS485_RXD(IO16) als Output und als TX Pin für deine UART.
Als erstes wäre es nicht schlecht, einen Schaltplan zu haben, aus dem hervor geht, was als Signal nach außen zur Verfügung steht. An RO sehe ich nur einen Pull-Up (R74) und sonst keine weiteren Verbindungen.
Auf den IO16 hab ich in einer Schleife 0xAA geschrieben. Wo da was toggeled hab ich nicht verfolgt. Am DI jedenfalls nicht und am RS485 Stecker auch nicht.
Senden auf den Bus geht nur über DI und das Signal ist in deinem Plan
oben auf Gnd gelegt - nix senden.
DI auf Ground IST zum Senden des dominanten Pegels richtig. Wenn gleichzeitig das DriverEnable high ist. Und das machen sie, indem sie das DE mit dem invertierten Sendesignal vom Controller speisen. Der Controller sendet low-aktiv, passt also perfekt.
Ich würde mal beim Senden mit dem Oszi auf den Controllerausgang, die Basis und der Kollektor vom Transistor und DE schaun, da müssen die Daten ankommen. Wenn der IC dann noch Spannung hat und trotzdem auf A und B nix rauskommt, ist der kaputt. Oder AB Kurzschluß.
Nein, am Controller bleibt der serielle Ausgang immer der serielle Ausgang, und speist den Basiswiderstand. Und der RO vom Treiber liefert an den seriellen Eingang des Controllers, der immer serieller Eingang bleibt. Heißt: der Controller muss bei der gezeigten Schaltung keine Richtungsumschaltung machen.
Nichts desto trotz gibt es die Richtungsumschaltung im Treiber, weil er nur entweder senden oder empfangen kann. Diese löst die Schaltung elegant indem das serielle Sendesignal die Richtungsumschaltung bedient und gleichzeitig das Sendesignal (DI) dauerhaft aktiv (Ground) ist.
Wenn man von der "Kleinigkeit" absieht, dass bei High-Pegel keine standardkonformen 200mV Differenz da sind, sondern nur 15mV bei beidseitiger 120-Ohm-Terminierung.
Die steigenden Flanken dürften so auch ziemlich rundgelutscht aussehen.
Aber immerhin haben sie RO einen Pullup spendiert, der wird bei gemeinsam geschalteten !RE und DE gerne vergessen.
Ooops, RS485 ist nicht CAN. Heißt, bei RS485 sollte der Transmitter sowohl bei Mark als auch bei Space eine Differenzspannung auf die Leitungen treiben. Die Auswerteschwelle des Empfängers ist ca. Null. Die Schaltung kann aber nur Space senden, und verlässt sich für Mark auf die externen Biaswiderstände. Sind die zu hochohmig im Vergleich zum Parallelwiderstand, oder auch im Vergleich zur Leitungskapazität, kommt beim Empfänger das Mark nicht sicher an. Wikipedia zeigt 720 ohm Biaswiderstände. https://de.m.wikipedia.org/wiki/EIA-485
Die Labels RX und TX sind wirr. Ich lass sie daher weg bei der Beschreibung. Normalerweise wäre TX die Transmitleitung vom Controller, also dort wo er Daten sendet. Diese muss an den Basiswiderstand. Im Ruhefall, wenn der Controller nichts sendet, ist die high. Die Basis daher auf 0.7V, der Transistor leitend, Kollektor auf 0V, DriverEnable also Low und Receiver eingeschaltet. Also leitet der Receiver die Daten von A/B an den RO weiter. Im Ruhezustand (PC ist still) ist RO high, und da er direkt mit dem seriellen Eingang des Controllers verbunden ist, der in Ruhe high erwartet, empfängt der Controller das, was der PC sendet (zB Stille).
Der serielle Eingang des Controllers würde normalerweise RX heißen, also RO direkt mit RX verbunden.
DI auf Ground IST zum Senden des dominanten Pegels richtig.
Nur fehlt es am Senden eines vernünftigen High Pegels.
Um zu klären, was dort tatsächlich mit dem anderen Pegel passiert, wenn der nur durch Abschalten des Sendertreibers generiert wird, würde ich als erstes gleichzeitig mit einem Oszi auf die Pegel auf dem Bus gucken.
Wer weiß, wie die kapazitive Belastung auf dem Bus ist und mit welcher Geschwindigkeit die Signale über den Bus laufen sollen. Ein Versuch zum Eingrenzen des Problems könnte es sein, die Übertragungsgeschwindigkeit einmal kräftig zu reduzieren.
Nimm dein RS485-Board, lege statische Pegel an die Eingänge an und miss mit dem Multimeter/Oszi was passiert. Ob ein Pegel aktiv durch den Bus-Treiber erzeugt wird oder durch die (hochohmigen) Widerstände, siehst du, wenn du die Busleitungen bspw. mit 2,2 kΩ belastest.
Für das Verständnis hilft es sicher auch, einmal einen vernünftigen Schaltplan zu zeichnen, aus dem man den Signalfluss erkennt kann, d.h. wo der Signalweg nicht (nur) über wild eingestreute Labels definiert wird und wo vielleicht zusätzlich die Datenrichtung für RX/TX gekennzeichnet ist, auch wenn sie sich aus der Pin-Zuordnung zu S1 und U6 ergibt.
Meine Vermutung war sie senden über die Richtungsumschaltung, also !RE
und DE.
Selbst das haben sie aber durch die viel zu grossen Bias-Widerstände
verbockt, die dann den High-Pegel liefern müssten.
Richtig. Sie senden mittels der Richtungsumschaltung. Das funktioniert nur, wenn irgendwo im Netzwerk Biaswiderstände sind (je 720 Ohm laut Wikipedia). Weil mit den vorhandenen 10k der Mark-Zustand nicht sicher erreicht wird.
Also für den TO: Besorge zwei Widerstände (im Bereich 470ohm bis 1k) und schalte die parallel zu den vorhandenen 10k Widerständen an A/B.
DI auf Ground IST zum Senden des dominanten Pegels richtig. Wenn
gleichzeitig das DriverEnable high ist. Und das machen sie, indem sie
das DE mit dem invertierten Sendesignal vom Controller speisen. Der
Controller sendet low-aktiv, passt also perfekt.
Nein, natürlich nicht.
Es würde (schlecht, nur langsam) funktionieren, wenn die RS485 Differentialleitung durch die pull up pull down auf den rezessiven Pegel gezogen werden würde, das klappt aber auf Grund der Niederohmigkeit der Abschlusswiderstände nicht.
Es ist einfach Schwachsinnig, wegen mangelndem Richtungssignal den Treiber bei rezessivem Sendepegel zu disabeln, kommt aber in China öfter vor und wie man sieht sind auch Deutsche davor nicht gefeit.
Nutze Treiber mit Richtungssignal (extra Sende-Enable).
Es ist einfach Schwachsinnig, wegen mangelndem Richtungssignal den
Treiber bei rezessivem Sendepegel zu disabeln
Ich hab die Schaltung nicht gemacht, ich versuch sie nur zu interpretieren :-) und ich nehm gern die Argumente beider Ansichten auf.
Das "originale" RS485 braucht die explizite Richtungsumschaltung, weil man damit hunderte Meter, schnell und in "lauter" Umgebung stabil überbrücken will. Daher treibt der Sender sowohl Mark als auch Space. Das macht absolut Sinn. Leider braucht es einen Pin mehr am Controller, und eine Treibersoftware, die Richtungsumschaltung beherrscht. Ist kein Hexenwerk, und wäre die saubere Lösung.
Die Billiglösung ist: Man sendet aktiv nur Space, und verlässt sich für Mark auf das Biasnetzwerk. Vorteile: Einfachere Software, ein Pin weniger am Controller. Nachteil: Es läuft nicht auf Anhieb (siehe Eingangspost), weil es nicht klar ist, dass das Bias-Netzwerk ein wesentliches Element des Designs ist. Und es läuft nicht bei langen Kabeln, weil die Flanken mit steigender Länge (=Kapazität) immer schlechter werden. Und es läuft nicht mit hohen Baudraten, weil diese steile Flanken erfordern. Wenn man diese Nachteile im Griff hat, also: kurzes Netzwerk (z.B. halber Meter), passende Baudrate (z.B. 9600) und passendes Biasnetzwerk (z.B. je 560ohm), keine nennenswerte Ground-Unterschiede, ist die Billiglösung aus meiner Sicht völlig legitim.
Die Billiglösung ist: Man sendet aktiv nur Space, und verlässt sich für
Mark auf das Biasnetzwerk.
Eine etwass bessere Lösung ist die Verwendung eines nicht retriggerbaren Monoflops, das auf etwa eine Bytezeit eingestellt wird, und somit vom Startbit getriggert wird. Einziger Nachteil ist die Baudratenabhängigkeit, aber einen Tod muss man sterben.
Eine tatsächlich bessere Lösung ist die Verwendung einer tauglichen UART, die nämlich kann die RS485-Ansteuerung in Hardware machen.
Ist ja nicht so, als daß es derartige UARTs nicht gäbe, sogar die üblichen USB-Seriell-Bridges à la FT232 enthalten so etwas.
Wer RS485 einsetzen will, muss halt auch etwas Aufwand treiben, und sowas nicht als "Nachgedanken" an eine auf Vollduplex ausgerichtete Hardware dranbamseln.
Eine tatsächlich bessere Lösung ist die Verwendung einer tauglichen
UART, die nämlich kann die RS485-Ansteuerung in Hardware machen.
Kurzes Zitat aus der ESP Doku:
1
This can be enabled by selecting the UART_MODE_RS485_HALF_DUPLEX mode when calling uart_set_mode().
2
Once the host starts writing data to the TX FIFO buffer, the UART driver automatically asserts the RTS pin (logic 1); once the last bit of the data has been transmitted, the driver de-asserts the RTS pin (logic 0). To use this mode, the software would have to disable the hardware flow control function.
screen.png
(91 KB)
