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?
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.
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...
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
schön, dass du etwas von deinem Code herausgerückt hast. Wie wäre es mit mehr?
ok, sorry... :) aber abgesehen von dem, was uns der CodeWizard ausgespuckt hat, sind's ja nur wenige Zeilen von uns geschriebener Code...
oh, in der letzten Zeile stand eigentlich noch: UDR = 'x'; Hatten das nur mal zum Testen geändert...
> 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 ...
> while (!(UCSRA) & (1<<UDRE));
Falsch abgeschrieben, gelle? Da ist eine Klammer an der falschen
Stelle! Richtig wäre:
while (!(UCSRA & (1<<UDRE)));
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...
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!
> 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.