Hallo, das hört sich nach einer banalen Frage an und ist es womöglich auch. Programmieren von uC habe ich bereits Erfahrungen, doch möchte ich mich das erste mal an Fuse-Bits heranwagen ohne meinen ATtiny85 zu verbraten. In Folge dessen, dass der Webshop (Beitrag "Webshop guloshop.de down?") das gewünschte Objekt (Bierdeckelprogrammer) nicht mehr anbietet, aber die Hex File und die Einstellungen für die Fuse-Bits auf dem Server (https://guloshop.de/f/bierdeckel/) liegen, möchte ich das nun selbst probieren. Meinem Verständnis nach wäre der Ablauf folgender: 1. bierdeckel_2014.hex file auf den ATtiny85 laden -> Schritt abgeschlossen. 2. Fuse Bits wie angegeben in einem anderen Schritt im uC setzen. Fusebits für beide Versionen: lfuse 0b11110001 = 0xF1 hfuse 0b01011101 = 0x5D efuse 0b11111111 = 0xFF 3. Glücklich sein, das alles funktioniert hat -> korrekt? Die Lockbits bleiben unangetastet bei... 0xFF?? Ist das die "Default" Einstellung?
:
Bearbeitet durch User
Warum willst du das bauen, wenn du doch schon einen AVR Programmer hast? Natürlich kannst du das so machen. (habe die Fuses nicht überprüft) Mirko schrieb: > ohne meinen ATtiny85 zu verbraten. Kannst du jederzeit mit einem HVSP wieder retten.
Arduino F. schrieb: > Kannst du jederzeit mit einem HVSP wieder retten. Den muss man aber auch erst haben oder bauen. Mittlerweile habe ich einen gebaut und auch schon genutzt. Die Fuses bei den älteren AVR Tiny können tückisch sein, da ist tatsächlich Vorsicht angebracht. Habe Deine Fuses auch nicht geprüft, mag gerade das DB nicht wälzen. Aber zwei gängige Fehler die zum Abhängen führen sind: - Taktquelle auf extern, obwhl die Schaltung keinen Oszillator hat. - Interner CPU-Takt zum Stromsparen z.B. auf 125 kHz, ohne den Teiler für den Peripherie-Takt von default /8 auf 1 zu setzen. Geschwindigkeit unterschreitet dann die Timeouts zum PC. Ja richtig, unprogrammiert ist 0xff. Aber Vorsicht, manchmal steckt eine negative Logik dahinter.
:
Bearbeitet durch User
Wulf D. schrieb: > Interner CPU-Takt zum Stromsparen Für USB ist eher 16MHz intern nötig, als der WDT Oszillator.
Kann ich beim Programmieren eigentlich immer davon ausgehen, dass die HEX Datei 100% korrekt übertragen wurde? Die Fuse-Bits wären wie folgt... LOW: CKSEL1 CKSEL2 CKSEL3 HIGH BODLEVEL1 SPIEN RSTDISBL EXTEND --- LOCK ---
Angehängte Dateien:
Mirko schrieb: > Kann ich beim Programmieren eigentlich immer davon ausgehen, dass die > HEX Datei 100% korrekt übertragen wurde? Jain! Aber dafür gibts ja schließlich verify, um sich da sicher zu sein.
:
Bearbeitet durch User
Angehängte Dateien:
-
Fuse_High_Byte.png
45 KB
> ohne meinen ATtiny85 zu verbraten > hfuse 0b01011101 = 0x5D RSTDISBL! > Glücklich sein, das alles funktioniert hat Wenn nicht: weiteres Programmieren nur noch per: > mit einem HVSP wieder retten
Spielt bezüglich Sicherheit wohl keine Rolle, aber: Mirko schrieb: > Die Fuse-Bits wären wie folgt... > LOW: > CKSEL1 > CKSEL2 > CKSEL3 ? Bei > lfuse 0b11110001 = 0xF1 lese ich CKSEL[3:0] = 0001 (d.h. High Frequency PLL Clock).
S. L. schrieb: > lese ich CKSEL[3:0] = 0001 (d.h. High Frequency PLL Clock). Sehe ich auch so Sachte ich aber weiter oben auch schon. S. L. schrieb: > RSTDISBL! Ist das wirklich gesetzt? Das sehe ich in den gegebenen Fuses noch nicht.
> Ist das wirklich gesetzt? Bit No. 7 von Fuse High Byte ist RSTDISBL, und dieses ist 'programmed': > hfuse 0b01011101 = 0x5D
Warum wil man das programmieren, wenn man das im Atmel Studio einfach anklicken kann? Da brauchst du auch kein Datenblatt, denn es steht alles da. Das meiste erklärt der Text von sich aus und bei Problemen einfach dieses eine Problem nachlesen.
Die Wert habe ich hier https://eleccelerator.com/fusecalc/fusecalc.php?chip=attiny85 ausgelesen... wohl nicht so ganz korrekt... hmm Dann werde ich es mal versuchen und auch mit "verify" um nochmal einen Sicherheitsschritt mehr zu haben. Arduino F. schrieb: > Warum willst du das bauen, wenn du doch schon einen AVR Programmer hast? Braucht man für Elektronikbasteleien immer ein "Warum?" Aber ich will mal nicht so sein... ich wollte einen Programmer direkt in ein Projekt integrieren ohne immer einen "brauchen" zu müssen. Und weil ich diesen simplen Bierdeckel-Programmer feier.
S. L. schrieb: >> ohne meinen ATtiny85 zu verbraten >> hfuse 0b01011101 = 0x5D > > RSTDISBL! Danke für den Ausschnitt aus dem Datenblatt. Man sollte dem DB mehr glauben schenken als irgend einer Webseite :D Ich werde die Bits definitiv einzeln im Microchip Studio setzen!!!
Mirko schrieb: > 2. Fuse Bits wie angegeben in einem anderen Schritt im uC setzen. > Fusebits für beide Versionen: > lfuse 0b11110001 = 0xF1 > hfuse 0b01011101 = 0x5D > efuse 0b11111111 = 0xFF Beitrag "Re: Timing-Problem"
Mirko schrieb: > Braucht man für Elektronikbasteleien immer ein "Warum?" Irgendwo, ja.... Aber hast schon recht. Meine Gründe sind nicht deine Gründe. Und da ist nichts verwerfliches dran.
Mirko schrieb: > Man sollte dem DB mehr > glauben schenken als irgend einer Webseite :D Immer! Deshalb liest du hier auch oft "RTFM". Mirko schrieb: > Braucht man für Elektronikbasteleien immer ein "Warum?" Nein, nur für die Leser hier. Aber im Ernst, hinter der Frage versteckt sich die eigentliche Frage: "Weißt du denn nicht, dass der Bierdeckelprogrammer ein ganz einfaches Werkzeug ist und du mit deinem Programmer sicher besser bedient bist?"
:
Bearbeitet durch User
Frank O. schrieb: > "Weißt du denn nicht, dass der > Bierdeckelprogrammer ein ganz einfaches Werkzeug ist und du mit deinem > Programmer sicher besser bedient bist?" Durchaus! Aber im Grunde ist es egal, wo man anfängt in die µC Welt einzusteigen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.