_delay_ms geht viel länger

[Pascal (Gast)]

Hallo bin blutiger Anfänger,
Als Board benutze ich ein Eval. Board von Pollin.
Nun habe ich ein kleines Testprg. geschrieben für einen Atmega8.
Eine LED soll jeweils 0.5Sekunden an sein, danach wechselt es zur andern 
LED. Nun beträgt die Delay Zeit aber ca. 3Sekunden. woran kann das 
liegen?

Beim Makefile habe ich Otimierung stufe 3 eingestellt.

Danke


#define KEY_ONE      PD5
#define KEY_TWO      PD6
#define ONE_ON        PORTD |= (1 << PD5);
#define ONE_OFF       PORTD &=~(1 << PD5);
#define TWO_ON        PORTD |= (1 << PD6);
#define TWO_OFF       PORTD &=~(1 << PD6);

#include <avr/io.h>
#include <util/delay.h>

int main()
{
  // Port Ausgänge
  DDRD =   (1 << KEY_ONE) | (1 << KEY_TWO);

  while(1)
  {
    TWO_ON;
  _delay_ms(500);  //500ms warten...
  TWO_OFF;
  ONE_ON;
  _delay_ms(500);  //500ms warten...
  ONE_OFF;
  }
}

[spess53 (Gast)]

Hi

CKDIV8-Fuse?

MfG Spess

[Klaus W. (mfgkw)]

Oder Fuses nicht/falsch gesetzt, oder F_CPU falsch definiert,
oder -O3 macht Mist - meines Wissens stimmen die _delay-Dinger
nur bei-Os. Letzteres weiß ich jetzt aber nicht, ohne nachzusehen.

[g457 (Gast)]

Wie (und wo) hast Du denn F_CPU definiert?

[Pascal (Gast)]

Am Anfang hatte ich die F_CPU nur im Makefile, nun aber auch im main.c, 
ohne Änderung.
Werde mal Fuses oder Opt S versuchen.

Danke Pascal

[Karl H. (kbuchegg)]

Pascal schrieb:
> Am Anfang hatte ich die F_CPU nur im Makefile, nun aber auch im main.c,
> ohne Änderung.
> Werde mal Fuses oder Opt S versuchen.

Du kannst dein F_CPU haben wo immer du willst.
Solange die dort gemachte Angabe nicht mit der Taktfrequenz 
übereinstimmt, mit der der µC tatsächlich läuft, wird _delay_ms nicht 
stimmen.

F_CPU ust eine Information für den Compiler. Aber der µC läuft deswegen 
nicht schneller oder langsamer sondern immer noch mit der am µC 
eingestellten (entweder interner Takt oder Quarz oder ...) Taktfrequenz

[Florian M. (micro-flo)]

Guck Dir auch mal die Beschreibung von _delay_ms.

The maximal possible delay is 262.14 ms / F_CPU in MHz.

500ms gehen also nur mit um die 500kHz Takt.

[Wichtel (Gast)]

Florian Micro schrieb:
> Guck Dir auch mal die Beschreibung von _delay_ms.

Da steht in halbwegs aktuellen Versionen (seit min. 1 Jahr) auch 
folgendes:

When the user request delay which exceed the maximum possible one, 
_delay_ms() provides a decreased resolution functionality. In this mode 
_delay_ms() will work with a resolution of 1/10 ms, providing delays up 
to 6.5535 seconds (independent from CPU frequency). The user will not be 
informed about decreased resolution.

[Micha S. (e-tec)]

schöner ist da sowieso soetwas (und genauer auch da delay fktn nur eine 
bergrenzte zeit hat):

#define ui16 unsigned short

void ms_delay(ui16 millisekunden)
{
   for(; millisekunden > 0; millisekunden--)
   {
      _delay_ms(1);
   }
}
das ist auf die dauer genauer.
aber ich kenne dein problem, nutze dezeit einen attiny2313, fcpu ist 
gesetzt, fuses sind auf externen quarz gestellt (8mhz) und die funktion 
läuft ca 1000 mal schneller als sie soll (also rein von der optischen 
"analyse") mit dem oszi werde ich mal alles messen sobald ich eines habe 
um der sache auf den grund zu gehen...

[Mr Obvious (Gast)]

Micha S. schrieb:
> das ist auf die dauer genauer.

Nimm _delay_ms. Das implementiert auch nur diese For-Schleife. (Ok, als 
"while" mit 10-Fach höherer Auflösung, whatever)

Und wenns genau werden soll, muss eh der Timer ran.

Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out". 
Schau dir mal den "stdint.h"-Header an, den jeder C-Compiler, der nicht 
im letzten Jahrtausend stehen geblieben ist, mitliefert.

Micha S. schrieb:
> läuft ca 1000 mal schneller als sie soll

Hört sich nach wegoptimierter Schleife an...

[Mitleser (Gast)]

>Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out".
Müsste das nicht eh "umgekehrt" sein? (typedef unsigned short ui16)

[Micha S. (e-tec)]

out?
sorry aber das ist mir ziemlich egal was in und was out ist...
ist gewöhnungssache, beim arbeiten schaffen wir so daheim auch, sag ja 
nicht das es jemand übenehmen muss :)

wegoptimierte schleife?
hm ja wäre möglich, muss ich mal probieren (opt level ist 0s), muss ich 
mal probieren... wenn die _delay_ms() mit 1000 aber auch so schnell 
läuft dann wirds wohl woanders liegen.

die delay funktioen sind eh nur für "anfänger" da sie während der verz 
den prozessor blockieren, also nicht grad das gelbe vom ei... aber wems 
so reicht warum nicht?
wenn ich nur ne led blinken lassen würde würd ich die ebenfalls 
benutzen!

[Micha S. (e-tec)]

Mitleser schrieb:
>>Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out".
> Müsste das nicht eh "umgekehrt" sein? (typedef unsigned short ui16)

bei typedef ja bei #define nein!

[Mitleser (Gast)]

Micha S. schrieb:
> Mitleser schrieb:
>>>Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out".
>> Müsste das nicht eh "umgekehrt" sein? (typedef unsigned short ui16)
>
> bei typedef ja bei #define nein!

Arghh, verguckt. Bei #define ist das natürlich richtig.