ATtiny45 delay doppelt so lang wie gewollt

[Stefan R. (Gast)]

Hallo,

ich fange gerade an, mit einem ATtiny45 zu programmieren. Bei meinen 
Aufrufen der delay-Funktion wundert mich, dass die Zeiten doppelt so 
lang sind wie gewollt. Ich habe also zunächst noch einmal die Angaben 
zur clock rate im Quelltext und auch die Fuses auf dem µC selbst 
überprüft. Wenn ich meine Fuses mit avrdude auslese

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF

und dann die Werte bei

http://www.engbedded.com/fusecalc/

eingebe, bekomme ich raus, der Chip laufe auf 8MHz, geteilt durch 8. Ich 
komme rechnerisch also auf 1MHz. Das habe ich dann im Quelltext auch so 
vermerkt.


#define F_CPU 1000000
#include <util/delay.h>
#include <avr/io.h>

int main(){
  while(1){
    PORTB |= (1<<PB1);
    _delay_ms(1000);
    PORTB ^= ~(1<<PB1);
    _delay_ms(1000);
  }
}



Trotzdem dauern die 1000ms aber jeweils 2 Sekunden—also 2 Sekunden LED 
an, dann2 Sekunden aus.

Wenn ich die Fuse für den 8-fach-Teiler mal rausnehme, passiert quasi 
das gleiche: dann blinkt die LED eben auch bei

#define F_CPU 8000000

doppelt so schnell wie sie soll. Klar, ich kann jetzt einfach 4000000 
bzw. 500000 eintragen, damit alles wieder stimmt, aber das kann ja nicht 
die Lösung sein.

Ich habe nun schon recherchiert, aber komme einfach nicht drauf. 
Vielleicht sehe ich auch den Wald vor lauter Bäumen nicht mehr.

Gruss,
Stefan

[edi_r (Gast)]

Stefan R. schrieb:
> #define F_CPU 1000000

Stefan R. schrieb:
> doppelt so schnell wie sie soll.

Vermutlich meinst Du: halb so schnell wie sie soll.

Ich weiß nicht, ob's was bringt, aber schreib mal den Datentyp (das "UL" 
am Ende) zur Frequenz dazu:

#define F_CPU 1000000UL

[Stefan R. (Gast)]

Oh, da hatte ich mich vertan. Ich meinte natürlich halb so schnell, wie 
sie soll.
Allerdings hat das Ändern auf

#define F_CPU 1000000UL

leider auch nichts geändert.

[Timmo H. (masterfx)]

Hatte erst gedacht, dass es das Problem ist: 
Beitrag "Re: _delay_ms() läuft 4 Mal schneller als erwartet"
Aber vielleicht doch nicht?!

[avr_gast (Gast)]

Hallo, ich glaube du must in delay.h nachgucken, was da für ein Wert für 
F_CPU eingegeben ist. Du redefinest nähmlich die Frequenz wenn du ,
#include <util/delay.h> nach #define F_CPU 1000000 setzt.

Gruß

[Michael (Gast)]

Kann nicht das Problem sein, denn dann dürfte sich bei
    #define F_CPU 8000000
nichts ändern.

[Peter II (Gast)]

avr_gast schrieb:
> Hallo, ich glaube du must in delay.h nachgucken, was da für ein Wert für
> F_CPU eingegeben ist. Du redefinest nähmlich die Frequenz wenn du ,
> #include <util/delay.h> nach #define F_CPU 1000000 setzt.

nein, so wir er es gemacht hat ist es richtig. F_CPU sollte vor den 
include stehen.

Wa sagt denn der Simualtor, lass den code doch mal darin laufen?

[Stefan R. (Gast)]

Also ich habe beide Varianten probiert: F_CPU vor und auch nach den 
Includes. Bringt beides dasselbe Resultat. Zum Simulator: ich habe einen 
Mac und darauf habe ich avr-gcc und kompiliere und flashe das ganze aus 
der Kommandozeile heraus. Habe also keine IDE, die einen Simulator o.ä. 
anbieten würde..

[Stefan R. (Gast)]

OK, also das Programm ist ohnehin etwas merkwürdig, aber wie es scheint, 
lag das mit den "doppelten delay-Zeiten", daran, dass ich

   PORTB ^= ~(1<<PB1);

anstatt

   PORTB &= ~(1<<PB1);

geschrieben hatte..
Stefan