RS485-Bus Antwort vom µC verzögern

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.

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.

Dann kannst Du auf die Verzögerung verzichten, wenn die beteiligten 
UARTs alle eine Signalisierung für "transmit shift register empty" 
haben.