Timing-Problem

[Johannes (Gast)]

Hallo,
ich habe ein timer-problem, verstehe es aber nicht warum und hoffe hier 
die lösung zu finden.
Ich habe ein Atmega328 mit einem externen Quarz (8MHz).

Den Timer initialisiere ich:

  /* 20 ms */
  TCCR1B = (1 << WGM12) | (1 << CS11) | (1 << CS10); // CTC-Mode clkIO/64
  OCR1A = (2500-1);
  TIMSK1 = (1 << OCIE1A);

in der ISR lasse ich ein Pin toggeln und messe die Zeit.
es waren 160 ms.

ISR (TIMER1_COMPA_vect)
{
  PORTB ^= (1 << PINB2);
}

Dann habe ich die fuses gelesen:
lfuse: 0x62
hfuse: 0xD9
efuse: 0x07

Damit wurde der takt durch 8 dividiert. Dann passt es mit den 160 ms.
habe die lfuse umgeschrieben auf 0xE2. Diese gibt der controller mir 
auch beim Auslesen wieder aus.
allerdings toggelt der pin immer noch alle 160 ms.
Als ob die Änderung nicht angenommen wurde.

Gibt es noch eine Stellschraube um den Takt anzupassen? Ist es möglich, 
dass die Änderung der fuses nicht übernommen worden sind? Habe auch die 
Spannung vom Controller abgezogen und neu gestartet.

[MaWin O. (mawin_original)]

Johannes schrieb:
> mit einem externen Quarz (8MHz).

Deine Fuses konfigurieren den internen 8MHz Osc mit 8x-Teiler.

Johannes schrieb:
> lfuse umgeschrieben auf 0xE2

Damit sollte es eigentlich auf internen 8MHz laufen (=ohne Teiler)

[Johannes (Gast)]

MaWin O. schrieb:
> Deine Fuses konfigurieren den internen 8MHz Osc mit 8x-Teiler.

Gerade auch aufgefallen.
lfuse habe ich jetzt auf 0xFD geändert. 
(https://www.engbedded.com/fusecalc/)
allerdings hat sich das Timing immer noch geändert

MaWin O. schrieb:
> Johannes schrieb:
>> lfuse umgeschrieben auf 0xE2
>
> Damit sollte es eigentlich auf internen 8MHz laufen (=ohne Teiler)

Ob jetzt intern oder extern. Grob sollte es trotzdem alle 20ms toggeln, 
was es nicht tut

[Johannes (Gast)]

Habe nochmal alles abgezogen und länger vom strom weggenommen.
Jetzt läuft es richtig

[MaWin O. (mawin_original)]

Johannes schrieb:
> Ob jetzt intern oder extern. Grob sollte es trotzdem alle 20ms toggeln,
> was es nicht tut

Ja. Wenn alles so ist, wie du es hier beschrieben hast, sollte es tun.

-> Vollen realen unmodifizierten Sourcecode bitte.

[MaWin O. (mawin_original)]

Johannes schrieb:
> Habe nochmal alles abgezogen und länger vom strom weggenommen.
> Jetzt läuft es richtig

Merkwürdig. Die Fuses sind direkt nach dem Schreiben wirksam, nachdem 
der Programmer den Chip aus dem Reset nimmt.
Welchen Programmer nutzt du?

[Peter D. (peda)]

Johannes schrieb:
> Habe nochmal alles abgezogen und länger vom strom weggenommen.
> Jetzt läuft es richtig

Das ist korrekt. Die Fuse wird nur beim Power-On neu ausgewertet. Alle 
anderen Resetquellen lassen den CPU-Vorteiler unverändert.

[MaWin O. (mawin_original)]

Peter D. schrieb:
> Das ist korrekt. Die Fuse wird nur beim Power-On neu ausgewertet.

Wo steht das im Datenblatt?
Ich habe noch nie einen POR nach Fuse-Schreiben gemacht.
Ext-RST reichte bisher immer.

[Thomas E. (thomase)]

MaWin O. schrieb:
> Ich habe noch nie einen POR nach Fuse-Schreiben gemacht.

Ich auch nicht.

[Johannes (Gast)]

MaWin O. schrieb:
> Welchen Programmer nutzt du?

Ich benutze einen DiamexProg-S

mit avrdude kann ich diesen als stk500v2 benutzen
-c stk500v2 -p m328p -B 10 -P com7 -U lfuse:w:0xfd:m

[Peter D. (peda)]

MaWin O. schrieb:
> Wo steht das im Datenblatt?

Nirgends. Man kann es nur ausprobieren.
Z.B schreib ein Blinkprogramm, was nach je 10s den CPU-Prescaler 
umschaltet.
Dann drück irgendwann die Resettaste und es blinkt mit dem letzten Takt 
weiter.

[Peter Lustig (Gast)]

ROFL!

... jedesmal wieder wenn jemand daherkommt und kryptische
Hexzahlen in den Raum wirft um seine Fuses zu zeigen bzw
die Rechnung dazu darzulegen.

Dabei ist es soooo einfach wenn man die Original Tools von
Atmel benutzt. Die Hexzahlen werden nach einleuchtenden
verbalen Vorgaben von der Programier-GUI berechnet und man
macht dadurch fast automatisch alles richtig. Auch bekommt
man sofort nach Programmierung ein optisches Feedback über
Erfolg oder Misserfolg.

Ich programmiere jetzt seit mindesten 10 Jahren mit AVR
Controllern und habe die Fuses niemals selbst berechnet,
immer praktisch "im Schlaf" den Controller richtig
programmiert. Dabei hab ich natürlich verpasst mir durch
Kauf von China-Ware sieben Euro fuffzich zu sparen. Das
bereue ich sehr, denn das hätte sich wirklich gelohnt.

Atmel mag auch nicht immer alles richtig gemacht haben,
beim Programmieren der Fuses haben sie jedenfalls Nägel
mit Köpfen gemacht.

Ich freue mich schon auf das nächste Hex-Zahlen-Gefecht
mit den AVR-Fuses. Wenn sich die geplagten User und die
Helfer sich gegenseitig die Hex-Würschte um die Ohren
hauen. Immer wieder lustig.

[MaWin O. (mawin_original)]

Peter D. schrieb:
> Nirgends. Man kann es nur ausprobieren.

Wenig glaubwürdig.

> Z.B schreib ein Blinkprogramm, was nach je 10s den CPU-Prescaler
> umschaltet.
> Dann drück irgendwann die Resettaste und es blinkt mit dem letzten Takt
> weiter.

Kann ich nicht nachvollziehen. Ich habe wie gesagt noch nie einen POR 
nach Fuse-write gemacht. Nur den vom Programmer generierten externen 
RST.

[MaWin O. (mawin_original)]

Peter Lustig schrieb:
> Immer wieder lustig.

Danke für den wertvollen Beitrag. Nicht.

[MaWin (noch originaler) (Gast)]

MaWin O. schrieb:
> Peter Lustig schrieb:
> Immer wieder lustig.
>
> Danke für den wertvollen Beitrag. Nicht.

Ich hoffe, das war jetzt nicht ironisch gemeint!
Im Prinzip hat Peter Lustig mit den Fuses ja Recht.