Faktor 10 in der UART-Kommunikation

OP #3362255
Lesenswert?

Hallo zusammen!

Ich habe z.Z. ein Problem mit einem Atmega64 bei dem die 
UART-Kommunikation nicht so funktioniert wie gewollt. Heißt im Klartext, 
dass in meinem Terminalprogramm trotz Einstellung der richtigen 
Baudrate, der richtigen Anzahl der Stopbits und keinem Paritätsbits nur 
"Müll" angezeigt wird.

Die Berechnung der Baudrate und die Initialisierung der USART Register 
wurden wie folgt relisiert:
1
#define F_CPU 16000000UL
2
#define BAUD_LOW 19200UL  //19.2 kBaud
3
#define UBRR_BAUD_LOW ((F_CPU/(16*BAUD_LOW))-1)
.
.
.
1
UBRR1H = UBRR_BAUD_LOW >> 8;  
2
UBRR1L = UBRR_BAUD_LOW & 0xFF;
3
UCSR1A = 0x00;
4
UCSR1C |= (1<<UCSZ11)|(1<<UCSZ10);
5
UCSR1B |= (1 << TXEN1) | (1 << RXEN1) | (1 << RXCIE1);

Überprüfe ich im Debugging die Register, werden diese auch alle richtig 
gesetzt. UBRR hat den Wert 51 und die oben gesetzten Bits sind auch alle 
da!
Mit dem Oszi habe ich jetzt die Breite eines Bits ermittelt (ca. 52ms). 
Diesen Wert mit 10 (Startbit, Stopbit und 8 Datenbits) multipliziert 
ergibt eine Baudrate von 1923, was sich verdächtig um den Faktor 10 zu 
der gewollten Baudrate unterscheidet. Allerdings fehlt mir mittlerweile 
absolut die Idee woran es noch liegen könnte.

Noch eine Anmerkung zum Quarz:
- Die Fuses sind alle richtig gesetzt! CKOPT ist gesetzt und 
EXTHIFKTALRES_16KCK_64MS.
- Die Quarzfrequenz konnte ich leider nicht direkt messen, da ich keinen 
diferentiellen Tastkopf zu Verfügung habe. Ich habe jedoch die ISP Clock 
auf 4MHz (1/4 * 16MHz) eingestellt und hier war ein Programmieren noch 
möglich. Drüber hinaus war das programmieren nicht mehr möglich. Damit 
habe ich für mich erst einmal ermittelt, dass der Quarz auf der 
richtigen Frequenz von 16MHz schwingen muss.

Ich hoffe, ihr habt eine gute Idee woran es noch liegen könnte!


Gruß
Andreas
#3362269
Lesenswert?

Hi
Um die Taktfrequenz mal so pi und dicken Daumen zu testen, lass doch 
eine LED über den Timer Blinken. Bei 16 MHz einen Vorteiler von 8000 
einstellen und die ISR im CTC Mode (Comparewert 2000-1) entsprechend 
programmieren. Dann solltest du eine Blinkfrequenz von 0,5 Hz haben.
Gruß oldmax
Gast #3362349
Lesenswert?

Parameter stimmen offenbar, nur deine Scope-Messung und deren 
Interpretation nicht, wie die Vorposter schon feststellten...

Hast du einen Schnittstellentreiber (MAX232 o.ä.) zwischen µC und 
serieller Schnittstelle des Computers mit dem Terminalprogramm?
Der invertiert nämlich die Daten, was auch erforderlich ist.
OP #3362733
Lesenswert?

der alte Hanns schrieb:
> Die Herren reden vermutlich von µs !

Oh, Sorry! Klar waren es µs! Da hab ich mich im Eifer des Gefechts 
vertippt!

Thosch schrieb:
> Hast du einen Schnittstellentreiber (MAX232 o.ä.) zwischen µC und
> serieller Schnittstelle des Computers mit dem Terminalprogramm?

Ich glaube, Du hast mir hier den Schupps in die richtige Richtung 
gegeben! Da die Platine nicht von mir ist, ich es aber als 
selbstverständlich erachte einem Pfostenwannenstecke für die serielle 
Kommunikation auch direkt einen RS232 Pegel mitzugeben hatte ich das gar 
nicht auf dem Schirm! Der Hersteller der Platine hat hier keinen 
Pegelumsetzter zwischen µC und Postenwanne. Das erklärt natürlich alles! 
Manchmal ist es echt sooooo einfach und man sieht den Wald vor lauter 
Bäumen nicht!!! :-(

Stefan Ernst schrieb:
> Bei einer stinknormalen seriellen Schnittstelle ist
> Baudrate = Bits/Sekunde

Und das hat dann auch noch den abweichenden Wert erklärt! Da ich aus der 
Fernmeldetechnik komme und hier Baud = Zeichen/Sekunde ist war das für 
mich neu! Man lernt halt nie aus!

Vielen Dank für Eure Kommentare!

Gruß
Andreas

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren