Ausgang toggeln

1

    while(1){

2

        PORTB = 0b11111111;  //PB0 im PORTB setzen

3

        _delay_ms(1000);       //1000ms warten

4

5

        PORTB = 0b00000000; //PB0 im PORTB löschen

6

        _delay_ms(1000);       //1000ms warten

7

    }

Mag zwar gehen, ist aber unschön, da du hier jeweils das ganze 
Portregister änderst.

Besser

1

    while(1){

2

        PORTB |= (1<<0);  //PB0 im PORTB setzen

3

        _delay_ms(1000);       //1000ms warten

4

5

        PORTB &= ~(1<<0); //PB0 im PORTB löschen

6

        _delay_ms(1000);       //1000ms warten

7

    }

oder

1

    while(1){

2

        PORTB ^= (1<<0);  //PB0 im PORTB togglen

3

        _delay_ms(1000);       //1000ms warten

4

}

oder ...

Spielt aber alles keine Rolle, wenn der µC nicht wie in F_CPU angegeben 
mit 16Mhz läuft sondern nur mit 1MHz, wie es im Kommentar steht.

Nein. Der Mega läuft nicht automatisch mit 16Mhz, nur weil du bei F_CPU 
das so  hinschreibst. F_CPU ist die Information für den Compiler aber 
was du da hinschreibst interessiert den eigentlich IC nicht die Bohne. 
Der läuft so schnell, wie er eben eingestellt ist.
Allerdings führt eine Falschangabe bei F_CPU dann dazu, dass die Zeiten 
bei _delay_ms nicht stimmen. Wenn dein Mega also tatsächlich noch immer 
mit 1Mhz läuft, du deinen Compiler aber mit den 16Mhz angelogen hast, 
dannn dauern die _delay_ms jetzt alls 16 mal so lange. D.h deine LED 
blinkt nicht im Sekundentakt, sondern nur alle 16 Sekunden. Und das ist 
eine lange Zeit, bei der man schon mal die Geduld verlieren kann und 
'funktioniert nicht' diagnostiziert.

Karl H. schrieb:
> Der Mega läuft nicht automatisch mit 16Mhz, nur weil du bei F_CPU
> das so  hinschreibst.

Es wäre nicht schlecht, wenn man die Fuse-Bits, wie in BASCOM möglich, 
mit dem $PROG-Kommando im Quelltext einstellen könnte.

Ja, ich weiß: hier geht es um "C". Aber man sieht manchmal Sachen, die 
in anderen Sprachen (und Entwicklungsoberflächen) schöner sind.

mfG Paul

Stefanie schrieb:
> Ja die Betriebsspannung ist bei 4,5V
> Ich glaube das Problem liegt wo ganz wo anders.
> Ich benutze den AVR MK2 Programmer, den steuere ich unter Ubuntu an.
> für das vorherige Projekt hatte ich die richtige .elf Datei.

Die interessiert nicht.
Letzten Endes kommt aus dem ganzen Compilierprozess eine HEX-Datei raus. 
Und die wird gebrannt.

> Bei neuen
> Projekt natürlich nicht mehr.
> Kann mir jemand sagen wie ich diese unter Ubuntu anpassen kann?

Kopfkratz.
Du hast doch irgendein Brennprogramm. Und dem kannst du angeben, wie die 
HEX-Datei heisst, die du brennen willst und auf welchem Verzeichnis sie 
ist.
Wo also liegt das Problem?

Stefanie schrieb:
> d.h. ich benötige gar keine .elf Datei?
> Ich programmiere unter Eclipse und Ubuntu

Autsch. Bitte, lern die Grundlagen. Sonst wird das nichts.
Hier gehts los: AVR-GCC-Tutorial

@Karl Heinz:

Speziell unter Linux wird sehr wahrscheinlich avrdude verwendet.
Und der kann seit einigen Releases das .elf Binary direkt flashen.
Die Extraktion des Flash-Segments und Umwandlung nach Intel HEX
ist nicht mehr zwingend notwendig.

Axel S. schrieb:

> Speziell unter Linux wird sehr wahrscheinlich avrdude verwendet.
> Und der kann seit einigen Releases das .elf Binary direkt flashen.

Ah. Danke. Das wusste ich nicht.
Hatte mich insgeheim ohnehin schon gewundert, warum das Brennprogramm 
anscheinend die ELF Datei akzeptiert und keinen Fehler meldet. Jetzt ist 
klar warum.

Bleibt aber immer noch die Frage, warum sie dann nicht weiss welche 
Datei sie flasht und ob das die richtige ist.

Also bei Eclipse mit Plugin und avrdude erzeugt ja normalerweise das 
plugin selber den richtigen aufruf für "den dude".
Wie hast du das denn konfiguriert ?

@Asd
Danke für die Auskunft.

mfG Paul