Hallo zusammen, ich will ein Li-Ion-Akkupack mit einem ATTiny84 überwachen. Um Strom zu sparen, soll er mit einer niedrigen Frequenz von z.Zt. 62kHz laufen (er hat kaum etwas zu tun). Ich betreibe ihn mit den Default-Fuses, d.h. mit RC-Oszillator und CKDIV8, also 1MHz. In Bascom setze ich die Frequenz dann mit CLKPR=7 auf 62,5KHz. Das klappt im Prinzip ganz gut. Beim Programmieren mit ISP-MKII erlebe ich dann aber Zustände, die ich nicht verstehe: - Beim 1. Programmieren mit ISP-Takt von 125kHz klappt alles bestens - Beim allen weiteren Versuchen erkennt er den Chip nicht mehr. Ich muss auf 10kHz ISP-Takt herunter gehen, damit es wieder geht. Das widerspricht meinem Verständnis: Der niedrige Takt wird erst im Programm gesetzt, d.h. nach Reset müsste er mit 1MHz loslaufen und mit 125kHz progammiert werden können. Erst im Programm setzte ich mit CLKPR die kleine Frequenz. Umgekehrt ist es genauso: Um ihn wieder mit 1MHz zu betreiben, muss ich ihn mit ISP-Takt 10kHz auf 1MHz bringen, damit er wieder mit 125KHz programmierbar ist. Seltsam... er kann sich doch nicht die Register nach Reset merken?! Ist dieses Verhalten erklärbar? Oder wo ist der Wurm drin? Hilfe Hermann
Hermann schrieb: > ich will ein Li-Ion-Akkupack mit einem ATTiny84 überwachen. Um Strom zu > sparen, soll er mit einer niedrigen Frequenz von z.Zt. 62kHz laufen (er > hat kaum etwas zu tun). Ich würde dazu den internen 128-kHz-Oszillator verwenden, der ist noch sparsamer. Ich glaube, den kann man per Prescaler sogar bis 500 Hz runtertakten - wenn man es ein bisschen übertreiben will. ;-) Öhm, ich geh jetzt mal vom ATtiny84A aus, ich glaube, den ATtiny84 gibts offiziell schon gar nicht mehr. > Beim Programmieren mit ISP-MKII erlebe ich dann aber Zustände, die ich > nicht verstehe: (...) Ich kenne das Phänomen. Möglicherweise wird Reset vom Programmer nicht schnell genug runtergezogen, so dass der Mikrocontroller schon losläuft. Falls der Taktfrequenzwechsel bei deinem Programm ganz am Anfang kommt, kann es sein, dass er noch erfolgt, bevor der Programmer mit seiner Arbeit beginnt. Es könnte helfen, den Frequenzwechsel erst nach einer kleinen Zählschleife zu schalten. Oder du lebst generell mit einer sehr niedrigen Programmierfrequenz, was ja auch nichts Schlimmes ist. :-)
Die Erklärung leuchtet ein, es ist tatsächtlich das 1. Statement. Ich habe es geich ausprobiert. Aber leider ohne Erfolg. CLKPR setze ich jetzt erst nach der ganzen Programmvorbereitung und habe noch eine 100ms-Warte-Loop eingebaut. Er tut es immer noch erst bei ISP-Takt von 10kHz. Der Chip ist ein Tiny84V-10PU.
Hermann schrieb: > Die Erklärung leuchtet ein, es ist tatsächtlich das 1. Statement. Ich > habe es geich ausprobiert. Aber leider ohne Erfolg. CLKPR setze ich > jetzt erst nach der ganzen Programmvorbereitung und habe noch eine > 100ms-Warte-Loop eingebaut. Er tut es immer noch erst bei ISP-Takt von > 10kHz. Hmmm... ich muss das selber auch noch einmal probieren. Ich glaube, ich hatte das Problem damals mit einem ATtiny85, den ich dann bei 500 Hz CPU-Takt nicht mehr programmieren konnte. Vielleicht hilft es, den Takt ganz am Anfang hochzusetzen und dann erst nach 10 Sekunden auf die niedrige Frequenz. Ich werd das bei nächster Gelegenheit probieren, interessiert mich jetzt selber. :-) > Der Chip ist ein Tiny84V-10PU. Du hast völlig Recht. Ich hab grad nachgeschaut, den 84 und 84V gibt es immer noch, obwohl der gemeinsame Nachfolger 84A jetzt schon länger auf dem Markt ist. Schadet ja nicht. :-)
Nachträglich leuchtet mir die Erklärung mit dem späteren setzten des Taktes nicht mehr ein. Der Chip hat immer vor dem Programmieren Vcc bekommen und das alte Programm läuft also bereits. Der Programmer muss immer das Reset setzen, bevor er mit dem Programmieren beginnt. Das Warten im Programm kann also nichts bringen (Test mit einer 10sec-Loop hat nichts gebracht). Es fällt auch auf, das ziemlich genau bei einer ISP-Frq von 1/4 der mit CLKPR gesetzten Takt-Frq Schluss ist. Dieses habe ich beim alten MKII-Treiber in Studio4 festgestellt. Der 1 Jahr alte Treiber in Bascom spinnt bei den Frequenzen völlig.
Ich habe jetzt Erfolg mit der Warte-Loop vor dem Setzen der niedrigen Takt-Frq. Der Chip lässt sich mit ISP-Frq=125kHz programmieren, wenn ich nach Anlegen von Vcc sofort mit dem Programmieren beginne, d.h. bevor die Takt-Frq mit CLKPR herunter gesetzt wird. Bleibt Vcc länger als die Warte-Loop dran, ist nur die ISP-Frq von 10kHz möglich. Die Erkenntnis: die CLKPR-Bits bleiben trotz Reset gesetzt, bis Vcc entfernt wird. Es bleibt seltsam, das hätte ich nicht erwartet. Das wird vermutlich auf alle anderen IO-Register zutreffen. So können evtl. viele andere Schmutzeffekte erklärt werden. Oder gibt es vielleicht eine andere Erklärung??
Hi >Das wird vermutlich auf alle anderen IO-Register zutreffen. So können evtl. >viele andere Schmutzeffekte erklärt werden. Nein. Bei CLKPR haben die unteren 4 Bit keinen Initialwert, mit dem sie nach einem Reset geladen werden. Bei den anderen IO-Registern ist das nicht so. MfG Spess
Angehängte Dateien:
-
Tiny84-CLKPS.gif
10 KB
Das wäre ja genau die Erklärung für das festgestellte Verhalten. Wo kann man das lesen? Ich finde aber im Tiny84-Manual, dass die Bits auf 0000 resettet werden - siehe Anhang.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.