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

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

Code:

#include "libs/lcd_lib.h"

eingefügt und im Makefile ein

Code:

SRC = $(TARGET).c lcd_lib.c

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

Code:

> "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

Hallo,
vielleicht so

Code:

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

?

Hab es aber nicht probiert.

Gruß Sebastian

Hi,

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

Code:

> "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

Code:

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.

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:

Code:

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

Vielleicht dort:

http://www.gnu.org/software/make/man...ode/index.html

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

Code:

VPATH = %.c libs

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

Code:

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

gefunden. Funktioniert ebenfalls prächtig.
Was macht das

Code:

.;

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

Zitat:

Zitat von Hans Meier

t ebenfalls prächtig.
Was macht das

Code:

.;

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...

Liste der Anhänge anzeigen (Anzahl: 1)

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

Für asm-Ausgabe guckst du
https://www.roboternetz.de/wissen/in...en_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.

Code:

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.

Code:

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.

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

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.