Hallo alle miteinander,
ich wollte fragen, welchen wert F_CPU bei meinem atmega644 hat, wenn das
Fuse bit auf Int. RC Osc gesetzt ist? Ich dachte es wäre 1000000.
Allerdings empfange ich mit hterm nur falsche zeichen, wenn ich von
1000000 ausgehe.
Viele Grüße
Pedde
Standardantwort hier: Steht im Datenblatt. Soll ich für dich nachgucken
oder wie?
Bei vielen AVRs ist der Int. Osc eingestellt mit 8 MHz und die CHKDIV8
Fuse gesetzt, so dass er mit 1 MHz läuft.
Also wäre 1.000.000 richtig.
gruß cyblord
Hi,
ja das habe ich im Datenblatt gelesen, ich war mir nur unsicher, da die
Kommunikation nicht funktioniert.
Stimmt dann was an meiner initilisierung nicht?
Hier mal ein Code-Ausschnitt:
1
#ifndef F_CPU
2
#define F_CPU 1000000 /* evtl. bereits via Compilerparameter definiert */
pedde schrieb:> Allerdings empfange ich mit hterm nur falsche zeichen, wenn ich von
Die 1Mhz sind nicht besonders genau. Besser wäre ein Quarz.
Aber ok. Welches Zeichen siehst du denn im Hterm?
>
1
>USART_Transmit(124);
2
>
Das Zeichen mit dem ASCII Code 124 ist ein '|'. Du kannst dir natürlich
selbst (und deinem Leser) das Leben schwerer machen als es sein muss,
aber einfacher ist es, wenn du davon Abstand nimmst, die ASCII Codes
(noch dazu dezimal) selber hinzuschreiben, sondern ganz einfach
1
USART_Transmit('a');
schreibst. Dann kennt sich jeder aus, was in HTerm sichtbar sein müsste,
auch ohne zuerst eine ASCII Tabelle konsultieren zu müssen.
ich hab schon andere baudraten (z.B. 9600 oder 2400) probiert, erhalte
aber trotzdem immer einen fehler, oder funktioniert die uart
kommunikation bei 1mhz mit keiner baudrate?
pedde schrieb:> 188 als dezimal, sprich: 10111100 bzw. 0xBC
1
188_dez 10111100
2
124_dez 01111100
Hmm. Interessant.
Da die Übertragung mit dem LSB beginnt, sieht es danach aus, als ob
deine Baudrate (abegeleitet aus der F_CPU) ein klein wenig zu viel
daneben ist.
>könnte es auch an dem FTDI FT232RL liegen, dass die Daten falsch>ankommen?
Nee, an falscher Baudrate liegt das. Der UART selbst
arbeitet doch schon, sonst würdest du gar keine Zeichen sehen.
Zeig mal den Rest von deinem Programm. Und lass mal ne LED
im Sekundentakt blinken. Wer weiss ob deine F_CPU auch stimmt
bzw deine Fuses richtig gesetzt sind.
pedde schrieb:> Hier mal mein gesamter code. Ist allerdings noch ein bisschen> unstrukturiert, da ich erst angefangen hae:
Alles schön und gut.
Aber können wir uns darauf einigen, erst mal die UART losgelöst von
allem anderen in Gang zu bringen?
Wenn 115kBaud bei 1Mhz zu viel Abweichung haben, dann musst du dir eben
eine Baudrate suchen, bei der die Abweichung kleiner als 3% bleibt.
Entweder rechnen oder im Datenblatt nachsehen - da gibt es Tabellen.
UBRR0H = UBRRH_VALUE;
UBRR0L = UBRRL_VALUE;
Ich sehe nirgends eine Definition von UBRRH_VALUE oder UBRRL_VALUE.
Der Code dürfte so gar nicht durch den Compiler gehen.
>> Ich sehe nirgends eine Definition von UBRRH_VALUE oder UBRRL_VALUE.>>#include <util/setbaud.h>
Ok, hab ich noch nie benutzt.
Für 9600 Baud muss dann ein
#define USE_2X 1
oben in den Code.
Oder besser 4800 Baud nehmen. Dann gehts mit und ohne USE_2X.
>Mit R/C Oszillator kann man sowieso nicht erwarten, dass die UART>Schnittstelle funktioniert.
Table 28-10. Calibration accuracy of internal RC oscillator.
Frequency VCC Temperature Calibration accuracy
Factory calibration 8.0MHz 3V 25°C ±10%
Also das bekommen andere Hersteller besser hin;)
Stefan schrieb:> Mit R/C Oszillator kann man sowieso nicht erwarten, dass die UART> Schnittstelle funktioniert.
Aber in Praxis funktioniert das nunmal meist. Und wenns bei einem
Anfänger nicht tut, liegs selten am ungenauen Osc.
gruß cyblord
>Aber in Praxis funktioniert das nunmal meist. Und wenns bei einem>Anfänger nicht tut, liegs selten am ungenauen Osc.
Dann bleibt wohl nur noch die blinkende LED und ein Osci
oder die Soundkarte um festzustellen wo sein F_CPU nun
wirklich liegt.
Eine fehlende GND Leitung wäre noch ne Möglichkeit.
Aber eigentlich passt es ja schon fasst:
188_dez 10111100
124_dez 01111100
>hab den code jetzt mal auf USART_Transmit( 'a' ); geändert,>nun empfang ich 0xA1, was allerdingsa auch das falsche zeichen ist.
Das kleine a ist 0x61.
0xA1 10100001
0x61 01100001
Witzigerweise scheinen nur die ersten beiden Bits verdreht zu werden.
also ich hab nochmal alle grounds gecheckt und es scheint mir wirklich
so, als ob ein pin etwas wackelig verlötet war. Er hatte zwar kontakt,
aber wohl etwas zu wenig. Auf jedenfall bekomm ich jetzt ein kleines
'a'.
Besten Dank für eure Tipps und Hilfe!
> Witzigerweise scheinen nur die ersten beiden Bits verdreht zu werden.
Das sind die höherwertigsten Bits, die als letzte übertragen werden. Was
meine Annahme bestätigt, dass die Frequenz des Oszillators nicht genau
genug ist.