Hallo Forum!
Ich habe lange probiert, aber ich komme einfach nicht weiter. Ich möchte
mit dem UART des ATmega32 in einer Schleife ein Zeichen an den Rechner
senden, erhalte aber statt des abgesendeten "a" ein großes "O". Ursache
ist ja nun meistens falsche Baudrate durch falsche Taktfrequenz, aber
folgende Punkte sind schon überprüft worden:
- Taktfrequenz 16MHz, externer Quarz - getestet mit delay.h und LED:
stimmt
- Wert für 38400 BAUD in UBRR (aus Datenblatt) ist 25, wird auch korrekt
berechnet
- UBRRH wird vor UBRRL beschrieben
- externe Beschaltung mit MAX232 okay, da bin ich sicher, da es sich um
ein fertiges Eval-Board handelt und in anderen Projekten schon
funktioniert hat.
Ich komme echt nicht mehr weiter, wäre nett, wenn von euch jemand auf
den (minimalistischen) Quellcode schauen kann - vielleicht sehe ich den
Wald vor lauter Bäumen nicht:
Danke,
Elmo
ermal muss in deiner uart_init
" UBRRH = UBRR_VAL >> 8; //Baudrate setzen
UBRRL = UBRR_VAL;"
ganz an den schluss und nicht an den anfang (steht so im datenblatt)
dann ist dies überflüssig geworden, da in der gcc von 2008 die schleife
in der _delay_ms schon mit drin ist, falls die übergebene zahl zu gross
ist
" for (i=0; i<100; i++)
{
_delay_ms(10);
}
"
ermal muss in deiner uart_init
" UBRRH = UBRR_VAL >> 8; //Baudrate setzen
UBRRL = UBRR_VAL;"
ganz an den schluss und nicht an den anfang (steht so im datenblatt)
das habe ich probiert, brachte keine Änderung :-(
Das mit der Schleife wusste ich nicht, habe aber auch noch ne relativ
alte gcc-Version - werde mir die neue mal ziehen, der UART sollte aber
auch mit dem alten funktionieren...
noch ne Idee?!
evtl. liegt es ja nur an der interpretation des zeichens am pc, mit was
empfängst du, hyperterminal?
probier mal ein anderes zeichen ,z.b ein 'b' und schau ob der
zeichenabstand beim empfangen der gleiche ist
a-->O
b-->P
etc.
dann sollte es eher an der interpretation der ascii zeichen liegen
Zusatzinfo:
Ich weiß nicht, ob das was zu sagen hat, aber der UART sendet nur was,
wenn der ISP-Stecker ABGEZOGEN (also nicht aufgesteckt, wie bei
fehlender Masse) ist. Die Takt-Kontroll-LED blinkt so, oder so. Kann es
irgendwie damit zusammenhängen?
hmm, wenn ich statt des "a" ein "b" sende, erhalte ich das Zeichen "'"
(ascii 39) und nicht "O" (ascii 79). Verwende das Terminalprogramm von
Br@y++ - hab's aber auch schon mit Hyperterm getestet, da ist es
dasselbe.
>>Ich weiß nicht, ob das was zu sagen hat, aber der UART sendet nur was,>>denn der ISP-Stecker ABGEZOGEN (also nicht aufgesteckt, wie bei>>fehlender Masse) ist. Die Takt-Kontroll-LED blinkt so, oder so. Kann es>>irgendwie damit zusammenhängen?
also dass kann nicht sein, dass ein eingesteckter isp stecker einen
einfluss hat. habe so etwas (verwende mkll) noch nie festgestellt,
funktionierte soweit immer tiptop.
ergo -> hardware checken...
nein, eine FEHLENDE Masseverbindung kann's ja nicht sein, wenn das
Senden nur funktioniert, wenn KEIN ISP angesteckt ist...
Hardware checken habe ich im Rahmen meiner Möglichkeiten gemacht, MAX232
auch ausgetauscht - selbes Resultat wie bisher :-(
Wie gesagt, bei anderen Projekten hat das Board auch schon funktioniert,
ist das RN-Control von Roboternetz.
Meine bisherigen µC-Erfahrungen reichen auch relativ weit über UART
hinaus, deswegen könnte ich durchdrehen, dass ich schon daran scheitere
;-)
>>Ich weiß nicht, ob das was zu sagen hat, aber der UART sendet nur was,>>denn der ISP-Stecker ABGEZOGEN (also nicht aufgesteckt, wie bei
Beim MK-II ist es so, dass bei eingestecktem ISP-Stecker und
ausgestecktem USB-Stecker der RESET-Pin auf low ist und das System
steht.
Hast du evtl. Fuses falsch gesetzt (CKDIV8 oder so?)
CKDIV8 gibts glaube ich gar nicht beim mega32, oder? Jedenfalls habe ich
in PonyProg nicht die Möglichkeit die Fuse zu setzen...ansonsten sind
CKSEL und CKOPT alle auf 1; SUT1=1, SUT0=0...das stimmt doch so für
externen 16MHz-Quarz, oder? µC läuft auf jeden Fall mit dem externen
Quarz, da er stehen bleit, wenn ich den Quarz rausziehe...
Stimmt, was "ich" schreibt! F_CPU muss vor dem include von delay.h
bekannt sein.
Ansonsten: Hast du schon die Verbindungen im Loopback getestet?
Also beim (weniger wichtigen) PC Test RS232 Kabel am Evalboard abziehen,
Pins 2 und 3 verbinden und dann PC was senden lassen. Es sollte als Echo
auf den PC zurückkommen. Damit ist die PC-Schnittstelle OK und das Kabel
physikalisch OK.
Beim µC Test RS232 Kabel am Evalboard abziehen und an der Buchse vom
Evalboard Pins 2 und 3 verbinden. Programm schreiben, welches Zeichen
sendet und empfängt. Gesendetes und Empfangenes vergleichen und LED
schalten, wenn ungleich. Damit ist der MAX232, die Verbindungen und der
UART Port am AVR physikalisch OK.
Welches Evalboard benutzt du, damit ich mir mal den Schaltplan ansehen
kann. Deine Beobachtung mit dem ISP-Stecker macht mich neugierig. Und:
Welchen ISP-Programmieradapter benutzt du?
Danke Stefan!
Während du das geschrieben hast, hatte ich die selbe Idee, nochmal die
Verbindung zu checken (Loopback)...nachdem dies nicht funktionierte hab
ich mir das Kabel nochmalgenauer angesehen und - ich traue mich das gar
nichtg zusagen, mach's aber trotzdem, weil mir so viele geholfen haben -
festgestellt, dass zwar RX richtig angeschlossen war, aber TX und GND
vertauscht waren ... mich wundert nur, warum ich dann trotzdem etwas
empfangen habe (wenn auch nur Müll).
Jedenfalls vielen Dank an alle, jetzt klappt's :-)
PS: Ihr könnt jetzt anfangen, euch über diesen Idiotenfehler lustig zu
machen :-)
Hi
>PS: Ihr könnt jetzt anfangen, euch über diesen Idiotenfehler lustig zu>machen :-)
Wenn du wüsstest, was Fachleute schon für Fehler gemacht haben.
MfG Spess