AVR USART: Eine Byte-Zeit warten

Bernhard schrieb:

> Gibt es dafür eine bessere Möglichkeit als mit _delay_us oder Timern zu
> arbeiten?

Leider nicht.

> Beim Abschalten des internen Transmitters per TXEN funktioniert der TXC0
> nicht mehr und man kann leider auch temporär den TXD pin per DDR
> Register nicht auf Input schalten.

So ist es. Der Pinfunction-Override ist leider nicht umgehbar und starr 
an TXEN gekoppelt.

Ich find's auch Scheiße. Wäre es anders, könnte man die USART, die 
heutzutage immer seltener als solche benötigt wird, oftmals als 
zusätzlichen Timer mit durchaus interessanten Fähigkeiten benutzen. Das 
gilt genauso für SPI und (teilweise) USI. Könnte alles mit nur geringem 
zusätzlichen Hardwareaufwand viel universeller nutzbar sein.

Aber es ist halt so, wie es ist, man muß sich mit den Gegebenheiten 
abfinden.

@Peter: Die TXEN-Leitung ist bei manchen Designs leider fest auf TXD 
verdrahtet um sich einen zusätzlichen IO Pin zu sparen. Was auch immer 
sich der Entwickler dabei gedacht hat :)

@c-hater: Ja, es könnte alles viel universeller sein aber mal im Ernst, 
wir sprechen hier von ATmegas... Die sind nicht für sowas gedacht.
Für mächtigere Peripherie und IO-Module geht man dann sowieso auf z.B. 
STM32

@Peter: Dass die Lösung ohne TXEN nicht gut ist, ist mir schon klar.
Die Pause braucht der Master um wieder auf Empfang zu schalten, dabei 
macht es keinen Unterschied ob ich ein Gerät mit fehlerhafter 
RS485-Schnittstelle am Bus habe oder nicht.
Wenn wir uns jetzt weiter an dem Gerät mit der defekten Schnittstelle 
aufhängen bringt das niemanden weiter.

Ich werde mich nun wieder der Pause widmen und diese per _delay_us 
implementieren.

Bevor ich nun einen neuen Thread starte, ist bekannt dass sich die 
beiden USARTS in größeren AVRs wie dem 1284 gegenseitig beeinflussen? 
Liegt da evtl. wie damals beim 323 ein Bug im Chip verborgen?

Wenn Atmel dazu nichts in den Errata schreibt, ist das denen zumindest 
nicht bekannt.

Wie äussert sich denn die Beeinflussung?

Oliver

Der USART1 hat eine fest eingestellte Baudrate und arbeitet im 
Hintergrund problemlos.

Auf dem USART0 kommen Daten mit falscher Baudrate an und es wird das Bit 
FE0 gesetzt (und dann in der ISR gemeinsam mit UDR0 wieder ausgelesen).

Auf dem USART1 werden dann aber auch Fehler gemeldet obwohl die 
Peripherie dort mit dem USART0 gar nichts zu tun hat.
Die Registernamen FE0 im UCSR0A für USART0 und FE1 im UCSR1A für USART1 
werden korrekt abgefragt.

Das Problem ist nicht kritisch, ich wiederhole dann einfach die 
Nachricht. Es ist nur komisch und vielleicht hat ja jemand das auch 
schonmal festgestellt.

Ein Probeaufbau bringt bei mir keinen Fehler der beschriebenen Art:
USART1 läuft korrekt durch trotz FE-Fehler auf USART0.