AVR UART

Johannes Bauer schrieb:

Mit meine beschränkten Kenntnissen würde ich versuchen einen Timer-Overflow irgendwie sinnvoll an einem Pin auszugeben und das anschliessend mit dem Oszi angucken. Dann ist zumindest klar ob der Takt stimmt. Ausserdem, guck mal ob das U2X Flag gesetzt oder gelöscht ist. Befindet sich bei Bit 1 im Usart Control and Status Register A (UCSRA) und muss für deine Taktrate, wenn ichs recht verstanden habe, gelöscht sein. (DOC2466.pdf@seite162) andernfalls muss UBRR auf 7 gesetzt werden (@seite167).

HTH, bye uwe

In article , Johannes Bauer writes: |> Hallo Gruppe, |> |> ich habe gerade ein komisches Problem mit einem Mega16 und dem UART. |> Betreibe das UART in Standardschaltung mit MAX232 - da gab's auch noch |> nie Probleme - aber jetzt liefert mir der AVR nur Müll. |> |> An XTAL1/2 hängt ein 7.3728 MHz Quarz, Fuses sind alle 1 |> (unprogrammiert). UBRR ist bei 115200 Baud 3 und ist auch so eingestellt. |> |> Wenn ich den AVR nun laufend übertragen lasse, kommt fast nichts an, was |> ankommt ist Müll. Wenn ich die Geschwindigkeit drossele, kommt was an, |> aber erwartungsgemäß Müll. |> |> Mit dem Oszi geguckt was so gesendet wird: Ein Bit ist 70us lang. |> Gesendet wird also mit 14,3 kHz, bei einer 8N1 Übertragung sind das also |> 12700 Baud! Wenn ich mit meinem Teiler von UBRR=3 zurückrechne komme ich

Nein, 14.3k. Start/Stop zählt mit rein.

|> damit auf einen MCU-Clock von 812 kHz - kann nicht sein, oder?

Hm.. 14.3k*16*4(!)=915.2kHz. Das mal 8 und man hat fast die 7.37MHz. Was ja wiederum recht nah an 2346904*PI liegt. D.h. könnte also auch Zufall sein... Das Mhz des RC-Oszillators passt da besser. |> Meine Vermutung war, dass der interne RC-Oszillator an ist: das kann ja |> aber bei den Fuses eigentlich nicht sein!

Wenn du schon ein Oszi hast: Klemm den XTAL-Ausgang auf den zweiten Kanal und triggere mit einer TX-Flanke. Wenn das Quarzsignal nicht sauber steht, sind die beiden Signale auch nicht synchron und der UART-Takt kommt wirklich von woanders. Allerdings sollte man dann eigentlich auch gar kein XTAL-Signal sehen....

Ah okay.

Das

woanders.

Durch den Tipp hab ich den Fehler schon näher eingegrenzt: der externe Quarz wird definitiv nicht benutzt. Bei meiner Messung daran habe ich probiert, die XTAL1 und XTAL2-Pins einfach mal kurzzuschließen - das UART sendet munter weiter Daten. Kein Reset, nichts.

Also tatsächlich der interne Oszillator.

Dann habe ich mich den Fuses zugewandt. Und irgendwie ist das mysteriös: Wenn ich die Fuses mit PonyProg brenne und danach einen Device Reset mache und sie wieder auslesen will, stehen sie alle immernoch auf 1! Funktioniert wohl das auslesen nicht richtig? Und nachdem ich die Fuses programmiert habe, steht im Flash "00 00 01 01 02 02 03 03 04 04"... etc.

Was läuft denn da verkehrt?

Viele Grüße, Johannes

Hmm der stimmt irgendwie nicht, siehe anderes Posting :-(

Danke für den Tipp, aber leider war's das nicht. Das Bit war nicht gesetzt (hab's nicht angefasst) und auch mit einem manuellen "&= ~(1

Okay, Fehler eingegrenzt: PonyProg.

Damit kann ich unter Linux bei dem mega16 die Fuses nicht lesen/schreiben. Der dude scheint zu gehen, ich schreibe gerade ein kleines Frontend dafür. Wenn ich mit dem die Fuses auslese, sehe ich ganz klar, dass der interne Oszillator an ist.

Ich melde mich, wenn ich weiß, ob's geklappt hat.

Viele Grüße, Johannes

TADAAA!

An PonyProg lag's. Das kann bei mir (2.06c beta Linux x86, neuste Linuxversion also) die Fuses weder lesen noch schreiben - zeigt aber keinen Fehler an! Mit avrdude tut's jetzt.

Bei uns sagt man: "A draum!" ;-)

Viele Grüße und danke für die Hilfe! Johannes

Wenn die Fuses tatsächlich alle 1 sind, wie du behauptest, dann ist ISP abgeschaltet und der AVR läßt sich nicht mehr per SPI programmieren. Und die CKSEL-Bits alle auf 1 ist zwar die Einstellung für externen Quarz, aber ich finde keine Dokumentation darüber, was dann passiert, wenn CKOPT auch 1 ist.

PonyProg zeigt die SPIEN-Fuse bei mir grau dargestellt - was Sinn macht, weil sie ja durch das serielle Programmieren nicht verändert werden kann. Vorher wurde bei ihr aber auch eine "1" angezeigt (leeres, graues Kästchen).

Interessanterweise ist jetzt - nachdem ich das Ding mit avrdude programmiert habe - auch bei PonyProg wieder alles in Ordnung. Er zeigt die Fuses richtig an und programmiert sie auch. Dubios.

Gruß, Johannes

Offensichtlich sendet PonyProg zu schnell für den Mega 16 mit internem RC-Oszillator.

Johannes Bauer schrieb:

Wie erstellst du das Frontend? Rufst du dann avrdude mit -v auf und extrahierst die Fuses oder schreibst du mit hfuse:r: usw. in eine Textdatei?

avrdude -p m128 -P /dev/parport0 -c stk200 -v bringt bei mir z.B. ... avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9702 avrdude: safemode: lfuse reads as DE avrdude: safemode: hfuse reads as D9 avrdude: safemode: efuse reads as FF

avrdude: safemode: lfuse reads as DE avrdude: safemode: hfuse reads as D9 avrdude: safemode: efuse reads as FF avrdude: safemode: Fuses OK

avrdude done. Thank you.

Und wie soll das Frontend in etwa aussehen? Wollte da auch schon mit fltk drangehen. "avrdude-gui" Kennst du? Ist mit wxwidgets gemacht, beta Stadium. Gruß Andy

Hallo,

Johannes Bauer schrieb:

Ein Frontend gibts doch schon: avrdude-gui.exe Ist bei WinAVR dabei.

Michael

Michael Rübig schrieb:

genau, du hast aber das "Linux" übersehen...

Andreas Weber schrieb:

ups...

Ich hab das mit einer Textdatei gelöst.

Und das Ding ist keine hübsche GUI - ncurses. Also auch nicht portabel...

Nein, avrdude-gui kannte ich nicht... wxwidgets sollte sich ja portieren lassen. Leider nirgendwo ein Screenshot, um zu sehen, wie's aussieht.

Also wenn du was mit fltk programmierst freu ich mich, meines ist wie gesagt nur Konsolen-GUI. Ich würde es auch auf nem x86 und nem x86_64 testen ;-)

Viele Grüße, Johannes