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
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.
