Forum: Mikrocontroller und Digitale Elektronik Verständnisprobleme mit FuseBits


von Michael K. (onkel_michi)


Lesenswert?

Nachdem ich nun erfolgreich eine Entwicklungsumgebung mit Linux auf
einem alten 486er aufgesetzt habe, wollte ich nun ein Programm das
Werte über den USART eines ATmega8L (bzw. ATmega8-16) ausgibt, in einen
solchen hineinflashen.

Avrdude läuft und auch das Flashen war erfolgreich.

Da es sich aber um einen fabrikneuen ATmega8 (L bzw. -16) handelt, muß
ich ja noch die FuseBits setzen, um den externen Quarz mit 3,6864 MHz
benutzen zu können.

Mit Ponyprog war das ja einfach. Aber mit Avrdude muß ich ja:

avrdude -p m8 -P /dev/parport0 -c stk200 -U:lfuse:xx

benutzen.

Wenn ich das Datenblatt richtig verstanden habe, müsste da doch für xx
der Wert ff hin, oder ???

(Also die ersten 2 Bit mit 11 (Stehen so in schon drin) SUT 1..0 mit 11
für Quarz  mit 65ms Delay, CKOPT 1 für externer Crystal und CKSEL mit
111 für 3...8 MHz)

Ich möchte nicht gleich im ersten Versuch den ATmega8 in ein
unbrauchbares Stück Sondermüll verwandeln.

Kann mir da jemand mal sagen, ob meine Vermutungen richtig sind ??

Danke im vorraus.

von _CH_ (Gast)


Lesenswert?

Hallo Michael,
Meiner Meinung nach vermutest du richtig. Bei meinem M8 ist das lfuse
auf 0xef eingestellt und er werkelt wunderbar mit 8MHz.

Gruß,
Christian

von Michael K. (onkel_michi)


Lesenswert?

Danke für die Antwort.

Du schreibst 0xef rein, aber wofür stehen dann die ersten 2 Bit ?

Wenn ich 0xef in lfuse schreibe heist das ja: 1011 1111 , in dem
Datenblatt zu dem mega8 finde ich aber nichts über die Funktion der
ersten Bits, bzw. was passiert, wenn ich 0xff in lfuse schreibe.

Wenn Du mir da noch helfen könntest.

Danke

von methyl (Gast)


Lesenswert?

>Du schreibst 0xef rein, aber wofür stehen dann die ersten 2 Bit ?
für die brown-out-detection
siehe:
http://electrons.psychogenic.com/modules/arms/art/14/AVRFusesHOWTOGuide.php

>Wenn ich 0xef in lfuse schreibe heist das ja: 1011 1111
ist 0xef nicht 11101111 ?

von Michael K. (onkel_michi)


Lesenswert?

Doch, sorry es ist 1110 1111 ... (habe da was verwechselt)

Das heißt dann ja, das 0xef für die 3,6864 MHz genau richtig wären.

Wenn ich dann 0xff in lfuse schreibe, löst der Brown-Out Detector bei
2,7V Vcc einen Reset aus.

Die verlinkte Seite habe ich gleich gebookmarked.

Danke für eure Hilfe. Ich habe aber trotzdem nur mit

avrdude -c stk200 -p m8 -P /dev/parport0 -U lfuse:w:0xEF:m

die Fuses für den externen Quarz gesetzt und die Brown-Out Detection
unprogrammiert gelassen.

Mit dem Wissen werde ich nun wohl auch den ATmega8-16 auf 16MHz
"gefused" bekommen.

von _CH_ (Gast)


Lesenswert?

viel Glück ;)

von Michael K. (onkel_michi)


Lesenswert?

Danke.

von Michael K. (onkel_michi)


Lesenswert?

Hallo nochmal ...

Das Unheil nahm seinen Lauf.

Ich habe ganz sorgfältig das Datenblatt zum ATmega16-16 gelesen, dem
Teil einen Quarz von 11,0592 MHz (Warum gerade den, weiß ich nicht mehr
so genau...) angehängt und zum Testen ein einfaches Blinkprogramm in den
Mega geschoben.

Ich habe den CKOPT auf 0 und den CKSEL 3...0 auf 1 gesetzt.
Das sind bei hfuse 0x89 und bei lfuse 0xff.

Das Problem ist nun das der Mega16 bei einem Delay von 1000 ms (Aus der
delay.h Bibliothek) immer noch etwa 10x so schnell blinkt, wie er denn
soll.

Wo liegt da mein Denkfehler ??

Bitte mal kurz die rostigen Zahnräder bei mir anschubsen, bevor ich
hier irre werde.

Danke.

von Simon K. (simon) Benutzerseite


Lesenswert?

Zu schnell kann ja nicht, das muss ein softwareseitiges Problem sein,
denn eine schnellere Clock als 11Mhz hat der Prozessor garnicht zur
Verfügung (Für den Falle dass du eine falsche Clock angewählt hast)

Du hast vielleicht im Makefile die Frequenz deines Quarzes nicht
richtig angegeben. (Also eine zu niedrige Frequenz angegeben,
vielleicht ne 0 vergessen? Also 1Mhz ?) dann könnte der Delay zu
schnell berechnet worden sein.

Deine Bytes sind übrigens korrekt, wenns nach mir geht.

von Michael K. (onkel_michi)


Lesenswert?

Ich habe den Sourcecode gerade nicht auf diesem Rechner hier verfügbar.

Aber grob sieht das Programm so aus:

PORTB auf Ausgang setzen

While(1)
{
  _delay_ms(1000)
   PIN PB0 auf 1
  _delay_ms(1000)
   PIN PB0 auf 0
}

Also daran kann es nicht liegen (Denke ich jedenfalls)

Ich gehe jetzt erst einmal nach hause und schlafe mich aus.

Morgen schaue ich dann mal in das Makefile, das hatte ich zuletzt für
ein myAVR Board gebraucht und da ist ein 3,6864 MHz Quarz drin.

Vielleicht liegt da wirklich der Fehler.

Danke erst einmal.

von Alex Trusk (Gast)


Lesenswert?

Es liegt an deinem Programm:
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

"The maximal possible delay is 262.14 ms / F_CPU in MHz."
--> Bei ~11Mhz also ~23ms

Probier es mal so:

uint8_t i;
DDRB=0x01;

while(1)
{
    for (i=0;i<100;i++)
        _delay_ms(10);

    PORTB ^= 0x01;
}

gruss, alex.

von Michael K. (onkel_michi)


Lesenswert?

Na super ...

Und ich habe gedacht, ich wäre zu dämlich die Fuse-Bits zu setzen.

Es klappt mit Deinem Programm.

Danke.

Das Blinkprogramm hatte ich nur geschrieben, um heraus zu bekommen, ob
die FuseBits stimmen und ich den Mega16 nicht "zerfused" habe.

Die richtige Anwendung für den Mega bin ich grade am zusammenstricken.

Die Seite mit der Beschreibung ist auch gebookmarked.

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
Noch kein Account? Hier anmelden.