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.
Gast
#267407
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
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
Gast
#267409
>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 ?
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.
Gast
#267411
viel Glück ;)
Danke.
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.
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.
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.
Gast
#267416
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.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.