Hallo,
im Datenblatt vom Atmega88 ist in einem Diagramm zu sehen, dass dieser
Controller bei einem Takt von 100kHz nur noch sehr wenig Strom
verbraucht.
Bei zeitunkritischen Routinen ist das ja prinzipiell löblich.
Ich frage mich allerdings, wie man diese geringe Taktrate erzeugt.
Gibt es 100kHz-Resonatoren, die man an den beiden XTAL-Pins anschließen
kann -> also für den Betrieb mit dem internen Oszillator?
("normale" Quarze gibt es anscheinend nicht für 100kHz)
Oder benötigt man dann in jedem Fall einen externen Oszillator?
zB mit dem internen RC, den auf 1MHz laufen lassen. Dann kann man fuer
Stromsparanwendungen auch noch einen 32kHz Quarz anhaengen. Stromsparen
ist allerdings nicht ganz so trivial. Denn ein 1M pullup zieht schon 3uA
bei 3V.
Danke für die schnelle Antwort!
Also interner Takt 8MHz und CLKDIV setzen -> 1MHz
(das sind aber noch keine 100kHz)
Oh D. schrieb:> Dann kann man fuer> Stromsparanwendungen auch noch einen 32kHz Quarz anhaengen.
Dann läuft der Controller einzig und alleine mit 32kHz?
Ja, kann man machen. Soweit ich weiss hat man dann ein Problem mit dem
Programmieren, denn der Programmierer darf nicht schneller sein, wie der
clock. Ich hab da jeweils einen richtigen quarz dazu. Auf den schaltet
man dann zurueck, wenn etwas getan werden soll.
Allenfalls kann man den clock auch von extern zufuehren, fuer das
Programmieren. Es gibt auch Programmer, die lassen sich auf langsam
schalten.
wern schrieb:> Also interner Takt 8MHz und CLKDIV setzen -> 1MHz> (das sind aber noch keine 100kHz)
Man kann den Clock-Divider (CLKPR) aus dem laufenden Programm heraus
setzen. Und zwar durchaus auch auf andere Werte als 8 oder 1.
wern schrieb:> Also interner Takt 8MHz und CLKDIV setzen -> 1MHz> (das sind aber noch keine 100kHz)
CLKDIV8 ist eine Voreinstellung per Fuse für CLKPR, den Clock Precaler.
Per Software lässt sich der Takt mit dem CLKPR bis auf 256 runterteilen.
Man kann auch per Fuse den Watchdog-Oszillator mit 128KHz als F_CPU
auswählen. Sollte dabei aber tunlichst die CLKDIV8-Fuse wegnehmen. Sonst
läuft er mit 16KHz. Und das ist keine Freude.
Das sind zwar alles noch keine 100KHz, aber immerhin. Solche krummen
Werte gehen eben nicht intern.
Oh D. schrieb:> Allenfalls kann man den clock auch von extern zufuehren, fuer das> Programmieren. Es gibt auch Programmer, die lassen sich auf langsam> schalten.
Ach, das wusste ich gar nicht. Danke für den Hinweis! Dann ist ein Clock
Division Factor von 1, 2, 4, 8, 16, 32, 64, 128 und 256 möglich... gut
zu wissen. Damit käme man z.B. auf 125kHz.
Axel S. schrieb:> Man kann den Clock-Divider (CLKPR) aus dem laufenden Programm heraus> setzen. Und zwar durchaus auch auf andere Werte als 8 oder 1.
Danke, s.o.!
> Sollte dabei aber tunlichst die CLKDIV8-Fuse wegnehmen.> Sonst läuft er mit 16KHz. Und das ist keine Freude.
Hab ich schon einmal macht, mit dem Ergebnis, dass mein ISP Programmer
nicht mehr funktionierte. Aber der Hersteller hat die Firmware
entsprechend angepasst, dauert nur ein paar Wochen.
Stefan U. schrieb:>> Sollte dabei aber tunlichst die CLKDIV8-Fuse wegnehmen.>> Sonst läuft er mit 16KHz. Und das ist keine Freude.>> Hab ich schon einmal macht, mit dem Ergebnis, dass mein ISP Programmer> nicht mehr funktionierte. Aber der Hersteller hat die Firmware> entsprechend angepasst, dauert nur ein paar Wochen.
Am einfachsten packt man die 'Fuse' für CLKDIV garnicht an. Damit läuft
der µC nach einem Reset mit 1 MHz. Gleich am Anfang des Programmes
stellt man sich seinen Wunschwert ein:
int16_t main(void)
{
CLKPR = 0x80; CLKPR = 0x0; // Vorteiler / 1 CPU-Takt = 8MHz
S. Landolt schrieb:>> Damit läuft der µC nach einem Reset mit 1 MHz> Das nun eben nicht, ein Reset reicht nicht, Power-up ist nötig.
Ich weiß nicht, wie Du darauf kommst. Weder kann ich es dem Datenblatt
entnehmen, noch verhält sich ein ATmega88 so.
Einfacher Versuch: ATmega mit 12 MHz und Teiler /8 nicht gesetzt. Der µC
läßt sich mit 2 MHz Takt programmieren.
Anschließend im Programm den /8 Teiler gesetzt und kontrolliert, daß der
µC nun langsamer läuft. Anschließende Programmierung mit 2 MHz klappt
nach wie vor. Der Reset von AVRISP reicht folglich aus.
Die Länge/ Dauer eines Bits ist entscheidend, bei der Programmierung.
Wenn es mal wieder bedeutend länger dauert, ist der Programmer einfach
zu schnell beim Senden, bekommt ein Timeout und dann ists halt nix mit
Programmierung. Alles bis 1MHz ist unkritisch. Der avrdude kann die
Bit-Clock variieren, um auch mit deutlich geringeren Taktraten
programmieren zu können. Aber alle Vorredner mit CKDIV nach
Programmstart haben Recht.
Beim Power-Up bin ich kritisch, da der ISP-Stecker nur eine Verbindung
zum RESET-Pin hat. Den Saft dreht er damit nicht ab. Aber u.U. steckt da
was im Programmierprotokoll.
an m.n.:
Sie haben vielleicht ein intelligenteres Programmiergerät als die
meisten hier, mich eingeschlossen.
Wenn Sie jedoch Ihren Versuch noch einmal wiederholen könnten, vorher
die Low-Fuse auf die kürzestmögliche Startzeit stellen, das wäre wohl
D7, und im Programm das Setzen von CLKPR gleich an den Anfang schreiben,
sowie am besten gleich das Maximum nehmen, also /256.
Mit dem genannten 12 MHz Quarztakt kann ich bis Vorteiler /32
heruntergehen. Die interne Taktfrequenz beträgt dann 375 kHz. Trotzdem
kann man noch mit 2 MHz Programmiertakt arbeiten.
Mit Vorteilerwerten /64, /128 und /256 muß ich beim AVRISP MK2 auf 6,25
kHz heruntergehen.
Ich vermute, daß der Reset-Impuls vom AVRISP zu kurz ist, um bei zu
niedriger Taktfrequenz 'wirksam' zu werden. Vermutlich spielen noch die
eingestellten Startzeiten eine Rolle.
Zwar könnte ich mit einem LPT-Programmer das Verhalten mit einem
deutlich längeren Reset untersuchen. Das ist mit jetzt aber zu viel.
Danke für Ihre Mühe.
Dann sind wir uns zumindest darin einig, dass an dieser Stelle für den
Unerfahrenen ein mögliches Problem besteht, je nach dem, was als
Programmiergerät verfügbar ist (dies Verhalten war der Anlass, mein
Selbstbaugerät bis 30 Hz (< 32768/256/4) herunterlaufen zu lassen).
S. Landolt schrieb:> Dann sind wir uns zumindest darin einig, dass an dieser Stelle für den> Unerfahrenen ein mögliches Problem besteht
Ich habe doch noch einmal mit einem LPT-Programmer gespielt.
Mir scheint zwischen Vorteiler /32 (schnelle Programmierung
funktioniert) und Vorteiler /64 eine 'magische' Grenze zu liegen, die
ein langsames Takten erforderlich macht.
Vielleicht kann Jemand dies bestätigen?
Nein, ich kann hier keine Schwelle erkennen (ATmega88-20PU 0643). Auch
hat ein Verlängern des Resetimpulses auf 500 ms nichts gebracht (außer
einem sehr langwierigen automatischen Herunterlaufen).
Allerdings habe ich, wie schon gesagt, nur ein Selbstbaugerät, dessen
Programmierung viele Jahre zurückliegt, für genauere Untersuchungen
müsste ich mich erst wieder in die Details einarbeiten. Jemand mit einem
professionellen Gerät könnte eher etwas Allgemeingültiges sagen.
