AtmelStudio 7 util/delay.h funktioniert nicht

Dominik schrieb:
> die F_CPU=16000000 hab ich in den Symbols Deklariert.

Da ist entweder ein Tippfehler drin oder es kommt beim C-Compiler nicht 
an.

Auch Atmel Studio kann die komplette Kommandozeile ausspucken die beim 
Kompilieren ausgeführt wird. Schau Dir die mal genau an.

Dominik schrieb:
> die F_CPU=16000000 hab ich in den Symbols Deklariert.

Ein Screenshot wäre hilfreich. Vergiss nicht, diese Definition sowohl 
für Debugging als auch Release einzutragen.

define schrieb:
> in meinem Code ist die korrekte definition für den Takt:

Darum gehts nicht, ein #define im C-Code einfügen kann jeder.

Es geht darum, diese Definition projektweit anzulegen, damit man das 
nicht in allen C-Modulen separat machen muss. Ein Projekt kann nämlich 
durchaus aus mehr als einem C-Modul bestehen.

Zeig den nicht funktionierenden Code mit F_CPU define, oder einen 
Screenshot von den Symboleinstellungen. Alles andere hilft nicht weiter.

Oliver
P.S. wenn du das define in den Code schreibst, muß das VOR
#include <util/delay.h>
Stehen.

Dominik schrieb:
> die F_CPU=16000000 hab ich in den Symbols Deklariert.

Falsch.  F_CPU muss ein Makro sein, also per #define im Code oder per 
-DF_CPU=xxx bei den Optionen.

Ein Symbol ist was anderes, das würde man per -Wl,--defsym,F_CPU=xxx 
definieren.

Johann L. schrieb:
> Falsch.  F_CPU muss ein Makro sein, also per #define im Code oder per
> -DF_CPU=xxx bei den Optionen.

Das passt schon, die IDE (und alle anderen, die die Optionsdialoge bei 
Eclipse abgeschaut haben) nennt das halt Symbol.

Oliver

Oliver S. schrieb:
> Johann L. schrieb:
>> Falsch.  F_CPU muss ein Makro sein, also per #define im Code oder per
>> -DF_CPU=xxx bei den Optionen.
>
> Das passt schon, die IDE (und alle anderen, die die Optionsdialoge bei
> Eclipse abgeschaut haben) nennt das halt Symbol.

Prima.  Und Symbole heißen wie?  Vermutlich "Macros" oder "Defines"...

Dominik schrieb:
> Aber es funktioniert trotzdem nicht.

Woher du wissen?

Da der Screenshot allerdings die Optionen für Configration Debug zeigt, 
vermute ich mal, daß du ohne Optimierung kompilierst. Das sollte dann a) 
doch eine Warnung vom Preprozessor geben, und b) funktioniert das Delay 
dann nicht, wie erwartet. RTFM.

Oliver

Dominik schrieb:
> Aber es funktioniert trotzdem nicht.

Was heisst das: Dauern die Delays jetzt vielleicht 16 mal so lang?

Die AVR-Delay-Funktionen funktionieren nur dann korrekt, wenn man die 
Optimierung eingeschaltet hat. Also: Stell das Projekte mal auf 
"Release" statt "Debug" um.

Noch etwas: Ist Dein µC per Fuses überhaupt auf Quarzbetrieb umgestellt? 
Wenn nicht, läuft der nämlich mit internem 8MHz-Oszillator-Takt.

Und dann gibt es noch die CKDIV8 Fuse: Wenn Du diese nicht deaktivierst, 
wird der Takt nochmal durch 8 geteilt und Dein µC rennt nur mit einem 
Achtel, also lediglich 1MHz. Das ist die Standard-Einstellung jedes 
fabrikneuen AVRs.

Fazit: Wenn Du die Fuses nicht korrekt konfigurierst, dauert jeder Delay 
tatsächlich 16-mal so lang wie Du erwartest.

Dominik schrieb:
> war ein Tipp fehler

Noch einer:
PORTB = 0X00;

Dominik schrieb:
> Fuses :        EXTENDED : 0xFD
>         HIGH     : 0xD6
>         LOW      : 0XFF

Laut Fusecalc

  http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p&LOW=FF&HIGH=D6&EXTENDED=FD&LOCKBIT=FF

sieht das gut aus.

> Der uc macht Gar nichts er führt DDRB = 0xFF und PORTB = 0x00 aus.
> dan friert er ein und macht gar nichts mehr.

Woran erkennst Du das? Am Verhalten im Debugger? Wie gesagt: _delay_ms() 
ist ohne Compiler-Optimierung unbrauchbar. Da gibt es hier zig Threads 
zu diesem Thema.

Ich habe es mal getestet - auch im Debugger funktioniert es (dauert halt 
einige Sekunden und keine 200 ms). Bei Symbols trage ich 
F_CPU=16000000UL ein.

Vielleicht Atmel Studio mal updaten / neu installieren?

Edit: Stottermodus aus :-)

Die entsprechende Bibliothek installiert ? Atmel Studio hat die 
Eigenschaft alles ins Projekt zu kopieren.

F_CPU=16000000 muss vor den inkludieren der delay.h stehen. Und sie 
funktioniert nicht mit Optimierung !

Eher nur als nicht.

Oliver

Das habe ich schon mitbekommen und selbst geprüft das diese Aussage 
falsch war....

Uwe Grassmé schrieb:
> Die ganzen anderen #define-Anweisungen im Programm hatten nichts
> gebracht.

Wichtig ist, dass F_CPU vor dem #include <util/delay.h> definiert ist. 
Ob man das nun per #define F_CPU eine Zeile davor schreibt oder auf 
globaler Ebene im Makefile bzw. Projekt, bleibt sich gleich.

Du bekommst allerdings auch eine Warnung, wenn du das nicht richtig 
gemacht hast. Ab da wird mit der Voreinstellung von 1 MHz weiter 
gearbeitet, die für viele AVRs im Auslieferungszustand passend ist.

Stefan ⛄ F. schrieb:
> Ich habe delay immer mit Optimierung benutzt und hatte damit nie
> Probleme.

Kann auch nicht anders sein. All diese "convenience functions" 
(_delay_us() und _delay_ms()) sollen halt "convenient" zu benutzen sein. 
Daher akzeptieren sie eben statt einer festen Anzahl von Zyklen (wie in 
<util/delay_basic.h>) eine Kombination aus einer als Gleitkommazahl 
angebbaren Verzögerungsdauer sowie einer als Gleitkommazahl angebbaren 
Frequenz. Es gibt ja bspw. Quarze mit 7.372 MHz, die kann man als

1

#define F_CPU 7.372E6

angeben. Damit die Gleitkomma-Rechnung aber nicht auf den Code 
durchschlägt, muss man natürlich die Compileroptimierungen aktiv haben.

(Meines Erachtens sollte man Microcontroller-Code sowieso nie ohne 
Optimierungen benutzen, auch zum Debuggen, aber das ist eine andere 
Sache und würde den Rahmen dieses Threads sprengen.)

Dominik schrieb:
> Oliver S. schrieb:
>> Zeig den nicht funktionierenden Code mit F_CPU define, oder einen
>> Screenshot von den Symboleinstellungen. Alles andere hilft nicht weiter.
>>
>> Oliver
>> P.S. wenn du das define in den Code schreibst, muß das VOR
>> #include <util/delay.h>
>> Stehen.
>
>
> Komisch ist jetzt, das ich keine Warnung mehr habe.
>
> Aber es funktioniert trotzdem nicht.

Doch, es funktioniert alles perfekt - auch das Übersetzen. Du solltest 
aber Deine schleife entweder so

1

while(1)

2

{

3

   PORTB = 0x00;

4

   _delay_ms(200);

5

   PORTB = 0xff;

6

   _delay_ms(200); // sonst wird ja sofort wieder umgeschaltet

7

}

oder so:

1

while(1)

2

{

3

   PORTB ^= 0xff; // toggle alle bit auf PORTB

4

   _delay_ms(200);

5

}

schreiben

Ingo E. schrieb:

> Doch, es funktioniert alles perfekt

> Dominik schrieb:

… am 6. Januar, muss man hier ergänzen.

Es hat nicht viel Sinn, jetzt wieder auf alle möglichen Altbeiträge hier 
zu antworten.

Stimmt, aber alle anderen Antworten haben das, was ich geschrieben habe, 
nicht erwähnt - oder ich habe was übersehen.