ATmega168 UART Problem

[Armin B. (arminb)]

Ich habe ein Problem mit dem Hardware UART des ATmega168. Ich 
konfiguriere laut Datenblatt so, dass 8 Datenbits, kein Paritätsbit und 
1 Stopbit gesendet werden soll. Trotzdem ist es so, dass ich an der 
Gegenstelle (ein Raspberry Pi) 7 Datenbits einstellen muss, um korrekte 
Daten zu erhalten. Hat oder hatte jemand mal vielleicht das gleiche 
Problem und hat eine Lösung dafür parat?

Ich habe das Register UCSR0C wie folgt konfiguriert:

Bit   0:   0: TX rising, RX falling
Bit 2-1:  11: character size 8 bit
Bit   3:   0: 1 stop bit
Bit 5-4:  00: no parity
Bit 7-6:  00: asynchronous USART

Das Register UCSRC0B habe ich auf das Bit geprüft, das 9 Datenbits 
konfiguriert, es ist nicht gesetzt.

Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU 
ist 8MHz. Ich benutze weiters die UART Library von Peter Fleury 
(http://homepage.hispeed.ch/peterfleury/group__pfleury__uart.html)

[Dietrich L. (dietrichl)]

Armin B. schrieb:
> Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU
> ist 8MHz.

Du weißt, dass der interne Oszillator nicht sehr genau ist? Eventuell 
musst Du die Baudrateneinstellung noch etwas trimmen (oder den 
Oszillator).

Gruß Dietrich

[Spess53 (Gast)]

Hi

Welche Baurate?

Der interne RC-oszillator ist nur sehr bedingt für die serielle 
Kommunikation geeignet. Erstens läuft er selten genau auf 8MHz und 
zweiter ist er nicht stabil.

MfG Spess

[Armin B. (arminb)]

Bei jeder Baudrate von von 2400-38400 tritt dasselbe Problem auf. Meinst 
du ich sollte einen externen Quartz verwenden?

[Dietrich L. (dietrichl)]

Armin B. schrieb:
> Bei jeder Baudrate von von 2400-38400 tritt dasselbe Problem auf. Meinst
> du ich sollte einen externen Quartz verwenden?

Wenn es am Frequenzfehler des Oszillators liegt, ist der prozentuale 
Fehler ja auch bei jeder Baudrate gleich.
Mess doch mal den Ausgang TX mit einen Scope eine Bitlänge, um den 
Fehler abzuschätzen.

Statt einem externen Quarz kannst Du ja auch mal mit der 
Baudrateneinstellung im ATmega168 spielen.

Gruß Dietrich

[Armin B. (arminb)]

> Mess doch mal den Ausgang TX mit einen Scope eine Bitlänge, um den
> Fehler abzuschätzen.

Leider besitze ich keine Messinstrument, dass mir derartiges anzeigen 
könnte. :o)

> Statt einem externen Quarz kannst Du ja auch mal mit der
> Baudrateneinstellung im ATmega168 spielen.

Das habe ich gemacht. Ich habe controllerseitig und entsprechend an der 
Gegenstelle alle Baudraten von 2400-38400 ausprobiert.

[Peter II (Gast)]

Armin B. schrieb:
> Statt einem externen Quarz kannst Du ja auch mal mit der
>> Baudrateneinstellung im ATmega168 spielen.
> Das habe ich gemacht. Ich habe controllerseitig und entsprechend an der
> Gegenstelle alle Baudraten von 2400-38400 ausprobiert.

er meint: du sollte einfach mal den wert von UBRR0 ändern, also nicht 
die werte aus dem Datenblatt. Einfach mal +2 oder -2 verwenden.

[Armin B. (arminb)]

Ich habe nun einen externen Quarzoszillator konfiguriert und 
angeschlossen. Jetzt funktioniert es wie gewollt. Vielen Dank für eure 
Hilfe und Hinweise!

[Klaus (Gast)]

War vielleicht auch die CLKDIV8 Fuse so gesetzt, das der intern mit ca. 
1 MHz gelaufen ist?

Fragt Klaus

[Armin B. (arminb)]

Klaus schrieb:
> War vielleicht auch die CLKDIV8 Fuse so gesetzt, das der intern mit ca.
> 1 MHz gelaufen ist?

Nein, wie ich schon sagte:

> Ich benutze den internen Oszillator ohne Teiler, das heißt mein F_CPU
> ist 8MHz.

[Michael (Gast)]

Armin B. schrieb:
> Das habe ich gemacht. Ich habe controllerseitig und entsprechend an der
> Gegenstelle alle Baudraten von 2400-38400 ausprobiert.

Das Durchprobieren der Baudraten bringt nix. Wenn die Frequenz 5% falsch 
ist, ist sie 5% falsch - egal wie weit sie durch den Baudratengenerator 
runtergeteilt wird.

Sende ein Zeichen, was im letzten Bit die gleiche Polarität hat, wie das 
Stop-Bit, variiere bei eine Baudrate von z.B. 2400 Bd den Teilerfaktor 
am µC um die im Datenblatt angegebenen Werte und guck, zwischen welchen 
Werten der PC das Zeichen richtig empfängt.