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). Schaltpläne gesucht und obiges gefunen (Ausschnitt). Original ist hier https://files.waveshare.com/wiki/ESP32-S3-Touch-LCD-7/ESP32-S3-Touch-LCD-7-Sch.pdf Laut Beispiel Programm #define RS485_RX_PIN 15 #define RS485_TX_PIN 16 Gibt es da einen Trick wie das funktionieren kann?
Angehängte Dateien:
-
screen.png
91 KB
Achtung ich bin Elektronik Noob. Ich versteh das so, daß die Richtung automatisch umgeschaltet wird wenn ich vom PC Daten sende. RX geht auf Hight -> DE geht auf Low?
Holger schrieb: > 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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
SP3481_85.png
16 KB
Holger schrieb: > Deshalb frage ich ja ob es da einen Trick gibt. 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.
Rainer W. schrieb: > 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...
:
Bearbeitet durch User
N. M. schrieb: > 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.
Rainer W. schrieb: > Getrennte Signal über RS485_RX_PIN und RS485_TX_PIN geht mit dem Board > jedenfalls nicht, ohne einen Lötkolben zu bemühen. Wieso nicht? Sind doch getrennte Pins (15/16)? 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. Oder wackeln einfach Mal mit IO16 RUM und schau dir an ob sich was auf dem RS485 tut.
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?
N. M. schrieb: > 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. Der DI liegt wirklich auf GND (nachgemessen).
Rainer W. schrieb: > An RO sehe ich nur einen Pull-Up (R74) und sonst keine weiteren > Verbindungen. Ja, da ist aber ein Label(RS485_TXD) dran. Das wird unten beim ESP (U8) über eine Leitung mit (IO15) verbunden.
Holger schrieb: > Am DI jedenfalls nicht Ja das war klar. Meine Vermutung war sie senden über die Richtungsumschaltung, also !RE und DE. Holger schrieb: > und am RS485 Stecker auch nicht. Das ist schlecht. Das hätte bei obigen Vermutungen funktionieren müssen.
@Rainer W. danke für die Hilfe aber ich will das nicht neu aufbauen ich wollte die Platine um mit lvgl zu spielen. Ich versuch die jetzt über USB an einen St32H747 (Arduino Opta) als USB Host an zu hängen. Das ist aber nur spielen.
N. M. schrieb: > 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.
Ist irgendwo auf dem RS485-Bus ein Abschlusswiderstand aktiviert (R70, J4.2-3)?
Rainer W. schrieb: > 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ß.
R70 gibt es. Der wird durch einen Jumper ein bzw. ausgeklemmt. Hab ich in beiden Positionen versucht. Aber nicht am IO16 gewackelt. Werde ich morgen nochmal versuchen.
Da habe ich den Uwe überlesen. Kannst Du das so erklären, daß ich es auch verstehe. Wenn der PC sendet kommt das Signal an Pin 1 (RO) an und damit an IO16 (RX) Muss ich, wenn das Board senden soll, den IO16 als Ausgang schalten?
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.
Uwe schrieb: > Diese löst die Schaltung elegant 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
Ich bin etwas verwirrt. RX (IO16) ist doch der serielle Eingang des ESP und TX der serielle Ausgang des ESP? Und RX schaltet den Transistor. RX High -> Transistor durchgeschaltet -> DE Low -> Treiber steht auf empfangen (vom ESP gesehen) Verstehe ich das richtig?
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.
:
Bearbeitet durch User
Uwe schrieb: > 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. Holger schrieb: > Verstehe ich das richtig? 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.
:
Bearbeitet durch User
Hmmm schrieb: > N. M. schrieb: >> 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.
Uwe schrieb: > 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).
Michael B. schrieb: > Es ist einfach Schwachsinnig, wegen mangelndem Richtungssignal den > Treiber bei rezessivem Sendepegel zu disabeln Es gibt Tage, die selten sind. Heute ist einer davon: Ich stimme Dir zu.
Michael B. schrieb: > 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.
:
Bearbeitet durch User
Uwe schrieb: > 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.
Harald K. schrieb: > 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. |
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/uart.html Es scheint also eher als ob das Waveshare Board einfach schlecht ist.
N. M. schrieb: > Es scheint also eher als ob das Waveshare Board einfach schlecht ist. Und diesen RS485-Hack verwenden sie öfter, scheinbar mit jeweils zufällig gewürfelten Bias-Widerstandswerten: https://files.waveshare.com/upload/0/02/Pico-2CH-RS485.pdf Also nichts, was man irgendwo produktiv einsetzen sollte, solange man keine Lust hat, den Murks vorher umzubauen.
Hmmm schrieb: > Und diesen RS485-Hack verwenden sie öfter, scheinbar mit jeweils > zufällig gewürfelten Bias-Widerstandswerten: Aus einem Faktor 1.4 im Strom würde ich jetzt keinen Elefanten machen.
N. M. schrieb: > Kurzes Zitat aus der ESP Doku: Das beschreibt die Software, aber auch die zugrundeliegende Hardware macht das. Siehe S.924 ff im TRM https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf Der einzige Grund, hier so eine Frickelbastelei zu verwenden, wäre, daß man den Pin DTR der jeweiligen UART anderweitig nutzen will.
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.