AVR-GCC: *.C und *.H aus Unterverzeichnis einbinden

[Hans Meier]

Hallo,

habe eine Frage zu WinAVR, bzw. Programmers Notepad und dessen Umgang mit Unterverzeichnissen beim kompilieren.
Habe mir eine LCD Library (von euch) heruntergeladen und möchte die mal testweise ausprobieren. Habe erst ein neues Projekt begonnen, LCD angeschlossen: haut hin => für gut befunden :=)
Nun habe ich einfach das Unterverzeichnis in mein "richtiges" Projekt kopiert und würde darin gerne das Unterverzeichnis (libs) mit den Dateien lcd_lib.c und lcd_lib.h einbinden. Dazu habe ich in meine main.c am Anfang ein


#include "libs/lcd_lib.h"

eingefügt und im Makefile ein


SRC = $(TARGET).c lcd_lib.c


Komischerweise greift er aber gar nicht auf die lcd_lib.c zu:


> "make.exe" all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: Testboard.c
avr-gcc -c -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=7372800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -Wa,-adhlns=/Testboard.lst -std=gnu99 -Wundef -MD -MP -MF .dep/Testboard.o.d Testboard.c -o /Testboard.o

Linking: Testboard.elf
avr-gcc -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=7372800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -Wa,-adhlns=/Testboard.o -std=gnu99 -Wundef -MD -MP -MF .dep/Testboard.elf.d /Testboard.o /pflib_lcd.o --output Testboard.elf -Wl,-Map=Testboard.map,--cref -lm

Creating load file for Flash: Testboard.hex
avr-objcopy -O ihex -R .eeprom Testboard.elf Testboard.hex

Creating load file for EEPROM: Testboard.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex Testboard.elf Testboard.eep

Creating Extended Listing: Testboard.lss
avr-objdump -h -S Testboard.elf > Testboard.lss

Creating Symbol Table: Testboard.sym
avr-nm -n Testboard.elf > Testboard.sym

Size after:
Testboard.elf :
section size addr
.text 1030 0
.data 42 8388704
.bss 0 8388746
.noinit 0 8388746
.eeprom 0 8454144
.stab 876 0
.stabstr 132 0
.debug_aranges 40 0
.debug_pubnames 210 0
.debug_info 1480 0
.debug_abbrev 728 0
.debug_line 1332 0
.debug_str 454 0
.debug_ranges 12 1030
Total 6336




Flash SRAM EEPROM
----- ---- ------
17% 4% 0%

-------- end --------


> Process Exit Code: 0
> Time Taken: 00:02


Wie kann ich im Makefile/in der main.c also dem AVR-GCC klar machen, das er gewisse Dinge aus "meinen" Unterverzeichnis libs holen soll? Was für Änderungen sind notwendig und wo?

Gruß,

Hans

[izaseba]

Hallo,
vielleicht so

SRC = $(TARGET).c libs/lcd_lib.c

?

Hab es aber nicht probiert.

Gruß Sebastian

[Hans Meier]

Hi,

wenn ich den SRC Eintrag im Makefile wie vorgeschlagen anpasse, erhalte ich folgende Fehlermeldung:


> "make.exe" all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Size before:
Testboard.elf :
section size addr
.text 1030 0
.data 42 8388704
.bss 0 8388746
.noinit 0 8388746
.eeprom 0 8454144
.stab 876 0
.stabstr 132 0
.debug_aranges 40 0
.debug_pubnames 210 0
.debug_info 1480 0
.debug_abbrev 728 0
.debug_line 1332 0
.debug_str 454 0
.debug_ranges 12 1030
Total 6336




Compiling C: libs/lcd_lib.c
avr-gcc -c -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=7372800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -Wa,-adhlns=/libs/lcd_lib.lst -std=gnu99 -Wundef -MD -MP -MF .dep/lcd_lib.o.d libs/lcd_lib.c -o /libs/lcd_lib.o
Assembler messages:
FATAL: can't create /libs/lcd_lib.o: No such file or directory
make.exe: *** [/libs/lcd_lib.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:02


Das Problem scheint zu sein, dass ab und an dem Pfad ein / vorausgestellt wird. Manchmal steht dort korrekterweise libs/lcd_lib.c, an anderer Stelle setzt der Compiler dann aber /libs/lcd_lib.lst bzw. /libs/lcd_lib.o ein.

weitere Hilfe?

Hans

[SprinterSB]

VPATH %.c .;./libs
SRC = $(TARGET).c lcd_lib.c

BTW: Warum verbiegst du die C-Semantik? Passt das zu den Quellen?
Evtl ist es besser ne eigene Regel für das Zeug zu schreiben. Den / erzeugst du wohl mit einem replacer.

[Hans Meier]

Hallo,

ein VPATH %.c .;./libs brachte nicht den gewünschten Erfolg, ein VPATH = %.c .;./libs aber sehr wohl ;=)
Super! Bin vollstens zufrieden. Hätte da nur eine Anmerkung: beim Compilieren wird mir jetzt für die lcd_lib der komplette Assemblercode im Outputfenster angezeigt. Außerdem kommt noch eine Warning/Message:


H:\Temp/cc2Taaaa.s: Assembler messages:
H:\Temp/cc2Taaaa.s:2775: can't open list file: /./libs/lcd_lib.lst: No such file or directory

Da ich unter Google keine genaue Erklärung gefunden habe: was bewirkt dieser VPATH? Gibt es irgendwo eine Erklärung (aller?) der Optionen im Makefile (VPATH hatte ich z.B. vorher gar nicht drin)?

Was meinst du mit Warum verbiegst du die C-Semantik? Passt das zu den Quellen?
Habe ein paar eigene allgemeingültige Funktionen für ein LCD (und andere) und wollte die nun so ähnlich wie <avr/io.h> o.ä. am Anfang einbinden. Habe aber wenig Lust die einzelnen Dateien immer zu kopieren. So habe ich in meinem Verzeichnis die libs im Unterverzeichnis und kann in Ruhe "mein" Projekt machen.
Was den / zuviel angeht: habe ein/das fertige Template von mfile übernommen und um avr_sizex (wie im Tutorila vorgeschlagen), Taktfrequenz und Baudrate für den Programmer erweitert.
Sollt eich ein anderes/besseres Template verwenden? Wie macht man es richtig? Wie "verwaltet" man seine Projekte, bzw. schafft da ein wenig Ordnung?

Björn

[SprinterSB]

Vielleicht dort:

http://www.gnu.org/software/make/manual/html_node/index.html

[Hans Meier]

Hi,

gilt das auch für das make das bei WinAVR dabei ist?
Wie auch immer: nachdem ich das (teilweise) durchgelesen habe, hätte ich


VPATH = %.c libs

geschrieben. Testweise mal eingesetzt und ausprobiert: läuft ebenfalls durch. In der angegebenen Doku habe ich noch


VPATH = %.c SUB1:SUB2
sucht in ./SUB1/ and ./SUB2/

gefunden. Funktioniert ebenfalls prächtig.
Was macht das


.;

denn darin? das Semikolon trennt doch die "Regel" suche *.c Dateien ebenfalls im Verzeichnis ./libs auf (meiner Meinung nach)? Dazu habe ich nichts weiter gefunden.

Hast du evtl. noch einen Tipp warum mir für alle Dateien die ich aus libs einbinde der ASM Code ausgegeben wird, für die Dateien aus dem "root" aber nicht?

Björn

[SprinterSB]

t ebenfalls prächtig.
Was macht das
.; denn darin?

Hast du evtl. noch einen Tipp warum mir für alle Dateien die ich aus libs einbinde der ASM Code ausgegeben wird, für die Dateien aus dem "root" aber nicht?

Björn

Der . ist der momentane Pfad.

Zum ASM: Ich kenne dein Makefile nicht. Die automatisch generierten Makefile-Monster funktionieren für kleine Projekte. Sobald es was komplizierter wird, sind sie überfordert und die ausgespuckten Makefiles will man sich auch nicht wirklich anschauen...

[Hans Meier]

Hallo,

danke für deine ständigen Antworten und Geduld mit mir :=)
Das Problem mit den Makefiles ist, dass ich damit vorher noch nie "wirklich" gearbeitet habe, d.h. die ganzen netten Optionen nicht kenne. Insofern habe ich halt das automatisch generierte von mfile genutzt und das angepasst. Von der PC Programmierung bin ich es gewohnt ein wenig Ordnung zu halten, insofern würde ich halt gerne alles ein wenig sortieren.
Wie baut ihr die Makefiles auf? Komplett von Hand? Fertiges Template/Vorlage ein wenig ändern/erweitern/anpassen?
Ansonsten: wodurch wird eine ASM Ausgabe erzeugt? Wenn du Vorlagen von einem (recht) universellen Makefile hast, würde ich mich freuen (ja ich weiß, es muss immer angepasst werden). Anbei noch mal mein Makefile (.txt nur fürs Forum).

Björn

[SprinterSB]

Für asm-Ausgabe guckst du
https://www.roboternetz.de/wissen/index.php/Assembler-Dump_erstellen_mit_avr-gcc

Ich finde make ist was für Leute, die ihre Schwiegermutter gemeuchelt haben ;-) Ich benutz es zwar auch, aber je universeller Makefiles sind, desto schwerer sind sie auch zu verstehen/anzupassen und erst recht zu debuggen.

Meine sind ganz simpel gehalten. Was ich da nich brauche hab ich rausgeworfen. Ursprünlich sind die aus den Beispielen, die WinAVR mitbringt.


PRG = main
SRC = time.c $(PRG).c timer1.c dcf.c fifo.c uart.c uput.c rc5.c
OBJ = $(SRC:.c=.o)

MCU_TARGET = atmega8
#MCU_TARGET = at90s2313
OPTIMIZE = -Os

RESET_SCRIPT = /d/avr/bin/reset.sh
BURN_SCRIPT = /d/avr/bin/burn-prog.sh
INCLUDES =

DEFS = -DF_CPU=10000000 -DDCF_DEBUG \
-DUART_OUTFIFO
LIBS =

# You should not have to change anything below here.

CC = avr-gcc

.PHONY: all clean size burn lst hex eeprom depend reset

# Override is only needed by avr-lib build system.

CFLAGS = -mmcu=$(MCU_TARGET) -Wall $(OPTIMIZE) -Winline -fno-keep-inline-functions $(DEFS) $(INCLUDES) -fno-common
LDFLAGS = -mmcu=$(MCU_TARGET) -Wl,-Map,$(PRG).map -Wl,-section-start=.eeprom=0x810001
ASMFLAGS = -dp -save-temps -fverbose-asm
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump

all: depend $(PRG).elf lst hex eeprom

fsize:
avr-nm --size-sort -S $(PRG).elf

depend:
$(CC) -MM $(SRC) -mmcu=$(MCU_TARGET) $(DEFS) $(INCLUDES) > .depend

size: #$(PRG).elf $(OBJ)
avr-size -x $(OBJ)
avr-size -C --mcu=$(MCU_TARGET) $(PRG).elf |grep -E '^(Data)|(Pro)|(AVR)'

$(PRG).elf: $(OBJ)
$(CC) $(LDFLAGS) -o $@ $^ $(LIBS)

-include .depend

%.o: %.c Makefile
$(CC) $(CFLAGS) $< -S $(ASMFLAGS)
$(CC) $(CFLAGS) $< -c -o $@

clean:
rm -rf *.o $(PRG).elf *.bak *.s *.i *.c.*
rm -rf *.lst *.map
rm -f .depend

lst: $(PRG).lst

reset:
sh $(RESET_SCRIPT) $(MCU_TARGET)

burn:
sh $(BURN_SCRIPT) $(PRG).hex $(MCU_TARGET)

%.lst: %.elf
$(OBJDUMP) -h -S -j .data -j .eeprom -j .text $< > $@

# Rules for building the .text rom images

hex: $(PRG).hex

%.hex: %.elf
$(OBJCOPY) -j .text -j .data -O ihex $< $@

# Rules for building the .eeprom rom images

eeprom: $(PRG)_eeprom.hex

%_eeprom.hex: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@


Da es sich um 8-Bit-µC handelt sind die Projekte alle kleine und überschauber (im ggs zu Host-Projekten).

Von der Organsation würde man nicht das LCD Zeug unter das Projektverzeichnis legen, sondern besser auf gleiche Ebene. Auch würde man nicht aus dem Projekt Makefie heraus generieren, sondern LCD hätte ein eigenes Makefile, das aus dem PRJ Makefile angestossen wird.

cd ../xxx && make

Evtl ist besser, eine Lib zu erzeugen und im PRJ nur noch gegen diese Lib zu linken. Das schliesst aber bestimmte Optimierungen/Anpassungen aus. Das LCD Zeug ist ja keine Lib (auch keine Lib-Quelle), sondern ein Quellpaket.

[Hans Meier]

Hallo,

die Assemblerausgabe habe ich nun (komplett) abgestellt.
Was ich bis heute aber nicht herausgefunden habe: warum die Assemblersachen bei Dateien aus Unterverzeichnissen ausgegeben wurden, bei C-Dateien aus dem Hauptverzeichnis aber nicht.
Was ein gutes Makefile angeht: am liebsten würde ich "einmal" ein (für meine Anforderungen) universelles Makefile basteln, um anschließend den ganzen Krempel wieder vergessen zu können...

Gruß,

Björn

[SprinterSB]

Na am Bastelt hindert sich ja niemand... Den Link zu make findest du oben. Beispiel Makefiles findest du auch viele im Netz, und zum lernen sind handgeschriebene Makefiles besser als die von den Gegeratoren erzeugten (find ich).

Das Problem liegt wohl in irgendeinem patsubst oder impliziten Regel oder nich abgefangenem Fall im Generator. Ich auch würd lieber versuchen was eigenes zu machen (klein aber fein, auch wenn's nur ein Wollmilchferkel ist) als den Output von mfile nachzupinseln.