Forum: Mikrocontroller und Digitale Elektronik USART ATmega8515L


von Chris (Gast)


Lesenswert?

Hallo,

wir haben folgendes Problem mit dem Senden von Daten vom o.g.
Controller auf einem STK500 an den PC (wir sind noch Anfänger in der
Thematik).

Wir gehen mal davon aus, daß alles richtig angeschlossen und richtig
gesteckt ist; es kommen ja teilweise Daten an, halt nur nie die
richtigen.

Zum ersten Testen haben wir nur eine printf-Anweisung in eine
Endlosschleife geschrieben und übers Terminal beobachtet, welches
Zeichen ankommt; es kamen zwar immer irgendwelche Hex-Zahlen, aber nie
die, die dem ASCII-Code der gesendeten Zeichen entsprochen haben.

Dann aus dem Handbuch einfach folgende zwei Zeilen rauskopiert:
while ( !( UCSRA & (1<<UDRE)) );
UDR = 'x';
aber dann kommt vom Compiler (CodeVision AVR) ständig die Meldung
"undefined symbol UDRE". Die zugehörigen Header-Dateien mega8515.h,
stdio und io.h sind eingebunden. Ebenso steht im compilierten asm-file
(wenn die fehlerhafte Zeile auskommentiert ist), als eine der ersten
Zeilen ".EQU UDRE=0x5", also sollte das Bit UDRE doch bekannt
sein...

Da wir in einigen Tutorials, Büchern und Google bislang erfolglos
nachgelesen/-gesucht haben, nun die Frage, was wir tun müssen, um
irgendein Zeichen korrekt angezeigt zu bekommen?

von inoffizieller WM-Rahul (Gast)


Lesenswert?

Habt ihr mal einen Blick ins Header-File geworfen?
Irgendwie hat CodeVision was mit dem UDRE vergessen.
Notfalls einfach per

#define UDRE 5

selbst definieren.

von Chris (Gast)


Lesenswert?

Zumindest kommt nun die Fehlermeldung des Compilers nicht mehr.
Im Header-File stand nur "#define USART_UDRE 11", also wenn man UDRE
durch USART_UDRE ersetzt, funktioniert es ebenfalls; nun ist noch die
Frage, welches von den beiden richtig ist?

Allerdings haben wir jetzt auch wieder dasselbe Problem wie mit der
printf-Anweisung: im Terminal wird was angezeigt, aber nie das, was wir
erwarten. Wenn man im Terminal disconnected und anschließend wieder neu
verbindet, dann erscheint häufig eine andere Hex-Zahl, die wie gesagt
für uns in keiner offensichtlichen Verbindung zum gesendeten Zeichen
steht. Und wenn man dann im Terminal von CodeVision von hexadezimal auf
ASCII-Modus umschaltet, erscheint gar nichts mehr...

von Hannes L. (hannes)


Lesenswert?

Stimmt die Baudrate?

...

von Chris (Gast)


Lesenswert?

Wir gehen davon aus...
Taktrate sind 4 MHz, für 9600 baud muss der Teiler ja 25 betragen und
das steht auch bei uns in UBRR

UCSRA=0x00;
UCSRB=0x18; // 0001 1000
UCSRC=0x86; // 1000 0110
UBRRH=0x00;
UBRRL=0x19; // 0001 1001

von inoffizieller WM-Rahul (Gast)


Lesenswert?

schön, dass du etwas von deinem Code herausgerückt hast. Wie wäre es mit
mehr?

von Chris (Gast)


Angehängte Dateien:

Lesenswert?

ok, sorry... :)

aber abgesehen von dem, was uns der CodeWizard ausgespuckt hat, sind's
ja nur wenige Zeilen von uns geschriebener Code...

von Chris (Gast)


Lesenswert?

oh, in der letzten Zeile stand eigentlich noch:
UDR = 'x';

Hatten das nur mal zum Testen geändert...

von Hannes L. (hannes)


Lesenswert?

> Wir gehen davon aus...
> Taktrate sind 4 MHz,

Woher nimmst Du die 4MHz??
Dass 4MHz für Baudrate nicht optimal ist, ist Dir bewusst?

http://www.hanneslux.de/avr/tipps/baudratenquarz.html

...

von johnny.m (Gast)


Lesenswert?

> while (!(UCSRA) & (1<<UDRE));
Falsch abgeschrieben, gelle? Da ist eine Klammer an der falschen
Stelle! Richtig wäre:
while (!(UCSRA & (1<<UDRE)));

von johnny.m (Gast)


Lesenswert?

Zur Erläuterung:
UCSRA ist am Anfang 0, d.h. "!(UCSRA)" ergibt 1 (logische Negierung),
also 0b00000001. "(1 << UDRE)" ist 0b00100000, also ergibt "!(UCSRA)
& (1 << UDRE)" immer 0. Die while-Schleife wird also nie ausgeführt,
solange UCSRA 0 ist.

Was so ne verrutschte Klammer doch alles bewirken kann...

von Chris (Gast)


Lesenswert?

Ja vielen Dank, jetzt funktioniert's, die letzten 3 Beiträge waren dann
ausschlaggebend!! :)

Natürlich war die Klammer falsch, aber selbst nachdem wir das geändert
haben, hat es immer noch nicht funktioniert... Mit ner Taktrate von
3,6864 MHz funktioniert nun aber alles bestens!

von Hannes L. (hannes)


Lesenswert?

> Mit ner Taktrate von 3,6864 MHz funktioniert nun aber alles bestens!

Das ist ja auch ein baudratentauglicher Takt... ;-)

...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.