Atmega128 USART Empfangsproblem von Zeichnketten

[PF (Gast)]

Hallo miteinander,

ich verzweifel hier gerade an einem Problem mit den UART des Atmega128. 
In kurzen Worten eine Erläuterung des bei meinem Vorhaben (Leider 
darf/kann ich den Code nicht ins Netz stellen...er wäre auch sehr 
umfangreich). Ich polle den Empfangspuffer bis ein Byte vvollständig 
empfangen wurde und schreibe es dann in ein Array. Sobald ein Timer 
abgelaufen ist, "schaue" ich mir die empfangenen Bytes an. Bisher hat es 
immer über einen USB->RS232 Adapter zwischen AVR und PC über HTerm 
fehlerfrei funktioniert. Nun habe ich es direkt an die RS232 
Schnittstelle eines PCs angeschlossen und bekomme recht reproduzierbare 
fehlerhafte Bytes. Hab daraufhin die Formel zur Berechnung für UBRR 
verändert und es wurde besser aber auch nicht  komplett fehlerfrei. 
Immer wieder sind einzelne Bytes fehlerhaft.
Als Formeln habe ich die 2 getestet:

#define F_CPU 16000000UL
#define BAUD 1155200UL

1. (F_CPU+BAUD*8UL)/BAUD*16UL)-1
  -> bei Nutzung des UBS Adapters fehlerfrei
  -> bei Nutzung der PC RS232 Schnittstelle fehlerbehafteter Empfang
2. FCPU/16UL/BAUD-1
  -> bei Nutzung des UBS Adapters fehlerbehaftet
  -> bei Nutzung der PC RS232 Schnittstelle fehlerbehafteter Empfang, 
aber
besser als bei der 1. Formel

Der Empfang basiert wie geschrieben auf:

uint8_t USART_getc(){
 while(!UCSR1A & (1<<RXC1))
 return UDR1;
}

do{
 data = USART_getc();
 data_array[loop_poll_count] = data;
 data = 0x00;
loop_poll_count++:
}while(...)


Komischerweise treten die fehlerhaften Bytes reproduzierbar für bestimme 
Hex-werte auf. Was könnte das Problem sein. Bringt ein schnellerer Quarz 
bspw. 32Mhz etwas?


Viele Grüße und vielen Dank und im Voraus.

[Karl H. (kbuchegg)]

> Bringt ein schnellerer Quarz bspw. 32Mhz etwas?

Nicht schneller. Der richtige!

> #define F_CPU 16000000UL
> #define BAUD 1155200UL

Das ergibt rund -3.5% Fehler in der Baudrate. Wenn jetzt die Gegenstelle 
ebenfalls eine größere Abweichung von der idealen Baudrate hat UND sich 
die beiden Fehler auch noch ungünstig addieren, dann bist du aus dem 
Korridor draussen, in dem problemlose Kommunikation noch funktioniert.


Daher: Formeln probieren ist gut. Aber du musst die auch für dich selber 
nachrechnen und feststellen, welcher Fehler sich ergibt. Alles was mehr 
als +-3% Fehler ergibt, ist schon hart an der Grenze.

Im Datenblatt gibt es Tabellen "Exmaples of Baud rate settings" in der 
auch die Fehler für häufige Taktfrequenzen angegeben sind. Bei 16Mhz und 
einer Baudrate von 76.8k beträgt der Fehler zb nur noch 0.2%, anstatt 
3.5% bei der doppelt so hohen Baudrate.

[PF (Gast)]

Oh Entschludige noch eine kleine Korrektur Baudrate ist 115200.

[PF (Gast)]

Hm ok schonmal Danke für die wirklich schnelle Antwort. Die Baudrate von 
115200 ist fest vorgegeben. Welche Möglichkeiten kommen denn dann in 
Betracht?

[Karl H. (kbuchegg)]

PF schrieb:
> Hm ok schonmal Danke für die wirklich schnelle Antwort. Die Baudrate von
> 115200 ist fest vorgegeben. Welche Möglichkeiten kommen denn dann in
> Betracht?

Du hast 2 Paramater an denen du drehen kannst
die Baudrate
die Taktfrequenz

Wenn die Baudrate fest vorgegeben ist, was bleibt dann noch?

Eben.

Wie gesagt: Im Datenblatt sind Tabellen für die Rechenfaulen. Such dir 
eine Taktfrequenz, bei der 115200 einen kleinen Fehler hat.

[Karl H. (kbuchegg)]

Hier
http://www.atmel.com/Images/doc2467.pdf
ist das Datenblatt.

Downloaden und aufschlagen auf Seite 193

Du willst wahrscheinlich was in der Nähe deiner 16Mhz.
Seite 195
14.7456MHz   115.2k  -  Fehler: 0%

Besser als 0% gehts nicht.

[PF (Gast)]

Ja danke euch :). Ich werde es mit dem Tausch des Quarzes mal versuchen. 
Hatte jetzt auch 18,432Mhz in Betrach gezogen. Mal schauen welcher 
verfügbarer ist.

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:

> Du willst wahrscheinlich was in der Nähe deiner 16Mhz.
> Seite 195
> 14.7456MHz   115.2k  -  Fehler: 0%
>
> Besser als 0% gehts nicht.

Für dich interessant:
Studiert man die Tabelle für 16Mhz, dann sieht man:
nimmt man das U2X Flag zu Hilfe, dann berechnen sich die 
Baudraten-Konstanten ein wenig anders, ABER: Der Fehler sinkt von 3.5% 
auf 2.5%
2.5% ist zwar auch noch nicht berauschend aber immerhin klein genug, um 
unter die ca. 3% Grenze zu fallen. Ob das in deiner spezifischen 
Konstellation schon klein genug ist, musst du ausprobieren.

[PF (Gast)]

Habe sogar mehr falsche Bytes mit dem U2X-Bit. Aber es ist anscheinend 
auch nur für das Senden relevant.