Hallo, nach vielen Versuchen bin ich endlich dem Problem auf die Spur gekommen: Ich habe einen RS485-Slave aufgebaut, der sporadisch abstürzte. Die Ursache dafür ist, dass der Master eine Anfrage schickt, seine Treiber aber nicht gleich abschaltet. Wenn dann mein Slave antwortet, arbeiten die Treiber von Master und Slave gegeneinander. Im Datenblatt des Slave-Transceivers MAX3072E ist angegeben, dass in dem Fall bis zu 250mA fließen. Das reicht wohl aus, um die Versorgung des Mikrocontroller soweit abfallen zu lassen, dass dieser sich aufhängt. Als Gegenmaßnahme habe ich jetzt mal vor die Antwort ein Delay eingebaut. Das geht auch ganz gut. Ab und zu kommt es trotzdem zu Aufhängern. Das Delay kann nicht beliebit verlängert werden, sonst liefert der Master einen Timeout. Ich könnte natürlich auch die Brown-Out Erkennung und den Watchdog aktivieren. Das verschleiert das Problem aber nur, statt dessen Ursache zu beheben. Und am Master kann ich nichts machen. Deshalb die Frage: Wie kann ich erkennen, wann der Treiber des Master abgeschaltet wird? Wenn die Antwort dann gleich darauf folgt, würde dieses Problem nicht mehr auftreten. Vielen Dank & schöne Grüße Markus
Mark U. schrieb: > Wie kann ich erkennen, wann der Treiber des Master > abgeschaltet wird? Das muß in der Protokollspezifikation des Masters stehen. Man kann es auch variabel halten. Dann muß der Master im ersten Paket dem Slave mitteilen, wie lange er sich mit dem Abschalten Zeit zu lassen gedenkt. Oft werden 2 Zeiten spezifiziert, wann darf der Slave frühestens senden und wann darf er spätestens anfangen. In der Regel ist es keine Kunst, im Sendeinterrupt nach dem Senden des ersten Stopbits sofort den Transceiver abzuschalten. Längere Zeiten könnten dem Overhead eines RTOS oder OS im Master geschuldet sein.
Mark U. schrieb: > Deshalb die Frage: Wie kann ich erkennen, wann der Treiber des Master > abgeschaltet wird? Das geht normalerweise nicht so einfach. Ich lege im Normalfall die Versorgung so aus, dass sie den Kurzschlussstrom der Treiber aushält. Weil der im Datenblatt steht, ist das so auch lösbar. Die sauberste Lösung ist aber, das Protokoll einzuhalten. Die Stromversorgung ist trotzdem wichtig, weil man dann im Fehlerfall statt einem undefinierten Ausfall einen lauffähigen Microcontroller hat.
Ja, das vermute ich auch: Normalerweise wird der Treiber des Masters gleich nach der Anfrage abgeschaltet. In seltenen Fällen dauert es bis zur Abschaltung aber bis zu 5ms. Jedenfalls war das jetzt der längste gemessene Wert, vielleicht sind auch längere Zeiten möglich. Keine Ahnung, was der da so lange treibt, würde aber meinen, das hängt mit dem Linux zusammen, das auf dem Master läuft. Im Protokoll steht zu den Zeiten leider nichts... Also hilft nur Abwarten? Dann würde ich die größtmögliche Wartezeit wählen, so dass der Master gerade kein Timeout erkennt. Dann noch Brown-Out Erkennung und Watchdog einschalten. Ist zwar keine saubere Lösung, aber funktionieren wird es.
OK, dann noch die Spannungsversorgung des Slave verbessern: Der Regler selbst liefert bis zu 1A, das reicht locker. Dann noch ein dicker Kondensator, der Spitzen puffert. Das sollte helfen.
So wie ich das Datenblatt auf Seite 7 verstehe (Output current vs.
Transmitter Output {high,low} voltage), ist der Strom eh durch das
Foldback begrenzt, das Problem sind nur die kurzen Spannungeinbrüche bis
das Foldback greift. Ich bezweifle dass dein Regler das schnell genug
ausregelt, aber mehr Low-ESR-Kapazität nah am Controller klingt immer
gut. Noch effektiver wäre es, die Versorgungen für Slave und Transceiver
zu entkoppeln, damit zumindest dein Controller nicht abschmiert.
Alternativ: Je nach Geschwindigkeit, Entfernung und Anzahl Teilnehmern
kannst du überlegen, den Treiberstrom zu begrenzen. Wenn du nur einen
Teilnehmer in 10m ansteuerst, brauchst du wahrscheinlich nicht die volle
Treiberleistung und könntest den KS-Strom durch Serienwiderstände
begrenzen.
Mark U. schrieb:
> Deshalb die Frage: Wie kann ich erkennen, wann der Treiber des Master
> abgeschaltet wird? Wenn die Antwort dann gleich darauf folgt, würde
> dieses Problem nicht mehr auftreten.
Um deine Frage zu beantworten:
*Möglichkeit 1*: Differenzspannung überwachen. Wenn Slave- und
Mastertreiber aus sind (und Abschlusswiderstände zwischen den Adern
vorhandenn sind), fällt die Differenzspannung zwischen den Adern ja auf
Null. Das ließe sich mit externer Beschaltung überprüfen, kommt mit
einem gewissen Beschaltungsaufwand. Wenn du zusätzlich noch slaveseitig
deine Adern auf ein festes Common-Mode-Potential ziehst (z.B. durch 1k
nach GND und VCC, so dass die floatende Leitung auf 2.5V liegt) reichen
zwei Fensterkomparatoren (weil sich die Spannungen der ungetriebenen
Leitungen auf VCC/2 einpendeln).
Sind aber viele "Wenn"s, und hängt davon ab wie schnell du senden willst
vs. die Zeitkonstante aus Leitungskapazität und Abschlusswiderstand
(d.h. wie lage dauert es bis die Differenzspannung auf Null abgesunken
ist). Außerdem musst du das Hardwaresignal im Slave auswerten.
*Möglichkeit 2*: Treiberstrom überwachen. Wenn du die Versorgung vom
Treiber entkoppelst, kannst du die Einbrüche in der Treiberspannung
erkennen (Komparator oder PNP-Transistor) und ein Software-Delay
aktivieren.
Hier noch eine blöde Idee, eine reine Softwarelösung die wahrscheinlich
nicht funktioniert: Miss mit einem schnellen Timer die Verzögerung die
es dauert, bis eine Änderung von DI an RO erscheint. Treibt der Master,
dann dauert das ein bisschen länger. Eine quick-and-dirty-Simulation
zeigt aber, dass die Verzögerung im Bereich von 100ns liegt, was a)
wenig zeitliche Auflösung zum sauberen Klassifizieren liefert und b)
kleiner ist als mögliche Umgebungs-Schwankungen (PVT).
Danke für diese ausführliche Antwort. Da sind einige Ansätze drin, ich mal überdenken und geg.falls ausprobieren muss. Insbesondere die Entkopplung der Versorgungsspannungen. Was ist denn unter "Foldback" zu verstehen? Ich hatte das auch gelesen, weiß aber nicht, welche Bedeutung dieser Begriff hat.
Mark U. schrieb: > Was ist denn unter "Foldback" zu verstehen? Ich hatte das auch gelesen, > weiß aber nicht, welche Bedeutung dieser Begriff hat. Der Strom wird nicht nur begrenzt, sondern beim Überschreiten einer Schwelle auf einen niedrigeren Wert "zurückgefaltet". Siehe S.7, rechts unten. Wenn der Treiberoutput low ist und Strom in den Ausgang fließt, steigt die Spannung am Ausgangspin an (durch den Ausgangswiderstand im Treiber bedingt). Am Anfang steigt die Kurve noch linear mit einer Steigung von ca. 2V/160mA = 12,5 Ohm Ausgangsimpedanz. Der Strom ist intern auf 160mA limitiert, so lange du unter 3.3V bleibst. Wenn du diese Spannung überschreitest, schaltet die Foldback-Schaltung den Ausgang auf Strombegrenzung um und begrenzt den Strom auf 60mA. Beim High-Pegel ist es ähnlich: Wenn du den Ausgang auf High stellst, fließt Strom aus dem Treiber, mit einer Steigung von ca. 1V/100mA = 10 Ohm Ausgangsimpedanz. Überschreitet der Ausgangsstrom 150mA bzw. ist die Spannung am Ausgangspin unter ~1.3V, dann schaltet der Ausgang wieder auf Strombegrenzung (Pfeil nach unten). Erst wenn die Spannung wieder über ~1.7V steigt bzw. der Strom unter ~42mA fällt, wird der normale Treiber wieder aktiviert (Pfeil nach oben). Wie sich diese Werte mit 250mA Spitzenstrom, 20mA Foldback-Strom aus der Tabelle auf Seite 3 vereinbaren lassen weiß ich nicht.
:
Bearbeitet durch User
Mark U. schrieb: > Was ist denn unter "Foldback" zu verstehen? Bei Überstrom reduziert das Bauteil den durch ihn fliessenden Strom auf eine unkritische Grenze. Fällt der Überstrom weg, wird wieder der maximale verfügbare Strom geliefert. Als Vorversuch kannst du mal ein RC Glied in die Versorgung des Tranceiver legen. Niederohmig, aber nicht zu niederohmig - z.B. 10 Ohm/100µF
:
Bearbeitet durch User
Wenn Du Dich stur an das Prinzip: "Ich rede und Du hältst die Klappe" hältst, sollte es keine Probleme geben. Eigentlich ganz einfach. Der Chef sagt was und die Angestellten lauschen höflich. Üblicherweise ist dann, von Seiten des Chefs aus Ruhe. Ob die Angestellten jetzt was zu sagen haben, wissen beide. Nebenbei gesagt: Wird der Bus ständig in Betrieb gehalten, kostet das nur unnötig Strom. Die 120 Ohm sind ja nicht ganz ohne.
wenn der Master fertig ist mit senden, geht dessen TxD Leitung am Widerstandsteiler in den Ruhepegel, den wiederum kann man verwenden um per Hardware den Treiber umzuschalten, damit erreichen wir jede Baudrate die gewünscht wird..
Das stimmt schon und funktioniert auch meistens. Nur sagt der Chef eben manchmal was, macht dann aber noch eine Kunstpause hinten dran. Und wenn dann der Angestellte in die Pause plappert, gibt's Ärger... Der Bus ist die meiste Zeit Idle: Es kommt nur ca. alle 30 sec. eine Anfrage, die beantwortet wird. Das sind jeweils nur ein paar Millisekunden.
Wenn es keine passive Failsafe-schaltung gibt kann man Bus-Idle mit einem verkehrt angeschlossenen RS485 receiver erkennen. Der "richtig" angeschlossene Receiver gibt bei Bus-high eine 1 aus, der falsch angeschlossene gibt bei bus-low eine 1 aus, sind beide 0 bzw. 1 ist der Bus idle.
:
Bearbeitet durch User
Das mit dem zweiten Transceiver hört sich gut an! Ich werde das mal fädeln und wenn's klappt auf die nächste Version der Platine übernehmen. Danke für alle Ideen!
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.