-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

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

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    14.07.2004
    Beiträge
    23

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

    Anzeige

    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

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.05.2005
    Ort
    Issum
    Alter
    45
    Beiträge
    2.236
    Hallo,
    vielleicht so
    Code:
    SRC = $(TARGET).c  libs/lcd_lib.c
    ?

    Hab es aber nicht probiert.

    Gruß Sebastian
    Software is like s e x: its better when its free.
    Linus Torvald

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    14.07.2004
    Beiträge
    23
    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

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    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.
    Disclaimer: none. Sue me.

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    14.07.2004
    Beiträge
    23
    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

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Disclaimer: none. Sue me.

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    14.07.2004
    Beiträge
    23
    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

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    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...
    Disclaimer: none. Sue me.

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    14.07.2004
    Beiträge
    23
    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
    Angehängte Dateien Angehängte Dateien

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Für asm-Ausgabe guckst du
    http://www.roboternetz.de/wissen/ind...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.
    Disclaimer: none. Sue me.

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •