Hi, ich beiße mir zur Zeit die Zähne daran aus, eine RS485-Kommunikation zwischen einem µC und einem externen Gerät (Pfeiffer TPG366) herzustellen. In früheren Tests habe ich das schon einmal geschafft, aber ich kann es nicht mehr reproduzieren. Ich habe meine Schaltung sowohl als PCB als auch minimal auf einem Steckbrett aufgebaut. Zu beiden Aufbauten gibt es jeweils einen Screenshot vom Oszi. Zu sehen sind jeweils die Datenleitungen (lila/orange) und die Differenz (türkis). Ja, die Leitungen tauschen während der Messungen - ich hab die Sonden vertauscht, aber die Adern trotzdem m.M.n. korrekt angeschlossen. In den Bildern sieht man eine kurze Anfrage vom µC, die ignoriert wird und eine davon unabhängige Sendung vom Gerät. Dieses Gerät sendet im Normalfall nach dem Einschalten kontinuierlich Messwerte, bis es ein erste Byte über RS485 empfängt. Dann stoppt es die Übertragung und wartet auf Befehle. Das passiert hier aber nicht. Was auffällt, in Verbindung mit der Platine sieht das Signal vom Gerät auf der orangen Datenleitung ganz anders aus als die korrespondierende lila Datenleitung in Verbindung mit dem Steckbrett. Woran kann das liegen bzw. ist das in Ordnung? Ist es wahrscheinlich, dass hier einfach ein Chip auf meiner Platine defekt ist? Dann hätte ich noch zwei weitere Fragen: - Im Datenblatt des MAX485 (https://www.analog.com/en/products/max485.html) gibt es ein Bild 8 "Driver DC Test Load" - dort gibt es zwei 27R-Widerstände zwischen den Datenleitungen. Sollen diese die beiden 120R-Widerstände simulieren, die es an den Enden des RS485-Bussen gibt? Weil 4*27 = 120R? - Zu Pullups/Pulldowns scheinen die Meinungen auseinanderzugehen. Laut Datenblatt scheinen die nicht nötig zu sein, aber auch hier im Forum bilde ich mir ein, Gegenteiliges gelesen zu haben. Wie steht Ihr dazu? Welche Gründe gibt es, die doch einzusetzen? Vielen Dank schon mal Peter
Angehängte Dateien:
-
uCF_-_Schaltung.png
34 KB -
PCB_b.png
54 KB -
Steckbrett_b.png
63 KB
Natürlich darf jeder seine Meinung haben, richtig ist jedenfalls: - jeweils 120 Ohm Terminierung an den Enden des Busses - BIAS-Netzwerk (Pullup/Down) einmal (und NUR einmal) irgendwo auf dem Bus Die BIAS-Widerstände müssen so bemessen sein, daß mindestens 200mV Vorspannung anliegen, bei 5V sind das jeweils 470 Ohm. Ohne BIAS-Widerstände nimmt der Bus zufällige Pegel an, wenn kein Teilnehmer sendet. Die Auswirkungen sind unvorhersehbar, sicher ist nur, daß die Busteilnehmer nicht gut darauf reagieren.
:
Bearbeitet durch User
Das werde ich mal ausprobieren. Danke! Allerdings... Ist es nicht möglich, dass das externe Gerät in seiner Blackbox auch schon Pullups/Pulldowns verbaut hat? Wenn ich auf den Datenleitungen jeweils zu VCC und GND die ~470R messe, ist das dann ein richtiges Indiz dafür?
Die beiden Signale /RE und DE des Max485 musst Du auch irgendwo anschließen ...
Peder schrieb: > Ist es nicht möglich, dass das externe Gerät in seiner > Blackbox auch schon Pullups/Pulldowns verbaut hat? > Wenn ich auf den Datenleitungen jeweils zu VCC und GND die ~470R messe, > ist das dann ein richtiges Indiz dafür? Ja und ja. Manche RS485-Devices haben nebem der Terminierung auch das BIAS schaltbar an Bord. Steht normalerweise in der Doku. Die Widerstandswerte können abweichen, sind i.d.R. aber unter 1kOhm.
> Die beiden Signale /RE und DE des Max485 musst Du auch irgendwo Hat er doch, hast du nur nicht gesehen. Ich wuerde sie wohl verbinden und nur einen anschliessen... Ich wuerde auch den MAX3008 weglassen und stattdessen einen RS485 Treiber nehmen der 3V3 kann. Ausserdem wuerde ich GND durchverbinden. :-) GND wird nicht fuer die Datenuebertragung gebraucht, wohl aber fuer die physikalische Funkion der Driver. Besonders wenn vielleicht eine Seite auf 230V/2 von irgendeinem Schaltnetzteil liegt und die andere nicht. Die Biaswiderstaende wuerde ich drauf machen nachdem ich weiss das die Software auch ohne gut funktioniert. Sie sind technisch naemlich nicht notwendig, dein SoftwareDriver muss erkennen wenn er "falsche" Bytes bekommt und sauber neu aufsetzen. Danach koennen die dann aber nicht schaden. 120R sind natuerlich okay und richtig wenn man 100m Kabel durch eine Industrieanlage schleift. Sind es nur 2-3m im eigenen Keller reichen auch 1k. Die 120R sind manchmal etwas unangenehm weil man da 90% der Energie der gesamten Schaltung drin verheizt. Wenn das alles nicht hilft, mal AB vertauschen. Hat mich auch schon oft gehilft. :-D Vanye
Peder schrieb: > - Im Datenblatt des MAX485 > (https://www.analog.com/en/products/max485.html) gibt es ein Bild 8 > "Driver DC Test Load" Auf der verlinkten Seite gibt es kein Bild "Driver DC Test Load". In dem auf der Seite verlinkten Datenblatt gibt es eine Figure 4, die so heißt. Meinst du die? Die angegebenen Daten beziehen sich auf die in den Messbedingungen mit Verweis auf Fig. 4 angegeben Werte für die Last R. https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1487-MAX491.pdf
Rainer W. schrieb: > Auf der verlinkten Seite gibt es kein Bild "Driver DC Test Load". In dem > auf der Seite verlinkten Datenblatt gibt es eine Figure 4, die so heißt. > Meinst du die? > Die angegebenen Daten beziehen sich auf die in den Messbedingungen mit > Verweis auf Fig. 4 angegeben Werte für die Last R. > https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1487-MAX491.pdf Mein Fehler. Es ist der MAX485E (https://www.analog.com/en/products/max485e.html), aber die Grafik entspricht dann der Fig.4, ja. Vanye R. schrieb: > Ich wuerde auch den MAX3008 weglassen und stattdessen einen RS485 > Treiber nehmen der 3V3 kann. Muss ich noch mal schauen. Da ich eigentlich immer bevorzugt mit 3,3V arbeite, fürchte ich, dass ich danach schon gesucht habe. > > Ausserdem wuerde ich GND durchverbinden. :-) GND wird nicht fuer die > Datenuebertragung gebraucht, wohl aber fuer die physikalische Funkion > der Driver. Falls ich dich richtig verstehe, habe ich das so auch gemacht. Das Pfeiffer-Gerät hat an der RS485-Buchse 24V, die meine Platine versorgt. Insofern sind alle auf gleichem Ground. > > 120R sind natuerlich okay und richtig wenn man 100m Kabel durch eine > Industrieanlage schleift. Sind es nur 2-3m im eigenen Keller reichen > auch 1k. Die 120R sind manchmal etwas unangenehm weil man da 90% der > Energie der gesamten Schaltung drin verheizt. Guter Punkt. Ich habe tatsächlich eine sehr kurze Leitung <1m. Vielleicht lohnt es sich, die Widerstände mal nach unten zu korrigieren.
Peder schrieb: > Muss ich noch mal schauen. Da ich eigentlich immer bevorzugt mit 3,3V > arbeite, fürchte ich, dass ich danach schon gesucht habe. RS485-Treiber für 3.3V gibt es doch genug: https://www.digikey.de/de/products/filter/schnittstelle/treiber-empf%C3%A4nger-transceiver/710?s=N4IgjCBcoEwOwDYqgMZQGYEMA2BnApgDQgD2UA2uHACwxgAcIxYNYYArEyOwJzv08u1OAAYRCRsWF0wg4v1kihMHiJpCEYBNSRSAzNUNyQtevVldNesVzB6Y8GLb0J4xu6J56uMETHoixr7%2BdD5%2B9DC6IMH0cN5SEjB68VRg8BDMcGDUItQgALrEAA4ALlAgAMolAE4AlgB2AOYgAL5SucggaJBYeESkFCAIemwQhSCl5VV1Ta3ycIzQXRg4BMRkkJR6PKrCBcVlkJU1Dc1t4BJ5S929awObIHrsMNTsnOOTR9OnrS0tQA
Stammt der MAX485 aus vertrauenswürdiger Quelle? Die werden gerne und häufig gefälscht. Ich durfte mich mal mit nur manchmal funktionierenden Übertragungen rumschlagen, Ursache waren dann gefälschte MAX485 die auf Breakout-Boards gekauft worden waren.
Vlt. liegt es daran: Ein anspruchsvoller Punkt ist die richtige Steuerung des Pins für die Datenrichtung: Bevor man sendet, schaltet man diesen auf "Senden", komplizierter ist es hingegen, den richtigen Punkt für die Abschaltung zu finden. Mitnichten ist das Verlassen der Senderoutine der richtige Punkt, denn dann sind noch Daten im Sendebuffer.
Gerd E. schrieb: > Stammt der MAX485 aus vertrauenswürdiger Quelle? Ich habe gute Erfahrungen mit dem generischen SP485 und SP3485 von MaxLinear gemacht. Der 3485 ist die 3,3V Version. Gibt es für kleines Geld bei LCSC. Es gibt zwar noch billiger chinesische Nachbauten, aber bei dem MaxLinear gibts auch ein vernünftig lesbares Datenblatt dazu. Hab ein paar Dutzend von den Dingern zur Verlängerung von WS2812 genommen, um Pixel zu Pixel mehrere Meter ereichen zu können :-)
> Mitnichten ist das Verlassen der Senderoutine der richtige Punkt, > denn dann sind noch Daten im Sendebuffer. Oh ja, ein sehr guter Hinweis! Da sollte man unbedingt mal ein Oszi drauf werfen.... Ich hatte sogar mal einen Chip, irgendwas von Renesas, der hatte da einen Bug. Da kam das "komplette uebertragung fertig" Signal bereits bei der Haelfte vom letzten Bit. Hat oft funktioniert, aber nicht immer. Vanye
Peder schrieb: > ich beiße mir zur Zeit die Zähne daran aus, Mit den 3. beißt sich besser ;-) > Ich habe meine Schaltung sowohl als PCB als auch minimal auf einem Den Pegelwandler braucht man nicht zwingend. Denn der MAX485 hat TTL-kompatible Schaltschwellen. und kann damit sicher mit 3,3V CMOS angeseuert werden. Für die Rückrichtung von RO reicht ein 1k Längswiderstand. Siehe Pegelwandler. > Zu sehen sind jeweils die Datenleitungen (lila/orange) und die Differenz > (türkis). Ja, die Leitungen tauschen während der Messungen - ich hab die > Sonden vertauscht, aber die Adern trotzdem m.M.n. korrekt angeschlossen. > In den Bildern sieht man eine kurze Anfrage vom µC, die ignoriert wird > und eine davon unabhängige Sendung vom Gerät. Dieses Gerät sendet im > Normalfall nach dem Einschalten kontinuierlich Messwerte, bis es ein > erste Byte über RS485 empfängt. Dann stoppt es die Übertragung und > wartet auf Befehle. Das passiert hier aber nicht. Sieht soweit OK aus. Die Pegel werden am Ende der Übertragung auf HIGH (D+) und LOW(D-) gezogen. So weit, so gut. > Was auffällt, in Verbindung mit der Platine sieht das Signal vom Gerät > auf der orangen Datenleitung ganz anders aus als die korrespondierende > lila Datenleitung in Verbindung mit dem Steckbrett. Da stimmt was nicht. Masse nicht angeschlossen? > Dann hätte ich noch zwei weitere Fragen: > - Im Datenblatt des MAX485 > (https://www.analog.com/en/products/max485.html) gibt es ein Bild 8 > "Driver DC Test Load" - dort gibt es zwei 27R-Widerstände zwischen den > Datenleitungen. Sollen diese die beiden 120R-Widerstände simulieren, die > es an den Enden des RS485-Bussen gibt? Weil 4*27 = 120R? Nicht ganz. Der Bus kann mit 2x120R = 60 Ohm belastet werden. die 2x27R=54R sind die Testgrenze incl. Reserve. > - Zu Pullups/Pulldowns scheinen die Meinungen auseinanderzugehen. https://www.mikrocontroller.net/articles/RS-485#Weitere_Hinweise
Gerd E. schrieb: > Stammt der MAX485 aus vertrauenswürdiger Quelle? Eigentlich ja. Ich hab die von Mouser. Aber vielleicht hab ich den ja trotzdem kaputtgelötet. Harald A. schrieb: > Bevor man sendet, schaltet man diesen auf "Senden", komplizierter ist es > hingegen, den richtigen Punkt für die Abschaltung zu finden. Mitnichten > ist das Verlassen der Senderoutine der richtige Punkt, denn dann sind > noch Daten im Sendebuffer. Ich sehe die Daten auf dem Oszi und kann Bit für Bit die Nachricht "lesen". Sie ist damit zumindest auf dem RS485-Bus präsent. Falk B. schrieb: > Den Pegelwandler braucht man nicht zwingend. Denn der MAX485 hat > TTL-kompatible Schaltschwellen. und kann damit sicher mit 3,3V CMOS > angeseuert werden. Für die Rückrichtung von RO reicht ein 1k > Längswiderstand. Siehe Pegelwandler. Den habe ich in der Tat auch nicht auf dem Steckbrett - wo das Ergebnis besser aussieht. Ich habe mir jetzt den MAX3485 bestellt und werde den am Montag mal ausprobieren. Ein Chip weniger ist eine Fehlerquelle weniger. > Da stimmt was nicht. Masse nicht angeschlossen? Das muss ich mal durchmessen. Die Platine selbst lebt vom GND des externen Gerätes. Aber vielleicht hab ich da schlecht gelötet. Ich sage erstmal vielen Dank bis hierher. Morgen und nächste Woche werde ich mir das hier noch mal alles und schauen, was ich hinbekomme. Inklusive neuem Chip. Ich meld mich dann noch mal.
Vanye R. schrieb: > Die Biaswiderstaende wuerde ich drauf machen nachdem ich weiss das die > Software auch ohne gut funktioniert. Sie sind technisch naemlich nicht > notwendig, dein SoftwareDriver muss erkennen wenn er "falsche" Bytes > bekommt und sauber neu aufsetzen. Kein guter Tipp. Das ist wie ein Auto mit schlechtem mechanischen Fahrwerk zu bauen und die Unzulänglichkeiten dann per ESP auszugleichen. Die BIAS-Widerstände sorgen hardwaremäßig für einen definierten Ruhepegel, sodaß die Software gar nicht erst raten muß, ob das Startbit ein Fehler war oder schon zu den Daten gehört. Es gibt keinen plausiblen Grund, das BIAS wegzulassen, außer der BWLer will unbedingt zwei Cent am Gerät sparen.
> Kein guter Tipp. Das ist wie ein Auto mit schlechtem mechanischen
Du hast mich nicht verstanden. Deine Software muss robust genug sein
jederzeit mit einem beliebigen falschem Byte klar zu kommen. Das darf
ihr nix ausmachen! Oder willst du z.B in der EMV dreimal antanzen weil
sich da was weghaengt?
Wenn du ernsthaft Software machst (SIL) dann werden sogar Tests gefahren
wo man bewusst falsche Daten injeziert um zu schauen ob dein Geraet
danach noch laeuft.
Danach kann man dann die Widerstaende vorsehen um die Sicherheit noch
weiter zu verbessern. Aber man darf sich nicht darauf verlassen.
Jeder hier ist doch immer bereit sich ueber kruden Mist anderer Leute
auszulassen und wer weiss was fuer Forderungen zu stellen. Hier hat man
die Gelegenheit selber mal gutes zu tun. Also sollte man es auch.
Vanye
Zwei Tipps von mir: M.M.n. Sollte nur der Master (oder ein Busteilnehmer) die Bias Rs aufweisen. Mehrere Köche verderben den Brei. Da das ein Halb-Duplex System ist, empfiehlt es sich dem RO Pin einen Pullup von ein paar zehn kOhm zu verpassen. Mir ist es schon passiert, daß beim Senden dann der RO Pin durch verdrahtungsbedingte Ursachen wegen der hohen Impedanz undefiniert zwischen Vdd und Vss schwebt und manchmal je nach Layout mit dem Sendesignal etwas mitschwingt und dem RX USART unbeabsichtigt unzusammenhängende Signale verpasst, die dann zu sporadischen Framing und Overrun Bitfehler im USART führen, die die Treiber SW (meist ISR) unnötig beanspruchen. Mit einem Pullup gibt es den Spuk nicht. Das ist mir mal mit einem PIC passiert. Wenn RE- beim Senden auf High gesetzt wurde, war RO in Tri-State und dann ist der USART RX-Eingang undefiniert und wandert spannungsmässig schlafwandlerisch durch die Gegend. Übrigens würde ich gerne den Grund wissen, warum DI und RE bei Dir nicht zusammen gesteuert werden. Meist es unnötig die Sende-Daten dem USART beim Senden rückzuführen. Man erspart einen unnötig aufgebrauchten Controller Pin. Ich würde übrigens auch gleich einen 3.3V Typ verwenden. In dem Fall bleibt RO beim Senden statisch High (mit Pullup) und macht keine Faxen. RS485 funktioniert, wenn man aufpasst und keine groben Fehler macht, meist auf Anhieb und zuverlässig. In meinen Arbeit und Heim Projekten gab es unzählige RS485 Projekte mit zahlreichen Busteilnehmern und es gab ausser am Anfang der Entwicklung keine Schwierigkeiten ausser dem Beschriebenem. Wie meist, soll man sich an Datenblatt und App-Note Empfehlungen halten. Wenn ein Masse-Draht nicht mitgeführt werden kann, empfiehlt es sich einen galvanisch getrennten Bus-Transceiver mit lokalen Bias-Widerständen zu verwenden. Dann kann sich jeder Transceiver selber optimal einstellen und betreiben.
Vanye R. schrieb: > Du hast mich nicht verstanden. Deine Software muss robust genug sein > jederzeit mit einem beliebigen falschem Byte klar zu kommen. Ohne Bias-Widerstände kann irgendwelches Rauschen ein einzelnes falsches Start-BIT erzeugen. Wenn das richtige Startbit dann innerhalb des aus Sicht des Empfängers vermeintlichen (Fehl-)Bytes ist, kommt das richtige Byte nie als solches beim Empfänger an und die Synchronisation bei den Folgebytes wird auch erstmal nicht klappen (abhängig vom Dateninhalt). Es geht nicht um einzelne falsche BYTES. Natürlich kann man das auf irgendeinem hohen Level der Protokolls abfangen, aber einfacher wären doch 2 Bias-Widerstände. KISS
:
Bearbeitet durch User
Vanye R. schrieb: >> Kein guter Tipp. Das ist wie ein Auto mit schlechtem mechanischen > > Du hast mich nicht verstanden. Deine Software muss robust genug sein > jederzeit mit einem beliebigen falschem Byte klar zu kommen. Im Worst Case sorgen fehlende Bias-Widerstände aber dafür, dass nicht nur ein falsches Byte reinkommt, sondern kurz vor dem echten Datenpaket fälschlicherweise ein Startbit erkannt wird. Das kann man nur verhindern, indem man nach dem Einschalten des Treibers (was für einen sauberen Ruhepegel sorgt) mindestens eine Bytedauer wartet und/oder mit Bias-Widerständen sicherstellt, dass dieser Fall gar nicht erst eintritt. Die Software darf natürlich bei fehlerhaften Bytes nicht abstürzen, aber wenn der UART den Anfang an der falschen Stelle sieht, ist im Worst Case trotzdem ein ganzes Datenpaket weg. Kleiner Hinweis am Rande: Bitte verwende die Zitatfunktion richtig, damit man durch Draufklicken zum zitierten Beitrag kommt. Der Boimler-Schwafler, der das vorsätzlich falsch macht, ist kein gutes Vorbild. Gerhard O. schrieb: > Übrigens würde ich gerne den Grund wissen, warum DI und RE bei Dir nicht > zusammen gesteuert werden. Meist es unnötig die Sende-Daten dem USART > beim Senden rückzuführen. Das eigene Echo zu sehen, kann hilfreich sein, um z.B. Kurzschlüsse oder Kollisionen zu erkennen. Und nebenbei hat man nicht das (von Dir auch erwähnte) Problem, dass RO bei abgeschaltetem Empfänger hochohmig ist und somit einen Pullup braucht, um beim Senden keinen Müll zu empfangen.
Vanye R. schrieb: > Du hast mich nicht verstanden. Deine Software muss robust genug sein > jederzeit mit einem beliebigen falschem Byte klar zu kommen. Du mich auch nicht. Natürlich muß die Software fehlertolerant arbeiten. Aber man muß es ihr doch im Produktivbetrieb nicht noch künstlich schwer machen, indem man die Hardware schlecht baut.
Hmm ... also 2-Draht. Dass da die Busumschaltung fehlt wurde - glaub ich - schon geklärt. Wer ist den aber Master, wer Slave? Ich würde erst mal die Gegenstelle abklemmen und schaun ob aus meiner Schaltung ein Signal rauskommt.
Vanye R. schrieb: > Hat er doch, hast du nur nicht gesehen. Da er im Schaltplan aus irgendwelchen Gründen die Rx/Tx-Leitungen durch einen Pegelwandler geführt hat (warum eigentlich?), und dazu die Signalleitungen durchverbunden hat (so, wie man das in Schaltplänen zu tun pflegte), habe ich in der Tat nicht damit gerechnet, daß die Signale ohne Pegelwandler direkt "verbunden" sind - warum allerdings zwei Signale, statt die übliche Ansteuerung mit nur einem, bleibt auch noch offen.
Harald K. schrieb: > warum allerdings zwei Signale, statt die übliche Ansteuerung > mit nur einem, bleibt auch noch offen. Manche Transceiver brauchen nur noch einstellige µA wenn man RX und TX abschaltet. "MAX485" ist doch nur ein Platzhalter für einen vernünftigen Typ ;) Es gibt übrigens auch welche, die diese berüchtigten Bias-Widerstände meistens nicht brauchen ("Fail-Safe").
Bauform B. schrieb: > Es gibt übrigens auch welche, die diese berüchtigten Bias-Widerstände > meistens nicht brauchen ("Fail-Safe"). Darauf sollte man sich allerdings nur verlassen, wenn am Gerät nichts angeschlossen ist. Der Eingang ist damit weiterhin hochohmig, der Bereich zwischen -200mV und +200mV ist bloss nicht mehr undefiniert, sondern sicher high. Wenn da eine (längere) Busleitung dranhängt, wäre mir das ohne relativ niederohmige Bias-Widerstände zu riskant.
Hmmm schrieb: > der Bereich zwischen -200mV und +200mV ist bloss nicht mehr > undefiniert, sondern sicher high. > Wenn da eine (längere) Busleitung dranhängt, wäre mir das ohne relativ > niederohmige Bias-Widerstände zu riskant. Die Terminierungs-Widerstände sind sehr niederohmig und sorgen für 0 mV. Was ist da das Risiko?
Clemens L. schrieb: >> der Bereich zwischen -200mV und +200mV ist bloss nicht mehr >> undefiniert, sondern sicher high. >> Wenn da eine (längere) Busleitung dranhängt, wäre mir das ohne relativ >> niederohmige Bias-Widerstände zu riskant. > > Die Terminierungs-Widerstände sind sehr niederohmig und sorgen für 0 mV. > Was ist da das Risiko? Die Bias-Widerstände sorgen für ca. 660mV. Bis zur anderen Polarität hat man dann ca. 800mV Rauschabstand im Gegensatz zu nur 200mV. https://www.mikrocontroller.net/articles/RS-485#Weitere_Hinweise
Clemens L. schrieb: > Die Terminierungs-Widerstände sind sehr niederohmig und sorgen für 0 mV. > Was ist da das Risiko? Weil RS485 nach dem Prinzip des Differenzverstärkers arbeitet und die Eingangsstufen einen Mindestpegel von 200mV benötigen, um das Signal sicher zu erkennen.
Icke ®. schrieb: > Vanye R. schrieb: >> Du hast mich nicht verstanden. Deine Software muss robust genug sein >> jederzeit mit einem beliebigen falschem Byte klar zu kommen. > > Du mich auch nicht. Natürlich muß die Software fehlertolerant arbeiten. > Aber man muß es ihr doch im Produktivbetrieb nicht noch künstlich schwer > machen, indem man die Hardware schlecht baut. Im Produktivbetrieb sind die Bias-Widerstände doch vorhanden. Es ging nur darum, sie im Softwaretest wegzulassen, um ein umfangreicheres Debugging der Fehlererkennung zu ermöglichen.
Angehängte Dateien:
-
uCF_-_RS485-Adapter.png
56 KB
Harald K. schrieb: > Da er im Schaltplan aus irgendwelchen Gründen die Rx/Tx-Leitungen durch > einen Pegelwandler geführt hat (warum eigentlich?), [...] - warum allerdings zwei > Signale, statt die übliche Ansteuerung mit nur einem, bleibt auch noch > offen. Es ist schon eine Weile her, dass ich mich für den Pegelwandler entschieden habe, aber ich glaube der Grund war der: Der MAX485 wird mit 5V versorgt, und ohne das jetzt zu testen, gehe ich (noch) davon aus, dass die Datenleitungen dann auch mit 5V zum µC gehen - was der nicht abkann. Getrennte Steuerleitungen habe ich einfach gewählt, weil mir so alle Optionen bleiben. Zusammenschalten kann ich sie ja auch per Software. @alle Ich habe heute mal das Gerät über einen kommerziellen RS485-Adapter an einen PC mit hterm angeschlossen. Erfreulicherweise läuft die Kommunikation einwandfrei, aber das Oszi-Bild hat mich überrascht. Im Bild sieht man wieder die Datenleitungen und die Differenz. Das erste Datenpaket ist eine Anfrage an das Gerät, und das zweite ist die korrekte und erwartete <ACK>-Antwort vom Gerät. Soweit alles gut. Die Idle-Pegel beider Leitungen liegen aber nicht, wie erwartet, auf 5V und 0V (Adapter) oder auf 3.5V und 0V (Gerät), sondern auf knapp über 1V. Dazu kommt, dass die eingekreisten Peaks keine Bits sind, sondern wahrscheinlich eine Art Vorbereitung darauf, dass gleich das Start-Bit kommt. Das heißt, irgendwie ist das Idle-Verhalten sehr seltsam. Ist das dennoch so, wie ein RS485-Bus aussehen sollte? Ich habe bisher immer andere Protokolle verwendet, und da waren die Pegel immer deutlich high/low, aber nichts dazwischen. Nur zur Info, so wie es aussieht, hat das Gerät intern keine Busterminierung und keine Pullups/Pulldowns.
Peder schrieb: > Die Idle-Pegel beider Leitungen liegen aber nicht, wie erwartet, auf 5V > und 0V (Adapter) oder auf 3.5V und 0V (Gerät), sondern auf knapp über > 1V. Um den Ruhepegel kümmern sich die Bias-Widerstände, die mit den Abschlusswiderständen einen Spannungsteiler bilden. Peder schrieb: > Dazu kommt, dass die eingekreisten Peaks keine Bits sind, sondern > wahrscheinlich eine Art Vorbereitung darauf, dass gleich das Start-Bit > kommt. Da wird der Treiber eingeschaltet.
Peder schrieb: > Der MAX485 wird mit 5V versorgt, und ohne das jetzt zu testen, > gehe ich (noch) davon aus, dass die Datenleitungen dann auch > mit 5V zum µC gehen - was der nicht abkann. Um den Pegel von 5V auf 3,3V zu verringern, würde ein Spannungsteiler aus zwei Widerständen reichen. Deine Signale sehen nicht so aus, als ob du mehrere MBit/s übertragen möchtest.
Zeig mal dein UART-TX (oder -RX, egal) zusätzlich an. Dann dürfte das Bild gleich viel vertrauter aussehen. Auf dem Kanal siehst du dann den Idle-Zustand vom UART und weißt, wie der auf dem Bus aussieht. Hier gibt es einen anderen zweiten Idle-Zustand wenn beide Sender abgeschaltet sind.
Peder schrieb: > Nur zur Info, so wie es aussieht, hat das Gerät intern keine > Busterminierung und keine Pullups/Pulldowns. Dann hast du mehr Glück als Verstand, denn der Ruhepegel deines Busses liegt bei nahe 0V. Es funktioniert, schön und zuverlässig ist aber was anderes.
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.