_delay_ms(xxx) Fehler unter Linux-Code::Blocks

[Gerhard H. (oderlachs)]

Da ich ja kein AVR Studio unter Linux nutzen kann, habe ich mich nun für 
Code::Blocks entschieden.

Nun habe ich eine Programm wo ich auf die delay.h zugreifen muss.
Da bekomme ich immer eine fehlermeldung, da ich die Zeitangabe in einer 
Variablen übergebe.
Gebe ich den Wert in Ziffern ein "_delay_ms(1000)" so ist alles ok.
Aber eine double Variable : 'LED_TIME' wird nicht akzeptiert.

error: conflicting types for ‘delay_us’

Leider sind meine vorhergehenden Aufzeichnungen zur AVR-Programmierung 
unter Linux, leider einem Computercrash zum Opfer gefallen..hoffe ja das 
neuer PC und vor allem die neue HDD länger hält bis ich es begriffen 
hab.

Auch ist mir noch ein "Fremdwort", wie ich dann die *.hex per STK500 auf 
den Chip flashe..

Vielleicht kann mir ja wer helfen und Hinweise geben.. ??

Danke und Gruss

Gerhard

[ich (Gast)]

delay_ms mit einer Variable??
dachte immer das der wert konst sein muss (und ein Integer)
MfG
ich

[Gerhard H. (oderlachs)]

Danke, aber constant..??
Nein das wäre mir ja das Neuste, wie soll ich eine variable 
Zeitabhängigkeit programmieren ..mit einer unveränderlichen Konstanten ?

Unter Win und AVR Studio..läuft das ganze ja...darum ist mir das so 
unbegreifflich

in der Headerdatei xyz.h ist LED_TIME so definiert

double LED_TIME = 1000;  // normale Pausenzeit 1sec.

Das eigendliche Programm verändert die Variable "LED_TIME" je nach 
Anforderung.


Gerhard

[Bernd K. (prof7bit)]

Gerhard Hinze schrieb:

> Danke, aber constant..??
> Nein das wäre mir ja das Neuste, wie soll ich eine variable
> Zeitabhängigkeit programmieren

Doch das ist so. Mach stattdessen eine Schleife mit variabler Anzahl von 
Iterationen mit einer festen Verzögerung.

[PittyJ (Gast)]

wie ist denn delay_us() definiert?
Wenn es einen int erwartet, und du wirfst ein double rein, dann gibt es 
manchmal diese Meldungen (je nach Compiler).
Richtigen Typ benutzen. Oder eventuell casten?

[Gerhard H. (oderlachs)]

Bernd K. schrieb:
> Gerhard Hinze schrieb:
>
>> Danke, aber constant..??
>> Nein das wäre mir ja das Neuste, wie soll ich eine variable
>> Zeitabhängigkeit programmieren
>
> Doch das ist so. Mach stattdessen eine Schleife mit variabler Anzahl von
> Iterationen mit einer festen Verzögerung.


Und doch ist es für mich neu, das es so sein soll, weil es hat ja sonst 
immer geklappt..egal  nun habe ich es so gemacht:

//Millisec.
void delay_ms(uint16_t count)
 {
  while(count--)
   {
    _delay_ms(1);
  }
}
//mMicrosec
void delay_us(uint16_t count) {
  while(count--) {
    _delay_us(1);
  }
}

_delay_ms/_us  ist mit einem double wert in der delay.h definiert

Nachtrag wie es unter Win7/AVR-Studio funktioniert:
LED_TIME ist hier sogar als Integervariable deklariert (!!!):

int main(void)
{
setup_init(); // zuerst immer ausführen !!!!
DDRA |= 0x03; //PA0 + PA1 = Output (1+2 =3)
USART0_Init(UBRR_0) ; //Serial-0 initialisieren  kommt später ins 
Setup-Init
// USART1_Init(UBRR_1) ; //Serial-1 initialisieren  kommt später ins 
Setup-Init

while(1)
{
Led1on();
Led2off();
_delay_ms(LED_TIME);
Led2on();
Led1off();
_delay_ms(LED_TIME);
USART0_TXTStrg("Hallo Freunde") ;
USART0_TXTStrg("Hier ist ATMega128") ;

}
return 0;      //irgendwas zurückgeben
}
hier der bisherige Code als Zip : 
http://robot.oderlachs.de/code/garage1.zip
Ich denke das es an den verschiedenen Compilern liegen muss...

Gerhard

[chris (Gast)]

Gerhard Hinze schrieb:
> Nachtrag wie es unter Win7/AVR-Studio funktioniert:
> LED_TIME ist hier sogar als Integervariable deklariert (!!!)

1.) GROSSBUCHSTABEN sollte man sich lieber für Makros aufheben, und 
nicht für Variablen
also:

#define LED_TIME   1000

2.) da in deinem Programm LED_TIME nicht verändert wird, optimiert der 
Compiler die Variable weg und setzt direkt die konstante Zahl ein. Darum 
hat es dort funktioniert.

lg
Chris

[Jörg W. (dl8dtl) (Moderator)]

Gerhard Hinze schrieb:
> Und doch ist es für mich neu, das es so sein soll,

War schon immer so.

> weil es hat ja sonst
> immer geklappt.

Nur, weil es immer klappt, auf der linken Straßenseite zu fahren,
wird es davon nicht richtig.

[Gerhard H. (oderlachs)]

Jörg Wunsch schrieb:

> Nur, weil es immer klappt, auf der linken Straßenseite zu fahren,
> wird es davon nicht richtig.

ja was sagt da ein Engländer dazu... ?? :)

Ja ich hatte doch wohl anfangs erwähnt, das ich bislang unter Windows 
mit dem AVR Studio gearbeitet habe, darum war ich so erstaunt, warum 
meine Programmierweise nicht mehr geht(unter Linux).

Warum es aber nun nicht mehr soo geht, das weiss ich nun immer noch 
nicht.
Egal, ich weiss das es so nicht mehr geht.

Einen schönen 2. Advent allen wünsche

Gerhard

So nun habe ich die Erklärung(?) gefunden: 
http://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC/_Warteschleifen

Damit ist das Problem erst mals gelöst, obwohl ich es noch nicht ganz 
verstehe warum es so ist...

[Oliver S. (oliverso)]

Gerhard Hinze schrieb:
> Ja ich hatte doch wohl anfangs erwähnt, das ich bislang unter Windows
> mit dem AVR Studio gearbeitet habe, darum war ich so erstaunt, warum
> meine Programmierweise nicht mehr geht(unter Linux).

Je nun, was Jörg dir sagen wollte, ist, daß das Verhalten auf Linux und 
Windows völlig gleich ist.

Die Delay-Funktionen der avrlibc funktionieren seit Anfang der 
Zeitrechnung nur mit Konstanten (und nur mit eingeschalteter 
Optimierung).

Oliver

[Simon K. (simon)]

Oliver S. schrieb:
> Gerhard Hinze schrieb:
>> Ja ich hatte doch wohl anfangs erwähnt, das ich bislang unter Windows
>> mit dem AVR Studio gearbeitet habe, darum war ich so erstaunt, warum
>> meine Programmierweise nicht mehr geht(unter Linux).
>
> Je nun, was Jörg dir sagen wollte, ist, daß das Verhalten auf Linux und
> Windows völlig gleich ist.
>
> Die Delay-Funktionen der avrlibc funktionieren seit Anfang der
> Zeitrechnung nur mit Konstanten (und nur mit eingeschalteter
> Optimierung).

Und es gibt auch auf beiden Systemen eine Warnung bei der 
Kompilierung...

[Jörg W. (dl8dtl) (Moderator)]

Gerhard Hinze schrieb:
> Ja ich hatte doch wohl anfangs erwähnt, das ich bislang unter Windows
> mit dem AVR Studio gearbeitet habe

Würde dort jetzt (mit aktuellem Compiler) genauso wenig gehen.

Ging eigentlich auch früher nie wirklich, war aber eben „nur“ eine
Warnung, jedoch die sich ergebenden Delay-Zeiten waren x-mal so hoch
wie die, die du haben wolltest.