Hallo, ich setze gerade ein System mit einem RS485 Bus auf. Es unterhalten sich dabei mehrere µC's. Auf dem Oszi sehe ich, das meine Controller auf die Anfragen sehr zügig antworten ( um die 100µs). Immerhinn ist das weniger als 1 Byte auf der Leitung zu sehen ist (57K6 Baud) Macht es Sinn die Antwortzeiten etwas verzögern? Macht Ihr das auch so und wenn ja wie? Ralf
Ralf schrieb: > Macht es Sinn die Antwortzeiten etwas verzögern? Es kann welchen haben, wenn die Sender-/Empfänger-Umschaltung des Busmasters etwas träge ist, wie z.B. bei einem mit einem RS232-zu-RS485-Konverter an einer normalen PC-RS232-Schnittstelle aufgebautem System. Da muss der PC die Umschaltung nämlich "von Hand" mit einer Handshakeleitung vornehmen. UARTs mit Hardwareunterstützung für die RS485-Umschaltung gibt es auf manchen PCI-Karten (Beispielsweise welche mit UARTs von Oxford Semiconductor/PLX) , und manche USB-Seriell-Bridges haben das auch, wie z.B. die von FTDI. Die normale Onboard-Schnittstelle des PCs aber hat keine Hardwareunterstützung und ist daher beim Umschalten ziemlich träge, je nachdem wie geschickt die steuernde Software geschrieben ist, kann die Umschaltzeit auch mehrere Millisekunden betragen.
Ralf schrieb: > Immerhinn ist das weniger > als 1 Byte auf der Leitung zu sehen ist (57K6 Baud) > Macht es Sinn die Antwortzeiten etwas verzögern? Auf jeden Fall. Ein Prozessor, der den Treiber abschalten soll, muss dazu den UART pollen, ob alles gesendet ist, das kann durchaus etwas länger dauern. Gibt es keine Abschaltleitung, kann das mit einem Monoflop realisiert werden, aber entweder die Monoflopzeit ist grösser als eine Byteübetragung dauert (muss man also nach der Baudrate einstellen), oder man schaltet einfach ab und verlässt sich für restliche Einsen auf die Pullups, ist auch nicht so toll zuverlässig. Schadet also nicht, wenn sich der Antworter mehr als eine Bytelänge Zeit lässt, besonders wenn man nicht weiss wer am anderen Ende sitzt. Georg
Georg schrieb: > Schadet also nicht, wenn sich der Antworter mehr als eine Bytelänge Zeit > lässt, besonders wenn man nicht weiss wer am anderen Ende sitzt. > > Georg Bei meinen RS485 Sachen baue ich immer standardmäßig eine 1-2ms Antwortverzögerung ein. Früher hatte ich auch Monoflop gesteuerte RS232/RS485 Teile im Einsatz und da war es eigentlich eine gewisse Notwendigkeit wenn die Monoflops nicht super genau auf die Baudraten kalibriert waren. Mit dem FTDI232RL funktioniert die automatische SE-Umschaltung sehr gut. Gerhard
Gerhard O. schrieb: > Bei meinen RS485 Sachen baue ich immer standardmäßig eine 1-2ms > Antwortverzögerung ein. Früher hatte ich auch Monoflop gesteuerte > RS232/RS485 Teile im Einsatz und da war es eigentlich eine gewisse Warum ? RS485 steht normalerweise auf Empfang. Beim Senden und nur beim Senden ist RS485 auf Senden, was ja auch logisch ist, oder ? ;-D Georg schrieb: > Auf jeden Fall. Ein Prozessor, der den Treiber abschalten soll, muss > dazu den UART pollen, ob alles gesendet ist, das kann durchaus etwas > länger dauern. Nein, wieso soll da UART gepollt werden ? In der Tx_Complete ISR wird geprüft, ob das der letzte Byte ist. Falls ja, wird RS485 wieder auf Empfang geschaltet. Das dauert nicht länger als 1-2us (mit Abfrage). Da kann der Empfänger so schnell antworten wie er will, vor allem wenn mit Rx Interrupt gearbeitet wird.
Marc Vesely schrieb: > Gerhard O. schrieb: >> Bei meinen RS485 Sachen baue ich immer standardmäßig eine 1-2ms >> Antwortverzögerung ein. Früher hatte ich auch Monoflop gesteuerte >> RS232/RS485 Teile im Einsatz und da war es eigentlich eine gewisse > Warum ? > RS485 steht normalerweise auf Empfang. > Beim Senden und nur beim Senden ist RS485 auf Senden, was ja auch > logisch ist, oder ? ;-D > > Georg schrieb: >> Auf jeden Fall. Ein Prozessor, der den Treiber abschalten soll, muss >> dazu den UART pollen, ob alles gesendet ist, das kann durchaus etwas >> länger dauern. > Nein, wieso soll da UART gepollt werden ? > In der Tx_Complete ISR wird geprüft, ob das der letzte Byte ist. > Falls ja, wird RS485 wieder auf Empfang geschaltet. Das dauert nicht > länger als 1-2us (mit Abfrage). > Da kann der Empfänger so schnell antworten wie er will, vor allem wenn > mit Rx Interrupt gearbeitet wird. Weil ich damals auf der Hostseite nur einen Monoflop gesteuerten Adapter zur Verfügung hatte, welcher nicht superpräzise schaltete. Da war die Verzögerung am anderen Ende von Vorteil. Auf der anderen Seite funktionierte alles mit Interrupt und die Verzögerung war natürlich dort unnötig weil dort der serielle Sende-Treiber die HW-Umschaltung steuerte. Mit dem FTDI232RL war diese Maßnahme natürlich unnötig. Beim Monoflop gesteuerten RS232 zu RS485 Adapter mußte man immer die Monoflopschaltzeit de gewählten Baudrate anpassen sonst passierte es dass gesendete Zeichen abgeschnitten wurden. Gerhard
Marc Vesely schrieb: > In der Tx_Complete ISR wird geprüft, ob das der letzte Byte ist. > Falls ja, wird RS485 wieder auf Empfang geschaltet. Das dauert nicht > länger als 1-2us (mit Abfrage). Das kann man auf einem µC machen -- aber mach das mal auf einem PC mit Betriebssystem, bei dem Du den vorhandenen Devicetreiber der seriellen Schnittstelle nutzen musst. Davon abgesehen gibt es UARTs, die nur signalisieren, daß wieder ein Byte in den Ausgangspuffer geschrieben werden kann, nicht aber, wann das Sendeschieberegister leer ist. Da muss man mit Timern eine Byte-Zeit nach dem Signalisieren des leeren Sendepuffers warten ...
Rufus Τ. Firefly schrieb: > Das kann man auf einem µC machen -- aber mach das mal auf einem PC mit > Betriebssystem, bei dem Du den vorhandenen Devicetreiber der seriellen > Schnittstelle nutzen musst. Ralf schrieb: > ich setze gerade ein System mit einem RS485 Bus auf. Es unterhalten sich > dabei mehrere µC's. Auf dem Oszi sehe ich, das meine Controller auf die TO schrieb aber von µC's, deshalb meine Antwort. Natürlich trifft das nicht auf PC zu, besonders mit Windows, dann würde ich aber auch nicht antworten. Und RS485 ohne Interuptgesteuertes senden und empfangen ist witzlos. Rufus Τ. Firefly schrieb: > Davon abgesehen gibt es UARTs, die nur signalisieren, daß wieder ein > Byte in den Ausgangspuffer geschrieben werden kann, nicht aber, wann das > Sendeschieberegister leer ist. Da muss man mit Timern eine Byte-Zeit > nach dem Signalisieren des leeren Sendepuffers warten ... Sorry, ich war der festen Überzeugung es handelte sich um ein AVR. Woher ich das hatte, weiss ich jetzt selber nicht.
Marc Vesely schrieb: > Sorry, ich war der festen Überzeugung es handelte sich um ein AVR. > Woher ich das hatte, weiss ich jetzt selber nicht. Tja - nicht jede Formulierung in diesem Forum ist so eindeutig, daß sie nur exakt eine Interpretation zulässt. Das wirst Du mir zugestehen müssen; ich lese hier ziemlich viel, wo grundlegendes weggelassen wird, oder sich die Rahmenbedingungen urplötzlich ändern. Und da die Idee, einen PC o.ä. auch an einen RS485-Bus zu hängen, nun nicht völlig von der Hand zu weisen ist (und dem Threadstarter vielleicht nach einiger Zeit auch kommen könnte), halte ich meine Hinweise weder für fehlgeleitet noch irrelevant.
Rufus Τ. Firefly schrieb: > halte ich meine > Hinweise weder für fehlgeleitet noch irrelevant. Wow, ich auch nicht, sollte auch nicht so klingen.
Danke für Eure Antworten! Zur Vollständigkeit: Es handelt sich um einen reinen RS485-Bus unter µCs. Dieser wird auch niemals an einen PC angeschlossen werden. Gruß Ralf
Dann kannst Du auf die Verzögerung verzichten, wenn die beteiligten UARTs alle eine Signalisierung für "transmit shift register empty" haben.
Bitte 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.