AVR Studio und Funktion _delay_ms()

[Michael D. (michael86)]

Nach einer sehr langen Pause bin ich gerade dabei mich wieder in die AVR 
Mikrocontroller einzuarbeiten. Leider scheitere ich schon ganz am Anfang 
an den einfachsten Dingen und finde den Fehler einfach nicht.

Das Programm läuft soweit, nur wenn ich die Funktion _delay_ms verwende, 
kann ich nicht mehr kompilieren.
Hab im Internet schon einiges dazu gelesen, auch Alternativen, aber 
diese funktionieren auch nicht. Was genau mache ich falsch?

Mein Setup:
Atmel STK500, Atmega2561, RS232
Windows 2000 SP4, IE6, AVR Studio 4.19

Da ich erstmal alles wieder deinstalliert habe,
hier die Reihenfolge der Neuinstallation
(falls das einen Unterschied macht)

+ WinAVR-20100110
+ AVR Studio 4.18
+ AVR Studio 4.18 SP1
+ AVR Studio 4.18 SP2
+ AVR Studio 4.18 SP3
+ AVR Toolchain 3.4.2
+ AVR Studio 4.19

Fehlermeldungen:
habe ich teilweise mitprotokolliert als Text-Datei.

Und das Programm:

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

int main()
{
  int delay_time = 2000;

  DDRB = 0xFF;    // PORTB STK500 LEDs
  PORTB = 0x00;

  DDRC = 0xFF;    // PORTC 2x 74C48
  PORTC = 0x00;

  for (;;)
  {
    for (int i = 0; i <= 255; i++)
    {
      _delay_ms (delay_time);
      PORTB = i;
      PORTB = ~PORTB;
      PORTC = i;
      _delay_ms (delay_time);    
    }
  }
  return 0;  
}

Habe es an einem anderen PC mit AVR Studio 6.1 versucht. Kompiliert 
einwandfrei und lässt sich übertragen
(musste den dazu aber den AVRISP MK2 verwenden, da das STK500 den 
Controller offiziell nicht kennt und ich diesen somit nicht auswählen 
konnte.)
Habe es zeitweise auch mit einem Atmega8515 versucht.

Somit kann es eigentlich nur am Compiler bzw. Linker liegen.
Habe die Atmel Toolchain (verschiedene Versionen) versucht und auch die 
beiden AVRGCC.EXE und MAKE.EXE von WinAVR.
Beides will nicht.

Danke schon mal für die Hilfe.

[Thomas R. (r3tr0)]

Funktioniert es denn, wenn du direkt _delay_ms (2000); schreibst?

[Bauteiltöter (Gast)]

Auf was für einem Computer hast du das installiert?

Das hier:
../8-Bit_Counter.c:20: internal compiler error: Illegal instruction
klingt als wäre der avr-gcc für eine neuere Platform compiliert. Deine 
CPU kennt diese instruction nicht. (z.B. neuster GCC auf einem alten 
386er)

[Michael D. (michael86)]

Nein, es macht keinen Unterschied ob mit oder ohne Variable und auch die 
Zeit auf ein Minimum runtersetzen (1) bringt keinen Erfolg.
Das Programm selbst funktioniert auch (mit einem anderen AVR Studio 
getestet.
Der Kompiler bricht ab, sobald die Funktion _delay_ms() verwendet wird.
Wenn ich sie auskommentiere funktioniert es.

[Ingo Less (Gast)]

Ab einer gewissen Version konnte man keine zur Laufzeit variablen Delays 
mehr machen... Sind nur noch Konstanten möglich.

[Bauteiltöter (Gast)]

Kann man schon ewig nicht (oder noch nie?) Die Cycle-Zähl-Magie hinter 
__delay_ms() rechnet in float und ist darauf angewiesen, dass diese 
Berechnung zur Compiletime gemacht wird.

Wenn man sich daran nicht hält, dann stimmen halt die Zeiten nicht. Das 
darf aber niemals zu einem ICE führen (Internal compile error).
Generel darf C-Code, egal wie falsch er ist, nie zu einem ICE führen. 
Der TO hat also ein Problem mit seiner Toolchain, nicht mit dem 
geschriebenem Programm.

[Michael D. (michael86)]

Bauteiltöter schrieb:
> Auf was für einem Computer hast du das installiert?
>
> Das hier:
> ../8-Bit_Counter.c:20: internal compiler error: Illegal instruction
> klingt als wäre der avr-gcc für eine neuere Platform compiliert. Deine
> CPU kennt diese instruction nicht. (z.B. neuster GCC auf einem alten
> 386er)

Ist ein alter AMD K6 irgendwas. Aber dürfte damit nichts zu tun haben, 
da ich ja für einen MCU kompiliere. Der PC kennt ja die I/O Ports auch 
nicht.Oder verstehe ich das falsch?

Ingo Less schrieb:
> Ab einer gewissen Version konnte man keine zur Laufzeit variablen Delays
> mehr machen... Sind nur noch Konstanten möglich.

Auch als const oder den direkten Wert als Übergabe für die Funktion 
macht keinen Unterschied.

Wie schon gesagt, ich hab es über einen anderen PC zum laufen gebracht, 
nur möchte ich verstehen warum es mit dem alten AVR Studio nicht will.

[Hmmm (Gast)]

Michael D. schrieb:
> Ist ein alter AMD K6 irgendwas. Aber dürfte damit nichts zu tun haben,
> da ich ja für einen MCU kompiliere. Oder verstehe ich das falsch?

Bei einem 20 Jahre alten Prozessor kann es durchaus passieren, dass die 
Toolchain-Binaries Instructions verwenden, die der noch nicht kennt.

Teste mal dasselbe auf aktuellerer Hardware.

[Bauteiltöter (Gast)]

Michael D. schrieb:
> Ist ein alter AMD K6 irgendwas. Aber dürfte damit nichts zu tun haben,
> da ich ja für einen MCU kompiliere. Der PC kennt ja die I/O Ports auch
> nicht.Oder verstehe ich das falsch?

Da verstehst du etwas falsch. Es geht nicht um den Mikrocontroller, 
sondern um das Programm avr-gcc.exe an sich. Das ist für einen viel 
neuere Prozessoren gebaut und verwendet Befehle (für sich selber, nicht 
das, was es generiert!) die dein AMD K6 nicht kann.

Da kann man nichts machen außer einen älteren avr-gcc nehmen.

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

Bauteiltöter schrieb:
> Da kann man nichts machen außer einen älteren avr-gcc nehmen.

… oder sich den Compiler selbst compilieren. Kann aber auf so'ner alten 
Kiste schon mal eine Beschäftigung für einen ganzen Tag werden.

[Ingo Less (Gast)]

Ich will ja garnichts gegen alte Sachen sagen... Aber ist ein 20 Jahre 
altes Setup evtl. nicht etwas viel zu alt? Wenn man sieht, dass man für 
~300€ ein neuen PC der Mittelklasse und somit zum Programmieren völlig 
ausreichend ist?

[Michael D. (michael86)]

Hab noch ne alte Toolchain 3.2.3 gefunden und getestet.
Jetzt funktioniert alles.
Danke für den Tipp, hab die ganze Zeit versucht immer neuer zu 
installieren.

Ja, der PC ist vielleicht nicht mehr ganz zeitgemäß, aber für meine 
Bastel-Projekte war er immer ausreichend. Außerdem lauft auf dem auch 
noch die alte Software für meine Geräte. Die müsste ich dann auch alle 
mit nem neuen PC mit ersetzen.

[Rolf M. (rmagnus)]

Das sollte zwar nicht die Ursache für dieses spezifische Problem sein, 
abr:

> avr-gcc  -mmcu=atmega8515

Warum Compilierst du Code für einen mega8515, wenn du in Wirklichkeit 
einen

Michael D. schrieb:
> Atmega2561

hast?