'F_CPU' was not declared in this scope

Deine Problembeschreibung verstehe ich zwar nicht so ganz (ein #define 
vor einem #include sollte eigentlich immer funktionieren), aber am 
einfachsten ist es, solche globalen defines per Compileroption 
(-DF_CPU=1600000) zu definieren. Damit bist du sicher, daß alle 
Sourcedateien den selben Wert bekommem.

EIntellen kannst du das in den Projeksettings.

Oliver

Alexander R. schrieb:
> Die Datei wird dann
> nur an der Seite compiliert

Dir ist aber schon klar, daß in der uart Object Datei das F_CPU=... 
gesetzt ist mit der du die compiliert hast. Ob das dann zu deinem 
aktuellen Projekt identisch ist weiß keiner ausser dir (vieleicht falls 
du aufgepasst hast)

Wenn der Code von solchen externen defines abhängt, ist es weise, die C 
Datei im Projekt immer neu zu compilieren.

Leute ihr habt doch keine 2000 C Dateien und alte Pentium 400 Rechner, 
daß das ne halbe Stunde dauert, das geht doch innerhalb des Bruchteils 
einer Sekunde, so what...

Preprozessor-Anweiseungen wie #include oder #define mache nur eine reine 
Textersetzung. Compiler und linker bekommen davon nie etwas zu sehen.

Wenn du in der main.c ein #define definierst, dann ist das nur in der 
main.c bekannt, dort aber auch in allen nach der Definition inkludierten 
header-files.

Alexander R. schrieb:
> Wenn ich nun in meiner Hauptdatei (nennen wir sie mal main.cpp) den Wert
> für die Konstante F_CPU definiere und den Header von meiner Klasse
> inkludiere, bekomme ich die im Betreff enthaltene Fehlermeldung.

Wenn du main.c kompilierst, kommt keine Fehlermeldung. Die kommt erst 
bei uart.cpp

Oliver

Alexander R. schrieb:

> Das "Problem" liegt glaube ich am Compiler, so scheint er einfach zu
> arbeiten.

Warnings lesen und beachten?

Udo Schmitt schrieb:
> Leute ihr habt doch keine 2000 C Dateien und alte Pentium 400 Rechner,
> daß das ne halbe Stunde dauert, das geht doch innerhalb des Bruchteils
> einer Sekunde, so what...

Nun ja, nur weil man mit make etc. nicht umgehen kann, muß man seine 
Unkenntnis nicht als generell richtig erklären. Immer alles neu 
kompilieren ist nicht nötig.

Ein kleines, einigermassen reales Projekt mit vielleicht 20-30 
Sourcedateien, kompiliert unterm avr-gcc mehrere Minuten. Das muß man 
sich nicht antun, wenn es auch anders geht.

Oliver

Alexander R. schrieb:
> Udo Schmitt schrieb:
>> Wenn der Code von solchen externen defines abhängt, ist es weise, die C
>> Datei im Projekt immer neu zu compilieren.
>
> Könntest du das näher erklären?
>
> Ich suche keinen Workaround, ich möchte schon wissen wie es korrekt
> gemacht werden sollte.

'korrekt' ist immer so eine Sache :-)


Die beste Lösung ist es, solche Dinge wie F_CPU in den 
Projekteinstellungen zu definieren. Denn diese Projekteinstellungen 
werden dem Compiler immer mitgegeben, wenn er ein C-File compiliert.

Der Nachteil davon ist allerdings, dass man die Projekteinstellungen als 
Teil des 'Source-Codes' ansehen muss. Denn wenn man sich nur die C-Files 
bzw. Header-Files ansieht, dann findet man da ja nicht raus, welcher 
Wert für F_CPU vorgesehen war.
Normalerweise ist das ja auch kein Problem. Es wird nur dann zum 
Problem, wenn man das Entwicklungssystem wechselt. Denn die 
C-Files/H-Files kann man, weil reine Text-Dateien, einfach direkt in die 
neue Entwicklungsumgebung übernehmen. Aber die Projekteinstellungen kann 
man normalerweise nicht so einfach übernehmen.

> Und ja, mir ist bewusst das der Präprozessor nur Text einfügt.

Was dir scheinbar noch fehlt, ist die Erkentnis, dass JEDES C-File für 
sich alleine compiliert wird.

Wenn der Compiler main.c compiliert, dann kennt er nur die Dinge, die in 
main.c geschehen. Plus natürlich die Dinge, die über die 
Projekteinstellungen dem Compiler beim Aufruf mitgegeben werden

Wenn der Compiler uart.c compiliert, dann kennt er nur die Dinge, die in 
uart.c geschehen. Plus natürlich ....


Jedes C-File wird für sich alleine compiliert und wenn der Compiler ein 
anderes C-File compiliert, dann fängt alles wieder bei 0 an.

C kennt keine 'Projekte', so wie das zb in C# der Fall ist, wo der 
Compiler darauf darauf angewiesen ist, quer über alle Source Code Files 
Querverbindungen herzustellen. In diesem Sinne ist C minimalistisch. Ein 
File - ein Compileraufruf - ein Ergebnis. Und erst wenn alle Einzelteile 
cmopiliert sind kommt dann der Linker und baut aus den vorübersetzten 
Einzelteilen das Komplettprogramm zusammen.

Oliver S. schrieb:
> Nun ja, nur weil man mit make etc. nicht umgehen kann, muß man seine
> Unkenntnis nicht als generell richtig erklären. Immer alles neu
> kompilieren ist nicht nötig.

Ist es nicht, aber um 3 Sekunden (oder 0,3?) zu sparen sich mit Make ins 
Knie zu schießen und evt. stundenlang Fehler zu suchen ist auch nicht 
schlauer.
Und man kann sich mit Abhängigkeiten oder nicht angegeben Abhängigkeiten 
wunderbar ins Knie schießen.

Oliver S. schrieb:
> Das muß man
> sich nicht antun, wenn es auch anders geht.

Die Frage ist obs anders geht, wenn er eine lib dazulinkt, die abhängig 
von einem define ist, das je Prozessor oder gar individuellem Projekt 
(F_CPU) unterschiedlich ist.

Oliver S. schrieb:
> Ein kleines, einigermassen reales Projekt mit vielleicht 20-30
> Sourcedateien, kompiliert unterm avr-gcc mehrere Minuten.
Ist das wirklich bei einem modernen Rechner so lahm?

Alexander R. schrieb:
> Ich suche keinen Workaround, ich möchte schon wissen wie es korrekt
> gemacht werden sollte.

jedes C File das von defines abhängt, die je nach Projekt 
unterschiedlich sein können, musst du zwingend neu compilieren, sonst 
ist dein Programm inkonsistent. Ob du das 'schlau' über make und 
Abhängigkeiten machst oder 'dumm' mit "build all" ist erst mal egal.
Globale Defines würde ich wie beschrieben über eine gemeinsame 
Compileroption machen, die für alle compiles benutzt wird. (Batch 
script, make, wie auch immer)

Udo Schmitt schrieb:
> Ist das wirklich bei einem modernen Rechner so lahm?

Ist es.

make etc. gibt es nun seit Anbegin der Zeitrechnung, heutzutage sogar 
versteckt hinter der IDE. Das funktioniert.

Oliver

Oliver S. schrieb:

> make etc. gibt es nun seit Anbegin der Zeitrechnung, heutzutage sogar
> versteckt hinter der IDE. Das funktioniert.

Und es gibt auch Tools, die die Abhängigkeiten selber bestimmen. 
Funktionieren ebenfalls.


Und Hand aufs Herz: Wenn man den Make-Mechanismus einmal durchschaut 
hat, ist er nicht schwer zu benutzen. Auch für ganz andere Dinge, als 
den C-Compiler anzuwerfen :-)


(Wer je in der Steinzeit mit PLINK ein Exe zusammenbauen musste, bei dem 
die Funktionen in Overlays sich denselben Speicher teilen mussten, der 
kann über das Thema Make oder Nicht Make nur müde lächeln. Da bist du 
tatsächlich Stunden bzw. Tage dabei gesessen und hast mit Memory Maps 
die Overlays ausgetüftelt, welche Funktion in welchem Segment sein muss, 
damit sie a) aufrufbar ist und b) nicht zuviele Page Swaps passieren)

Karl Heinz Buchegger schrieb:
> nd es gibt auch Tools, die die Abhängigkeiten selber bestimmen.
> Funktionieren ebenfalls.
>
>
> Und Hand aufs Herz: Wenn man den Make-Mechanismus einmal durchschaut
> hat, ist er nicht schwer zu benutzen.

Und ich kenne den häufigsten Tipp von Kollegen wenn seltsames passiert:
"Mach mal ein komplettes Rebuild"

Wenn das make hinter einer funktionierenden IDE versteckt ist die sauber 
alle Abhängkeiten aktuell anpasst dann ja. Wenn das aber eine mehr oder 
weniger 'manuelle' toolchain ist wo man handisch im make rumeditiert, 
dann sit ganz schnell ein neues h File bei den Abhängigkeiten vergessen.
Und wie gesagt, wenn ein komplettbuild nur ein paar Sekunden dauert, 
wofür?

Das ist dann genauso wenig sinnvoll wie wenn jemand versucht im Code ein 
paar µs Zeit zu sparen, und der Code dann für Benutzerinteraktion ist wo 
sich der Prozessor zu 99,99% langweilt.

Meine Erfahrung mit großen C Projekten (PC über 1000 Sourcen und H 
Files), allerdings schon Jahre her.

Udo Schmitt schrieb:
> Und wie gesagt, wenn ein komplettbuild nur ein paar Sekunden dauert,
> wofür?

Weil kein reales Projekt, das über ein Anfänger-"Hello world" 
hinausgeht, in ein paar Sekunden vollständig kompiliert.

Alexander R. schrieb:
> Das mit den Projekteinstellungen ist ein guter Punkt, da ich nicht
> gewährleisten kann, dass jemand die gleiche IDE benutzt.

Ok, das ist ein Grund, die IDE-Projekteinstellungen nicht zu nutzen. In 
dem Fall empfiehtl sich z.B eine header-Datei "global_defines.h" (oder 
so), in der solche globalen Dinge definiert werden, und die du dann in 
jedes header-File deines Projektes inkludierst.

Oliver

Oliver S. schrieb:
> Weil kein reales Projekt, das über ein Anfänger-"Hello world"
> hinausgeht, in ein paar Sekunden vollständig kompiliert.
Unser Großprojekt in der Firma bestand aus über 400 Sourcefiles, zum 
Teil bis über 200K groß, etwa 200 h files und compilierte KOMPLETT auf 
einem 400 MHz PC (>10 Jahre her) in etwa 40 min, mit einem 1600+ AMD 
Prozessor des nächsten Rechners dann etwa 10-15 min.
Jetzt erzählst du mir ein µC Projekt mit ein paar kByte Code braucht euf 
einem 3 GHz Rechner mehrere Minuten.
War jetzt der alte Microsoft Compiler so genial gut, oder sind die 
Compiler für den AVR so scheiße???? Ich kanns nicht ganz glauben, muss 
es wohl aber.

Ich programmiere hier praktisch ausschlisslich Java, und mit einem Core 
I7 Rechner dauert das complette rebuild von Projekten mit um die 100 
Sourcen auch nur < 1Minute, ein Ant komplettbuild mit Tests und Build 
von War Files (zum teil sogar umpacken includierter jars und Wars )im 
Bereich von 1 - 4 Minuten.

Alexander R. schrieb:
> Karl Heinz Buchegger schrieb:
>> Die beste Lösung ist es, solche Dinge wie F_CPU in den
>> Projekteinstellungen zu definieren. Denn diese Projekteinstellungen
>> werden dem Compiler immer mitgegeben, wenn er ein C-File compiliert.
>
> Im Atmel Studio 6 habe ich noch keine Option für die Frequenz gefunden.
> Ist der Eintrag im -D Parameter das Gleiche?

Ja, ist dasselbe.
Im alten AVR-Studio gabs dafür ein eigenes Edit-Feld, aber letzten Endes 
mündete das auch in einem -DFCPU=.... welches dem Compiler mitgegeben 
wird.

Alexander R. schrieb:

> Um also alle nötigen Informationen im Quelltext mitzuliefern, scheine
> ich nicht drum herum zu kommen, das F_CPU in der Header-Datei der Klasse
> zu definieren.

Das wiederrum ist keine so gute Idee.
Da ist es noch besser, ein globales Header-File zu machen, das 
zwingsweise von jedem includiert werden muss. Und wenn der include 
vergessen wurde, dann beschwert sich der Compiler, dass er F_CPU nicht 
kennt.

Was du erreichen willst: Egel wieviele C-Files du im Projekt hast, du 
willst nur an einer einzigen Stelle die Definition von F_CPU physisch 
haben. Denn nur so ist 100% gewährleistet, dass tatsächlich alle C-Files 
mit demselben Zahlenwert arbeiten. Hast du im Projekt mehrere 
Definitionen verstreut, besteht immer die Gefahr, dass diese nicht 
zusammenstimmen. Und dagegen kann dich ausser dir selber (und deinem 
Gedächtnis) niemand schützen. Das mag dir heute noch nicht als Prpblem 
erscheienen, aber wenn du in 2 Jahren das Projekt noch mal vorkramst um 
es auf eine andere Schaltung mit anderer Taktfrequenz umzustellen, 
darfst du dann nicht vergessen ALLE F_CPU Definitionen anzupassen. Und 
wie das halt so ist ... als Mensch macht man Fehler und vergisst bzw. 
übersieht Dinge gern.

Genau aus dem Grund bin ich auch kein Freund der Methode ....

1

#ifndef F_CPU

2

#define F_CPU 1000000UL

3

#endif

..., meinetwegen noch mit einer Warnung garniert (die eh keiner liest). 
Wenn F_CPU fehlt, dann sollte man das IMHO ruhig mit einem Error 
quittieren und keine Standardannahmen treffen, die dann ohnehin nicht 
stimmen und in Fehlersuche ausarten.

Udo Schmitt schrieb:
> Oliver S. schrieb:
>> Weil kein reales Projekt, das über ein Anfänger-"Hello world"
>> hinausgeht, in ein paar Sekunden vollständig kompiliert.
> Unser Großprojekt in der Firma bestand aus über 400 Sourcefiles, zum
> Teil bis über 200K groß, etwa 200 h files und compilierte KOMPLETT auf
> einem 400 MHz PC (>10 Jahre her) in etwa 40 min, mit einem 1600+ AMD
> Prozessor des nächsten Rechners dann etwa 10-15 min.

Das Projekt, an dem ich zur Zeit bin, compiliert des Nachts auf einem 
eigenen Compile-Server komplett durch. Dauer: ungefähr von halb 1 Uhr 
morgens bis knapp nach 5. Wir haben extra eine Mehrkern-Maschine dafür 
abgestellt, denn ein einziger Kern hat es in einer Nacht alleine nicht 
mehr geschafft :-)

(Ist aber kein AVR-Projekt - sollte aber klar sein :-)

Karl Heinz Buchegger schrieb:
> Das Projekt, an dem ich zur Zeit bin, compiliert des Nachts auf einem
> eigenen Compile-Server komplett durch. Dauer: ungefähr von 2 Uhr morgens
> bis knapp nach 5

Glaube ich dir gerne :-) Wenn ich alle Compiles für alle 
Betriebssysteme, Rechner und Datenbanken dazunehme, komme ich bei uns 
auch auf Zeiten > 8h pro Nacht (Ohne Tests).

Ich wollte damit nur deutlich machen, daß ich es kaum glauben kann daß 
es bei modernen Rechnern lohnt für 8Bit µCs keine Komplett Builds laufen 
zu lassen.
Speziell Anfänger, die das halt nur hobbymäßig betreiben können mit nur 
halb verstandenen make skripten in wunderbare Fallen laufen.

Udo Schmitt schrieb:

> Ich wollte damit nur deutlich machen, daß ich es kaum glauben kann daß
> es bei modernen Rechnern lohnt für 8Bit µCs keine Komplett Builds laufen
> zu lassen.

Ne ne, das passt schon.

2 Punkte:
* zum einen, meine Meinung, sollte man sich schon an gewisse Standards
  halten. Hilft nichts - in der Programmierung muss man eben vieles
  lernen.
* zum anderen hilft dir ein Make All auch dann nicht, wenn du mehrere
  sich widersprechende F_CPU im System hast. Und das ist für mich
  eigentlich einer der wichtigeren Punkte in diesem Thread.
  Ob ein Make All jetzt 20 oder 30 Sekunden dauert (weil die Ausgabe
  der Fehlermeldungen so langsam ist) ist hingegen zweitrangig.

xfr schrieb:
> Ob
> derjenige das dann in seinen Projektoptionen macht oder lieber ein
> #include config.h im Code ergänzt, sei ihm überlassen.

Es sollte allerdings an einer Stelle sein, an der man es schnell findet. 
Da ist mir ein globales headerfile mit aussagekräftigem Namen lieber, 
als eine Definition im makefile. Denn auch make ist nicht gleich make. 
Wer das Projekt lieber in einer IDE mit automatisch erzeugten makefile 
nutzen will, muß sich mühsam die defines aus dem makefile suchen. Mit 
einem header funktioniert das immer und überall.

Oliver