Hallo Experten, ich entwickele grad eine Schaltung in der ein ATtiny2313 zum Einsatz kommt. Da das Ganze stromsparend aufgebaut sein soll, habe ich das CLKPR-Register zum Runterteilen des Quarztaktes am Anfang des Programms verwendet. Das Programm arbeitet soweit korrekt. Leider kann ich den µC aber jetzt nicht mehr programmieren, da er laut meiner Berechnung mit internen 46,8 KHz arbeitet. Gibt es eine Möglichkeit mit meinem Programmieradpter AVR910 das Timing so zu reduzieren, dass er einen so langsamen Mikrocontroller programmieren kann? Ich weiß, dass man mit einem sehr schnellen externen Quarzosszilator z.B. 50MHz den Controller wieder ansprechen kann. Nur, das hilft bei der Entwicklung nicht weiter und wird dem Leben des Controllers nicht förderlich sein.
Birger Z. wrote: > Leider kann ich den µC aber jetzt nicht mehr programmieren, da er laut > meiner Berechnung mit internen 46,8 KHz arbeitet. Nö. Bei SPI-Programmierung wird der MC im Reset gehalten, das CLKPR hat also den Resetwert. Code wird da garkeiner ausgeführt. > Ich weiß, dass man mit einem sehr schnellen externen Quarzosszilator > z.B. 50MHz den Controller wieder ansprechen kann. Wer erzählt denn sonen Quark? Peter
So ganz hab ich das Geschehen auch nicht verstanden, denn genau wie du, hätte ich erwartet, dass mit dem Reset-Signal auch das CLKPR-Register wieder zurückgesetzt werden würde. Nur, es geschieht wohl nicht. Und das mit den 50 MHz ist natürlich kein Quark, ich hab's vorhin mit 'nem anderen Controller AT90CAN128, der das gleiche Verhalten zeigte, einfach ausprobiert. Mich interessiert, ob es eine Möglichkeit gibt, den SPI-Takt während des Programmierens mit Avrdude und AVR910-Programmer zu reduzieren.
Birger Z. wrote: > Mich interessiert, ob es eine Möglichkeit gibt, den SPI-Takt während des > Programmierens mit Avrdude und AVR910-Programmer zu reduzieren. Das musst du deinen AVR910-Programmer fragen, denn der legt den Takt fest.
Ich bin mittlerweile schon zu zwei Lösungen gekommen: Mit einem STK200 kompatiblen Adapter und den von Jörg schon an einigen anderen Stellen gemachten Hinweisen zu der -i Option habe ich Erfolg gehabt. Bei meinem Athlon 3200 XP habe ich -i 80 als Parameter angehängt, wobei das Funktionieren ab -i 63 anfing. Desweiteren habe ich mir den Assemblercode des AVR910 angeschaut und die Delayroutine des SCK-Signals identifiziert. Da ich zum Neuflashen der Firmware allerdings sowieso den Parallelportprogger brauche, habe ich lieber gleich diesen genommen. Die von mir bislang nie genutzte bzw. unbekannte -i Option erklärt mir auch, warum ich seit längerem nichts mehr von den Paralleport-Flashern gehalten habe.
Hallo, mit diesem Problem kämpfe ich auch gerade (ATmega48). Schreibt man einen zu großen oder zu kleinen(!) Teiler nach CLKPR, lässt sich auch bei mir der Baustein nicht mehr programmieren. Der Trick liegt nun darin, den Programmer zu veranlassen, RESET auf low zu halten, und dann den ATmega aus- und wieder einzuschalten. Dadurch läuft das Programm erst gar nicht an, der CLKPR wird auch nicht beschrieben. Evtl. wird das CLKPR-Register bei einem "Warmstart" (ohne Wegnahme der Betriebsspannung) gar nicht auf den Initialwert gesetzt? Am Timing kann's eigentlich nicht liegen, da ich ein selbstgebasteltes Downloadprogramm verwende, in welchem ich das Timing beliebig einstellen kann. Erst der Trick mit RESET low beim Einschalten brachte Erfolg. Das ist laut ATMEL-Doku auch der beste Weg. Warum sich die Biester mit bestimmten Vorteilern nicht mehr programmieren lassen, ist eine interessante Frage. Ich werde mal auf den ATMEL-Seiten stöbern, ob ich dort etwas finde. Irgendwelche Timingbeschränkungen habe ich zumindest auch auf den zweiten Blick in der Doku nicht finden können. Seltsam das ganze... ciao Marcus
> Evtl. wird das CLKPR-Register bei einem "Warmstart" (ohne Wegnahme der > Betriebsspannung) gar nicht auf den Initialwert gesetzt? Den Eindruck habe ich auch, habe allerdings im Datenblatt keinen entsprechenden Vermerk gefunden (vielleicht auch nur übersehen). > Am Timing kann's eigentlich nicht liegen, da ich ein selbstgebasteltes > Downloadprogramm verwende, in welchem ich das Timing beliebig > einstellen kann. Bei mir half allerdings das Ausbremsen der Datenübertragen mit der -i-Option von AVRdude bei der Verwendung eines Parallelport-Bitbang- Programmers. > Irgendwelche Timingbeschränkungen habe ich zumindest auch auf den > zweiten Blick in der Doku nicht finden können. Im Kapitel "Serial Downloading" im Datenblatt ist die maximale Übertragungsgeschwindigkeit wie folgt spezifiziert: "Depending on CKSEL Fuses, a valid clock must be present. The minimum low and high periods for the serial clock (SCK) input are defined as follows: Low: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz High: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz"
Der USBASP Programmer (http://www.fischl.de/usbasp/) hat einen Jumper zum herabstellen der Programmiergeschwindigkeit, hat auch mich schon gerettet. Nicht nur als Notfalllösung geeignet, ist ein super Programmer.
Hallo Leute, also ich habe jetzt das Problem gefunden, warum ich den ATmega48 nach dem ändern von CLKPR nicht mehr programmieren konnte, ohne die Spannung wegzunehmen, bei aktivem RESET (also low) einzuschalten und dann zu flashen: Ich habe mich beim Versuch, in den Programmiermodus zu schalten, an den Algorithmus von Atmel gehalten und nach einem erfolglosen Versuch RESET kurz auf High-Signal gelegt und dann wieder auf low (aktiv). Dabei hatte ich den High-Zustand sicherheitshalber auf 100ms gesetzt. Das war viel zu lang! Gehe ich mit der Impulslänge sehr weit runter, z.B. auf 1ms, dann lässt sich der Controller problemlos in den Programmiermodus schalten. Ich habe die Vermutung, dass der Controller bei 100ms High-Signal an RESET anläuft und sich dann beim anschließenden RESET in einem Zustand befindet (evtl. durch das geänderte CLKPR), dass er sich nicht mehr in den Programmiermodus schalten lässt. Nun habe ich ja den BOD noch nicht aktiviert. Mit aktiviertem BOD wird ja die Hochlaufzeit erheblich kürzer, so dass der Controller evtl. schon nach 1ms wieder komplett hochgelaufen ist. Ich werde das mal testen. Vielleicht hat jemand eine Idee, wo das Problem liegen könnte. Ansonsten kein Problem, denn der Controller lässt sich ja problemlos programmieren. ciao Marcus
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.