Hää?

Nun, vielleicht hättest Du ja statt des ,,Hää'' ja lieber mal
beschreiben sollen, was denn bei Dir nicht funktioniert.

Ich bekomme jedenfalls in der Simulation einwandfrei einen
Rechteck mit einer Periodendauer von ca. 115 ms (@ 8 MHz CPU)
an PB0.

hmm nunja wenn ich das ganze kompiliere und auf nen AT90S4433 schreibe 
dann tut sich garnix

wenn ich es allerdings so mache:

#include <avr/io.h>

void main(void)
{
  unsigned int i;
  DDRB = 0xFF;
  while(1) {
    PORTB = 0;
    for(i=0; i<0xFFFF; i++) { asm volatile ("nop"); }
    PORTB = 1;
    for(i=0; i<0xFFFF; i++) { asm volatile ("nop"); }
  }
}

und dies dann kompiliere und auf meinen AT90S4433 schreibe funktioniert 
es

also wieso funktioniert das oben nicht aber das hier funzt?

MFG Marcel

Wie geschrieben: bei mir funktioniert die Version, die bei Dir
nicht tut, sehr wohl.  (OK, in der Simulation, einen Chip zum
Testen habe ich jetzt hier nicht zur Hand.)

Aber ich habe da so einen Verdacht... Du hast -mmcu=$(MCU) in
Deiner Linker-Kommandozeile vergessen (also in dem Aufruf von
avr-gcc, der das Linken vornimmt).  Dadurch wird für den
falschen AVR gelinkt, was zur Folge hat, daß der Stack im
Nirvana landet.  Stört keinen bis zu dem Moment, da Du die erste
Funktion aufrufen willst...

Ein Standard-Makefile-Template ist bei WinAVR wohl dabei.  Das
solltest Du als Basis für Dein eigenes Makefile benutzen.

ok danke ich werds mal versuchen...

wie genau und womit simulierst du denn deine programme?

MFG Marcel

Mit VMLAB, siehe http://www.amctools.com/ -- man verzeihe mir
die Schleichwerbung.  Ist Payware, hat aber eine deutlich
bessere Peripherie-Simulation als AVR Studio und für mich vor
allem den Vorteil, daß es auf meinem FreeBSD mit dem Wine
Windows-Emulator läuft.

Alternativ habe ich avr-gdb + simulavr zum Simulieren.  Vorteil
ist, daß es Freeware ist und der GDB als Debugger an Features
von keinem noch so ausgefeilten GUI wirklich zu schlagen ist,
außerdem kann man auf die vollen Debug-Informationen der ELF-Datei
zurückgreifen.  Nachteil ist, daß simulavr praktisch nur zum
Simulieren reiner Algorithmen geeignet ist und nur rudimentäre
IO-Fähigkeiten besitzt.  Ohne avr-gdb und simulavr hätte aber
das avr-libc Projekt weder ein malloc() noch eine komplette
printf() und scanf() Familie, zumindest nicht aus meiner Feder
(bei printf() nur teilweise, die Basis unseres printf() ist
von Alexander Popov geschrieben worden, von dem ich leider
seither nichts mehr gehört habe).

Oder wird die Delay schleife vom Compiler wegoptimiert?

Werner

Nein, warum sollte sie denn?  Erstens gäbe es keinen Grund,
warum der Compiler sie innerhalb einer Funktion wegoptimieren
sollte und innerhalb von main() nicht (Marcel schrob ja, daß
es beim direkten Einfügen in main() tut), zweitens hat Marcel
im Body der Schleife ordentlich ein »asm volatile("nop")«
stehen, der Compiler darf das also gar nicht wegoptimieren,
drittens kann man sich den generierten Assemblercode ja ruhig
ansehen, und schließlich habe ich nicht umsonst die sich
ergebende Ausgangsfrequenz meiner Simulation mit gepostet, der
man ebenfalls entnehmen kann, daß es sich um ein deutliches
Delay handelt.

hi ich bins nochmal,

also joerg hatte recht, ich hatte als mmcu einen falschen AVR gesezt -> 
autsch :D

danke für eure hilfe...

MFG Marcel