Verständnisproblem #if bei avr-gcc

[Jürgen S. (jsachs)]

Hallo,

ich versuche zur Compile ZEit code für mehrere CPUs fest zu legen.

z.B.

#if MCU == atmega328p
    UDR0 = c;
#elif MCU == atmega1284p
    UDR0 = c;
#elif MCU == atmega32
    UDR = c;
#endif

Also nichts besonderes.

Ist MCU = atmega32 greift aber bereits #if MCU == atmega328p

Mache ich hier was falsch ?
So hatte ich das zumindest laut Anleitung verstanden.
Bisher hatte ich für jede CPU ein "#define _CPU2_" und dann nur noch

#if _CPU1_
    UDR0 = c;
#elif _CPU2_
    UDR0 = c;
#elif _CPU3_
    UDR = c;
#endif

Aber das ist ja nicht so toll...

Eventuell kann mir einer ja kurz die Erleuchtung geben.

Danke
Juergen

[Tom W. (nericoh)]

müsste das erste #if nicht eher ein #ifdef sein?

edit: ne sry, das war Quatsch...

[g457 (Gast)]

> Ist MCU = atmega32 greift aber bereits #if MCU == atmega328p

Dann haben die Defines atmega32 und atmega328p den selben Wert. Zeig mal 
jene Defines her.

[Tom W. (nericoh)]

würde da auch Klammern setzen: #if (MCU == ...)

bin nicht sicher, ob der Präprozessor sonst nicht schon das #if MCU als 
wahr interpretiert (wenn MCU ungleich 0 ist)

[JSachs (Gast)]

Die defines sollten passen, werden ja von gcc als cpu Auswahl genutzt.
Also
MCU=atmega32

Gruß
Juergen

[g457 (Gast)]

> Die defines sollten passen

Das glaube ich nicht. Schau Dir mal die Defines

__AVR_ATmega328P__

 und co an.

[Wilhelm M. (wimalopaan)]

Der cpp kann keine(!) Stringvergleiche. Er kann nur numerisches.

[Wilhelm M. (wimalopaan)]

Zur Info:


http://en.cppreference.com/w/cpp/preprocessor/conditional

[Jörg W. (dl8dtl) (Moderator)]

Jürgen S. schrieb:

> z.B.#if MCU == atmega328p
>     UDR0 = c;
> #elif MCU == atmega1284p
>     UDR0 = c;
> #elif MCU == atmega32
>     UDR = c;
> #endif

Schreib' das mal so um:

#if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega1284P__)
     UDR0 = c;
#elif defined(__AVR_ATmega32__)
     UDR = c;
#else
#   error Unhandled MCU type
#endif

Dann kommst du komplett mit der durch den AVR-GCC bereits vorgegebenen
Infrastruktur aus und musst dir keine eigenen #defines erst erfinden.

[JSachs (Gast)]

Danke, probiere ich sobald ich daheim bin.

Den define für die MCU brauche ich trotzdem fur den cpu Typ.

Oder habe ich da was übersehen?

Gruß
Juergen

[Jörg W. (dl8dtl) (Moderator)]

JSachs schrieb:
> Den define für die MCU brauche ich trotzdem fur den cpu Typ.

Nein, die Makros wie

__AVR_ATmega1284P__

etc. erzeugt der AVR-GCC intern selbst aus der übergebenen Option
-mmcu=atmega1284p.

[Rainer B. (katastrophenheinz)]

... und in der UART-Lib von P. Fleury gibt's das Ganze schon fertig 
aufgebaut und getestet:

http://homepage.hispeed.ch/peterfleury/uartlibrary.zip

Und wenn du den Quellcode nur dafür hernimmst, um zu gucken, wie man 
sinnvoll mit dem #define für den Prozessortyp umgeht.

Das #define für den AVR-Typ legt der Preprozessor für dich an, je 
nachdem welches Target du mit der gcc-Kommadozeilenoption -mmcu=... oder 
per Setting in deiner IDE auswählst ( was letztendlich auch auf die 
Kommandozeilenoption hinausläuft).

[Jürgen S. (jsachs)]

Jörg W. schrieb:
> JSachs schrieb:
>> Den define für die MCU brauche ich trotzdem fur den cpu Typ.
>
> Nein, die Makros wie
>
>

__AVR_ATmega1284P__

>
> etc. erzeugt der AVR-GCC intern selbst aus der übergebenen Option
> -mmcu=atmega1284p.

So ganz habe ich das nicht verstanden.......
Wenn ich folgendes machen möchte

AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER)

Muss ich doch MCU definieren?
Wobei das ja für AVR_DUDE ist, nicht für gcc...
genauso habe ich das auch bei

# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -W -Wall -I. $(CFLAGS) $(GENDEPFLAGS) $(CDEFS) $(CSTANDARD) -ffunction-sections -O$(OPT) 
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)

genutzt..


Oder gibt es einen define, der das bereits beinhaltet.
Wenn ich der Datei avr/io.h folge, kann ich da nichts entdecken, mit den 
jeweiligen includes natürlich.

Der Umbau auf:

#if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega1284P__)
     UDR0 = c;
#elif defined(__AVR_ATmega32__)
     UDR = c;
#else
#   error Unhandled MCU type
#endif

hat erst mal den Erfolg gebracht, trotzdem würde ich das noch weiter 
Optimieren wollen.
Nur so als Hinweis, es geht nicht nur UART, auch Interrupts un Co.
Trotzdem Danke für den Hinweis auf die UART Library.

Etwas Offtopic...
Kann mir einer sagen, wie ich bei einer Änderung einer bestimmten Datei 
einen "make clean" als erstes ausführen kann ?
Ein (Ausschnitt aus meinem Makefile)

build: $(GLOBAL_SRC_DIR/typeToBuild.makefile) elf hex bin eep lss sym size copyHttp finish

$(GLOBAL_SRC_DIR/typeToBuild.makefile):
  echo "type to Build changed, clean up project first"
  clean

brachte leider keinen Erfolg.

Gruss
Juergen

[Jörg W. (dl8dtl) (Moderator)]

Jürgen S. schrieb:

> Muss ich doch MCU definieren?

Ja, an einer Stelle schon.  Aber diese Variable namens MCU ist nur
innerhalb des Makefiles bekannt.  Von da wird er als -mmcu= an den
Compiler weitergereicht, und dieser wiederum baut sich intern dann
die Makros mit den Unterstrichen draus.

> Kann mir einer sagen, wie ich bei einer Änderung einer bestimmten Datei
> einen "make clean" als erstes ausführen kann ?
> Ein (Ausschnitt aus meinem Makefile)

> build: $(GLOBAL_SRC_DIR/typeToBuild.makefile) elf hex bin eep lss sym
> size copyHttp finish
>
> $(GLOBAL_SRC_DIR/typeToBuild.makefile):
>   echo "type to Build changed, clean up project first"
>   clean

Probier' es mal mit einer Hilfsdatei, die von der anderen abhängt:

build: stamp elf hex bin eep lss sym size copyHttp finish

stamp: $(GLOBAL_SRC_DIR/typeToBuild.makefile)
        $(MAKE) clean
        touch stamp

[Johann L. (gjlayde)]

Jörg W. schrieb:
> Nein, die Makros wie
>
>

__AVR_ATmega1284P__

>
> etc. erzeugt der AVR-GCC intern selbst aus der übergebenen Option
> -mmcu=atmega1284p.

Inzwischen nicht mehr.  Während es sich bis avr-gcc v4.9 noch um 
Build-in Makros handelte und in entsprechenden Dumps daher steht

# 1 "<built-in>"
...
#define __AVR_ATmega1284P__ 1

ist das ab v5 nicht mehr so.  Die Macros werden qua specs File über die 
Kommandozeile definiert:
  

# 1 "<command-line>"
#define __AVR_ATmega1284P__ 1

 
Der entsprechende Eintrag aus specs-atmega1284p:
 

*cpp:
  -D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p

[Jürgen S. (jsachs)]

Jörg W. schrieb:
> Jürgen S. schrieb:
>
>> Muss ich doch MCU definieren?
>
> Ja, an einer Stelle schon.  Aber diese Variable namens MCU ist /nur/
> innerhalb des Makefiles bekannt.  Von da wird er als -mmcu= an den
> Compiler weitergereicht, und dieser wiederum baut sich intern dann
> die Makros mit den Unterstrichen draus.
Jetzt wo ich es lese...
Klar, MCU war nur im Makefile bekannt...

Gut, jetzt mit dem

#if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega1284P__)
     UDR0 = c;
#elif defined(__AVR_ATmega32__)
     UDR = c;
#else
#   error Unhandled MCU type
#endif

ist es eh besser.

Das mit dem
>

> build: stamp elf hex bin eep lss sym size copyHttp finish
> 
> stamp: $(GLOBAL_SRC_DIR/typeToBuild.makefile)
>         $(MAKE) clean
>         touch stamp
>

hat genau einmal Funktioniert, sieht bei mir so aus.

# Change the build target to build a HEX file
build: whatToBuildDummy elf hex bin eep lss sym size copyHttp finish

whatToBuildDummy: $(GLOBAL_SRC_DIR/typeToBuild.makefile)
  echo "type to Build changed, clean up project first"
  echo "if you get an error abaout missing dependency file, simply compile again"
  $(MAKE) clean
  touch "whatToBuildDummy"

Das stelle ich jedoch mal hinten an.

Gruss
Juergen

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
>> erzeugt der AVR-GCC intern selbst aus der übergebenen Option
>> -mmcu=atmega1284p.
>
> Inzwischen nicht mehr.

OK, das war mir jetzt nicht so ganz genau klar.

Anyway, das Interface aus Nutzersicht hat sich ja dadurch nicht
geändert: er kann sich drauf verlassen, dass sein -mmcu= einen
entsprechenden Makro automatisch generiert, und man muss sich nicht
die Mühe machen, etwas vergleichbares „zu Fuß“ nachzubilden.

[S. R. (svenska)]

Jürgen S. schrieb:
> Das mit dem
>>> build: stamp elf hex bin eep lss sym size copyHttp finish
>>
>> stamp: $(GLOBAL_SRC_DIR/typeToBuild.makefile)
>>         $(MAKE) clean
>>         touch stamp
>> hat genau einmal Funktioniert, sieht bei mir so aus.

Erstens:
Dein "make clean" muss das stamp-File auch löschen, sonst funktioniert 
das nur genau einmal. Du kannst aber statt auf ein Dummy-File auch auf 
"clean" verweisen lassen, und du solltest "clean" als ".PHONY" 
deklarieren. Außerdem macht dein Ansatz parallele Builds kaputt, weil 
"clean" an fremden Dateien rumspielt.

Zweitens:
Wenn du vor einem Build ein "make clean" brauchst, ist an deinem 
Buildsystem etwas kaputt. Erweitere dein Makefile mal lieber um 
richtiges Dependency Tracking (der gcc kann dir passende 
Makefile-Snippets erzeugen), dann funktioniert der Rebuild auch 
zuverlässig, wenn du einen Header änderst.

Beispiel (Auszugsweise):

OBJS = bla.o blub.o main.o

[...]

DEPS = $(OBJS:.o=.od)
.PHONY: all clean run
.PRECIOUS: $(OBJS) $(DEPS)

[...]

%.o: %.c
    $(CC) $(CFLAGS) -c -o $@ $<
    $(CC) $(CFLAGS) -MM -c $< > $@d

[...]

clean:
    rm -f $(MAIN) $(OBJS) $(DEPS)

-include $(DEPS)

Die beiden Compileraufrufe kann man sicherlich auch vereinigen, aber das 
habe ich bisher nicht gebraucht. Vermutlich geht's auch noch besser.

[Jörg W. (dl8dtl) (Moderator)]

S. R. schrieb:
> Wenn du vor einem Build ein "make clean" brauchst, ist an deinem
> Buildsystem etwas kaputt.

Naja, wenn man im Makefile (oder einem seiner Includes) irgendwelche
Parameter ändert, die das komplette Compilat beeinflussen, dann
bleibt einem eigentlich nicht viel anderes übrig, als vorher erstmal
alles zu löschen.

[S. R. (svenska)]

Ja gut, das ist klar. Aber dann macht man vorher einmal "make clean" per 
Hand und gut ist. Mein Reflex ist in solchen Fällen "make clean run", 
weswegen ich clean auch nicht in NOTPARALLEL stehen habe; mit der Race 
Condition kann ich leben,

Ich hatte den TO so verstanden, dass es um eine Datei geht, die im 
Makefile nicht explizit auftaucht, aber trotzdem gebraucht wird. Das ist 
dann ein Fehler im Buildsystem, und implizit "make clean" aufrufen 
lassen ist ein hässlicher Workaround, der zudem parallele Builds bricht.

Wenn man ständig an den Makefiles rumspielt, könnte man natürlich auch 
Includes bauen, die die einzelnen Makefile.inc-Dateien verfolgen, und im 
Zweifelsfall dann "make" neu aufrufen... ;-)

[JSachs (Gast)]

Genau das ist bei mir der Fall.

Dieses File definiert, was erzeugt wird.
Dadurch wird im Makefile Prozessor und Optionen definiert.
Außerdem werden durch das define bestimmt, was im Quellcode compiliert 
wird, eventuell die pin Konfiguration geändert usw.

Da hilft nur ein make Clean um sicher zu gehen.

Gruss
Juergen