mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USART ATmega8515L


Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt die Baudrate?

...

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: inoffizieller WM-Rahul (Gast)
Datum:

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

Autor: Chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ok, sorry... :)

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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh, in der letzten Zeile stand eigentlich noch:
UDR = 'x';

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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht 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

...

Autor: johnny.m (Gast)
Datum:

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

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mit ner Taktrate von 3,6864 MHz funktioniert nun aber alles bestens!

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

...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.