_delay klappt nicht wie es soll

[avrRookie (Gast)]

Hi,

verwende AVR Studio 5, internen 8MHz Oscillator und CKDIV ist disabled.

Wenn ich die F_CPU verändere ändert sich nicht die Blinkzeit.

Woran kann das liegen?

[Peter II (Gast)]

avrRookie schrieb:
> Woran kann das liegen?

das delay ja nicht von deiner F_CPU weiss, weil du es nach
#include <util/delay.h>

erst setzt.

[avrRookie (Gast)]

Vielen Dank.
Problem gelöst.

[Simon K. (simon)]

#define F_CPU gehört in kein .c File rein, sondern muss beim 
Compileraufruf (Projektoptionen) angegeben werden!

[Da D. (dieter)]

Simon K. schrieb:
> muss beim
> Compileraufruf (Projektoptionen) angegeben werden!

Nein. Kann, muss nicht. Hauptsache es ist definiert, wenn der 
Preprozessor das #include <util/delay.h> zu fressen bekommt.

[Karl H. (kbuchegg)]

Da Dieter schrieb:
> Simon K. schrieb:
>> muss beim
>> Compileraufruf (Projektoptionen) angegeben werden!
>
> Nein. Kann, muss nicht.

Prinzipiell richtig.
Hat man allerdings irgendwann mal mehrere C-Files in einem Projekt, dann 
wird es mühsam, die alle auf gleich zu halten.
Viel einfacher und sicherer ist es dann, in den Projekt Optionen 
einmalig und nur an einer Stelle den Wert für F_CPU vorzugeben.

Man muss sich ja nicht vorsätzlich mögliche Fehlerquellen in sein 
Programm einbauen. Das Leben als Programmierer ist auch ohne solche 
Stolpersteine schon schwer genug.
Eines der Merkmale, die einen guten Programmierer ausmachen ist es auch, 
dass er seinen Code so gestaltet, dass er sich selbst möglichst wenig 
Türen für Fehler offen lässt. Er ist sich bewusst, dass er Fehler macht 
und arbeitet daran, sich selbst ein Sicherheitsnetz zu spinnen, so dass 
konkrete Fehlersituationen gar nicht erst entstehen können.

[Da D. (dieter)]

Karl Heinz Buchegger schrieb:
> Prinzipiell richtig.
> Hat man allerdings irgendwann mal mehrere C-Files in einem Projekt, dann
> wird es mühsam, die alle auf gleich zu halten.
> Viel einfacher und sicherer ist es dann, in den Projekt Optionen
> einmalig und nur an einer Stelle den Wert für F_CPU vorzugeben.
>
> Man muss sich ja nicht vorsätzlich mögliche Fehlerquellen in sein
> Programm einbauen. Das Leben als Programmierer ist auch ohne solche
> Stolpersteine schon schwer genug.
> Eines der Merkmale, die einen guten Programmierer ausmachen ist es auch,
> dass er seinen Code so gestaltet, dass er sich selbst möglichst wenig
> Türen für Fehler offen lässt. Er ist sich bewusst, dass er Fehler macht
> und arbeitet daran, sich selbst ein Sicherheitsnetz zu spinnen, so dass
> konkrete Fehlersituationen gar nicht erst entstehen können.

Völlig richtig. Aber trotzdem kann man nicht sagen, man muss das in 
den Projekt Einstellungen machen. Ich nehme für sowas immer ein globales 
Headerfile. Find ich persönlich deutlich praktischer, als irgendwelche 
Projekteinstellungen. Denn: Auch das ist eine Fehlerquelle, wenn man das 
Projekt mal neu aufsetzt, die IDE wechselt, oder den Code mal weiter 
gibt.

[Marwin (Gast)]

Da Dieter schrieb:

> Völlig richtig. Aber trotzdem kann man nicht sagen, man muss das in
> den Projekt Einstellungen machen. Ich nehme für sowas immer ein globales
> Headerfile.

Und das ist immer noch eine grosse Fehlerquelle.

> Find ich persönlich deutlich praktischer, als irgendwelche
> Projekteinstellungen. Denn: Auch das ist eine Fehlerquelle, wenn man das
> Projekt mal neu aufsetzt, die IDE wechselt, oder den Code mal weiter
> gibt.

Das ist wesentlich unwahrscheinlicher, als den Include fuer's globale 
Headerfile mal zu vergessen. Oder ihn wegzulassen, weil man meint, in 
diesem File wuerde er ja nicht gebraucht. Und gegen ein Vergessen im 
Makefile/den Projekteinstellungen kannst du immer noch einen Check in 
dein globales Headerfile einbauen.

[Da D. (dieter)]

Jetzt wirds langsam philosophisch... Und da dann sowieso jeder auf 
deinem Standpunkt verharrt, bin ich mal raus...

[Karl H. (kbuchegg)]

Da Dieter schrieb:
> Jetzt wirds langsam philosophisch... Und da dann sowieso jeder auf
> deinem Standpunkt verharrt, bin ich mal raus...


Dein globales Header File ist solange gut, solange du es tatsächlich 
überall includierst (was sich bei Code der in Library-Directories liegt 
als gar nicht so einfach erweist)

UND

solange du nicht die vermeintliche Sicherung

#ifndef F_CPU
#define F_CPU 1000000UL
#endif

benutzt. Denn die ist die eigentliche Fehlerquelle, die Fehler verdeckt. 
Leider hat sich dies 'Sicherung' vor Jahren mal eingebürgert und ist 
heute nicht mehr auszurotten.

[Da D. (dieter)]

Karl Heinz Buchegger schrieb:
> #ifndef F_CPU
> #define F_CPU 1000000UL
> #endif

Nej, also was das soll hab ich auch nie verstanden. Das verdeckt doch 
nur Fehler. Wer sich das ausgedacht hat, gehört durch den Präprozessor 
gedreht... ;)

Und es kann ja wohl nicht so schwer sein, in seine Sourcefiles ein 
Headerfile zu includieren! Erstens gibts ne Warnung vom Delay, wenn man 
das vergisst und zweitens stehen in dem Header ja auch noch andere Dinge 
drin. (defindes für Pinzuordnung z. B.).

[Frank M. (ukw) (Moderator)]

Karl Heinz Buchegger schrieb:
> Denn die ist die eigentliche Fehlerquelle, die Fehler verdeckt.
> Leider hat sich dies 'Sicherung' vor Jahren mal eingebürgert und ist
> heute nicht mehr auszurotten.

Auch sehr böse:

avr/include/util/delay.h:

#ifndef F_CPU
/* prevent compiler error by supplying a default */
# warning "F_CPU not defined for <util/delay.h>"
# define F_CPU 1000000UL
#endif

Besser wäre hier ein #error. Stattdessen wird nur eine Warnung gezeigt 
und F_CPU auf obigen Phantasiewert gesetzt.

Ab AVR Studio 5.1 werden Warnungen nicht mehr in der Summary ausgegeben 
und daher schnell übersehen.

[Marwin (Gast)]

Da Dieter schrieb:
> Und es kann ja wohl nicht so schwer sein, in seine Sourcefiles ein  Headerfile 
zu includieren!

Wenn du nur ein paar Source-Files in deinen Hobby-Projekten hast, wirst 
du das im Griff haben. Es gibt hier aber auch Leute, die arbeiten an 
richtigen Projekten, in Teams mit zig Leuten zusammen.

[Da D. (dieter)]

Marwin schrieb:
> Wenn du nur ein paar Source-Files in deinen Hobby-Projekten hast, wirst
> du das im Griff haben. Es gibt hier aber auch Leute, die arbeiten an
> richtigen Projekten, in Teams mit zig Leuten zusammen.

Ja, ja, der übliche Schwachsinn von Marwin wieder... Ich hab genug über 
dich gelesen, um gar nicht erst zu versuchen, dir klar zu machen, dass 
es auch im beruflichen Umfeld von deiner Meinung abweichende Methoden 
geben kann...

[Karl H. (kbuchegg)]

Da Dieter schrieb:

> Und es kann ja wohl nicht so schwer sein, in seine Sourcefiles ein
> Headerfile zu includieren!

Na dann probier mal Folgendes.

Folgende Directory Structur

  + Irgendwas
    + Projektverzeichnes 'Proj1'
    + Lib-Verzeichnis 'Lib'

Die Idee dahinter ist es, dass identischer Code wie zb. LCD Ansteuerung 
oder UART in einem eigenen Verzeichnis, welches von mehreren Projekten 
benutzt werden kann, zu liegen kommt und man die jeweiligen C-Files 
einfach nur zum Projekt hinzufügt (also nicht in das Projekt kopiert, 
sondern aus dem Projekt in das Lib Verzeichnis 'verlinkt')

Im Lib Verzeichnis liegt zb ein
lcd.c

#include <stdio.h>
#include "config.h"

void foo()
{
  printf( "%ld", F_CPU );
}

Die Idee dahinter ist es, dass die tatsächliche Konfiguration (wie zb 
F_CPU oder auch die tatsächlich zu benutzenden Pins für den LCD 
Anschluss) vom Projekt genommen werden, in dem es dort ein config.h 
geben soll

Ergo hast du auf dem Projektverzeichnis 2 Dateien
main.c

#include <stdio.h>
#include "config.h"

int main()
{
  printf( "%ld", F_CPU );
}

und (das ist das entscheidende), ein
config.h

#define F_CPU 1000000UL

so weit so gut. Das Setup ist gemacht und sieht in der Dateihierarchie 
so aus:

  + AVR-Projekte
    + Projekt1
        main.c
        config.h
    + Lib
        lcd.c

Im AVR-Studio sind main.c und ../Lib/lcd.c als zum Projekt zugehörig im 
Projektbaum eingetragen.

Ein Build aufgerufen und was sehen wir:

../Lib/lcd.c:2:20: error: config.h: No such file or directory
../Lib/lcd.c: In function 'foo':
../Lib/lcd.c:6: error: 'F_CPU' undeclared (first use in this function)
../Lib/lcd.c:6: error: (Each undeclared identifier is reported only once
../Lib/lcd.c:6: error: for each function it appears in.)

Warum ist das so?
Weil für lcd.c das Verzeichnis auf dem lcd.c liegt als 
Standardverzeichnis für Includes gilt. Dort gibt es aber kein config.h

Klar kannst du das mit zusätzlichen Include-Pfaden in den Griff kriegen. 
Wenn du das aber sowieso machen musst, dann kannst du auch gleich in den 
Compiler Settings ein globales Symbol für F_CPU eintragen. Das schenkt 
sich nichts.

(aktuell getestet mit einem zugegebenermassen etwas älterem AVR-Studio 
4)