Frage:
Gibt es eine gute Möglichkeit, einen RS-485-Sender automatisch in Hardware zu aktivieren?
fred basset
2013-04-17 02:41:53 UTC
view on stackexchange narkive permalink

Kennt jemand eine gute Schaltung, die die Übertragung auf einem RS-485-Treiber automatisch ermöglicht, wenn Zeichen übertragen werden? In unseren Designs verwenden wir derzeit RTS, um den Treiber-Sendestift anzusteuern, aber dann muss die RTS-Signalisierung in der Software erfolgen.

Beachten Sie, dass die Lösung recht billig sein muss, da dies ein Volumenprodukt sein wird ( Art schließt die Verwendung eines separaten Mikrocontrollers aus, um die Arbeit zu erledigen). Es wäre auch ein Problem, die Übertragung länger als nötig aktiviert zu halten, da die serielle Leitung möglicherweise viel Verkehr verarbeiten muss.

Fünf antworten:
#1
+4
Dave Tweed
2013-04-17 07:21:03 UTC
view on stackexchange narkive permalink

Wenn Sie ein gewöhnliches asynchrones (UART) Protokoll mit einem Startbit am Anfang jedes Bytes verwenden, besteht eine einfache Methode darin, einen monostabilen Multivibrator (sogar den gefürchteten 555) zu verwenden, der auf die Dauer eines Bytes plus eingestellt ist das Startbit und ungefähr die Hälfte des Stoppbits und verwenden Sie dieses, um den Sendetreiber zu aktivieren.

Wenn der Multivibrator erneut auslösbar ist, müssen Sie ab dem Ende einer Übertragung bis zu einem vollen Byte Zeit vor allen anderen zulassen Andernfalls kann gesendet werden, da der Multivibrator möglicherweise durch das letzte Datenbit erneut ausgelöst wurde, wenn er eine Null war.

Wenn nicht, sollte er in der Mitte jedes Stoppbits abschalten und dann erneut auslösen das nächste Startbit.

Ich würde das gerne sehen.
Das klingt gut. In der Stromschaltung haben die Hardware-Leute entworfen, dass der Sendeantrieb des RS-485-Treiberchips mit dem TTL-Sendestift verbunden ist, sodass bei jedem * Bit * die Übertragung aktiviert ist. Ich kann jedoch nicht sehen, wie dies zuverlässig funktionieren würde, werde es aber in den nächsten Tagen testen ...
Es ist möglich, dass die Absicht besteht, den Bus als Pseudo-CAN-Bus mit einem "dominanten" Zustand und einem "rezessiven" Zustand zu betreiben. Haben die Hardware-Leute ziemlich steife Pullup- / Pulldown-Widerstände auf die Busleitungen gelegt?
Ich sehe 750 Ohm Widerstände auf den RX + und RX- Leitungen, nicht sicher, ob dieser Wert ziemlich steif ist oder nicht. Wie würde der gesamte RS-485 funktionieren, wenn er wie ein CAN-Bus wäre? Ich habe RS-485 bisher nur im einfachen Zweidrahtmodus verwendet.
750 Ohm würden als "ziemlich steif" (6,67 mA bei 5 V) gelten, also ist das wahrscheinlich der Fall. Was den Betrieb des RS-485 angeht, sollte er wie erwartet funktionieren. Es ist nur so, dass durch Kollisionen mit diesem Hardware-Setup keine physischen Schäden auftreten können.
#2
+4
Darian
2013-06-20 11:59:16 UTC
view on stackexchange narkive permalink

Nun, "gut" ist ein vager Begriff, aber Sie haben "billig" gesagt ...

Die einfachste Lösung dafür, die ich selbst gesehen und getestet habe, ist die Verwendung eines PNP-Transistors und eines RC-Netzwerks . Das folgende Beispiel ist für 9600 Baud vorgesehen, daher werden ein 22k-Widerstand und ein 1n5-Kondensator verwendet. Diese Werte würden für unterschiedliche Baudraten geändert.

Dies ist keine elegante Lösung, aber sie ist einfach und kann aus dem Teilefach erstellt werden.

Hier ist das Schema:

schematic

simulieren diese Schaltung - Schema erstellt mit CircuitLab sup>

#3
+3
supercat
2013-04-17 03:12:52 UTC
view on stackexchange narkive permalink

Am besten verwenden Sie wahrscheinlich einen kleinen Mikrocontroller (wahrscheinlich mit einem UART, obwohl Software-Bit-Banging möglicherweise ausreicht), der ein "Dateneingang" -Signal aufnimmt und sowohl "Datenausgang" als auch "Sendefreigabe" generiert. Sie sollten wahrscheinlich einen flankengetriggerten Interrupt am "Dateneingang" -Pin haben, der Ihr "Datenausgang" -Signal aktiviert, noch bevor ein Byte vollständig empfangen wurde, damit Sie mit dem Senden beginnen können, sobald das vollständige Byte empfangen wurde (es ist) Normalerweise ist es eine gute Idee, die Übertragungsfreigabe kurz vor Beginn der Übertragung zu aktivieren. Schalten Sie nach Ablauf einer bestimmten Zeitspanne ohne fallende Flanke oder ohne vollständig empfangenes Zeichen den Sendefreigabepin aus.

Der obige Ansatz würde eine Verzögerung von einer vollen Zeichenzeit zwischen dem Empfang des Prozessors einführen Daten und wenn es aus dem Draht geht. In einigen Fällen kann es wünschenswert sein, diese Zeit zu verkürzen. Dies würde die Verwendung eines Software-Bit-Bang-UART anstelle eines Hardware-UART erfordern. Es wäre schwierig, das Timing bei höheren Bitraten korrekt zu machen, aber man könnte das Timing der eingehenden und ausgehenden Daten viel feiner steuern.

Das klingt gut. In der Stromschaltung haben die Hardware-Leute entworfen, dass der Sendeantrieb des RS-485-Treiberchips mit dem TTL-Sendestift verbunden ist, sodass bei jedem * Bit * die Übertragung aktiviert ist. Ich kann jedoch nicht sehen, wie dies zuverlässig funktionieren würde, werde es aber in den nächsten Tagen testen ...
Sie können sich auf die Tatsache verlassen, dass eine freie RS-485-Leitung normalerweise hoffentlich einen Markierungszustand annimmt. Bei niedrigen Baudraten in relativ ruhigen Umgebungen könnte dies funktionieren. Es könnte sogar mit moderaten Baudraten arbeiten, wenn die Freigabeleitung langsamer reagiert als die Datenleitung (so dass jeder Übergang von Leerzeichen zu Markierung kurz eine richtige Abstandsbedingung ausgibt, bevor sie in den Leerlauf geht). Die Störfestigkeit wäre jedoch nicht sehr gut.
#4
+2
Andy aka
2013-04-17 14:22:38 UTC
view on stackexchange narkive permalink

Ich habe eine Schaltung gesehen, die dieses Problem wahrscheinlich gelöst hat. Die CPU war ein Slave auf dem RS485 und wartete daher normalerweise im Empfangsmodus auf die richtige ID-Nachricht, woraufhin sie ihre Antwort senden würde. Der RS485-Chip wurde durch die Vorderflanke des 1. Bits in der Datenantwort, die von der CPU beim Antworten kam, sendungsfähig gemacht. Eine Diode, ein Kondensator und ein Widerstand haben es geschafft, den Chip schnell in den Sendemodus zu versetzen, und aufeinanderfolgende Datenübergänge hielten ihn im Sendemodus. Wenn die Übertragung beendet war, entlud sich die Kappe durch den Widerstand und nach einigen zehn Millisekunden kehrte der Chip in den Empfangsmodus zurück.

Hierbei gibt es zwei Probleme: Das erste übertragene Bit war um etwa 1% kurz 10% und dies kann zu Problemen führen. Ich bin sicher, dass eine bessere Schaltung entwickelt werden könnte, aber es wird immer eine Verkürzung des 1. Bits geben, da dies verwendet wird, um ein Sendesignal zu "erkennen" und dem RS485 das Senden zu ermöglichen. Das zweite Problem ist, dass die Sendefreigabeschaltung einige zehn Millisekunden lang aktiv blieb, nachdem die Übertragung vom Slave beendet wurde, und dies verhindert natürlich, dass der Master während dieses Zeitraums einen anderen Slave abfragt.

Wenn dies der Fall ist "Probleme" sind OK, dann kein Problem, es wird funktionieren

Wenn die RS-485-Leitung eine "Markierungs" -Zustand zuverlässig hält, wenn niemand sendet, könnte man die Dinge wahrscheinlich vereinfachen, indem man ein Schieberegister hat, das mit einer Rate läuft, die viel schneller als die Bitrate ist, wobei der mittlere Abgriff als Daten für die verwendet wird RS-485-Chip und das "UND" vieler anderer Abgriffe als "Freigabe". Wenn man beispielsweise einen Takt hätte, der mindestens das 16-fache der Baudrate beträgt, könnte man ein 2x64-Bit-Schieberegister mit Abgriffen alle 16 Bit verwenden. Wenn z.B. Die Uhr war 32x die Baudrate, dann wurde das Gerät zwei Bit-Zeiten aktiviert, bevor Daten zu ihm eingegeben wurden, und ...
... bleiben nach der letzten fallenden Flanke zwei Bit-Zeiten aktiviert. Zwei Bitzeiten sollten ausreichend Zeit für den Fahrer sein, um mit dem Markieren zu beginnen. Selbst wenn der Treiber in der Mitte des Typs deaktiviert ist, sollte die Linie bis zum Ende markiert bleiben. Wenn man sich nicht darauf verlassen kann, dass die Leitung in einem Markierungszustand bleibt, wenn niemand sendet, sollte man dem Fahrer vor dem Senden eine volle Bytezeit ermöglichen.
#5
+1
Shane
2014-12-17 09:41:22 UTC
view on stackexchange narkive permalink

Ich habe nach einer ähnlichen Lösung gesucht, aber ich brauchte ein sehr genaues Timing, da der Bus zu 90% ausgelastet ist. Ich konnte es mir nicht leisten, mehr als ein halbes Stück Überlauf zu haben. Ich muss den Tx innerhalb von 2uS nach dem Ende des Stoppbits zuverlässig deaktivieren.

Meine Lösung bestand darin, das Startbit mit einem Flip-Flop vom Typ S / RD zu verriegeln und dann in einen LTC-Timing-Chip zu treiben ( LTC6994) bieten diese eine Genauigkeit von 3% bei der von mir benötigten Baudrate von 230 kbps. Der Ausgang des Timing-Chips steuert den Reset beim Typ D.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...