logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[AVR][C] - zagadnienie deklaracji funkcji do kompilacji

mirekk36 09 Cze 2008 23:17 2610 11
  • #1 5230650
    mirekk36
    Poziom 42  
    Witam,

    może dziwny tytuł mojego pytania ale już mówię co chciałbym uzyskać a nie mogę:

    otóż mam już własne pliki z funkcjami do obsługi LCD:
    - lcd.h
    - lcd_hardware.h
    - lcd.c

    oczywiście do pliku głównego z funkcją main dodaję pliki nagłówkowe *.h a do pliku projektu lcd.c i wszystko ślicznie działa. Jednak widzę, że kompilują mi się funkcje zdefiniowane w pliku lcd.c, które nigdy nie są np używane!

    mam np funkcję lcd_cursor_on - jej ciało leży w lcd.c , a jej deklarację mam jeszcze w pliku lcd.h

    i teraz wyraźnie widzę, że gdy nie używam nigdzie funkcji lcd_cursor_on to kod wynikowy ma dokompilowaną pomimo to, tę funkcję. Dopiero ggdy ją zaremuję w lcd.c to kod generuje się mniejszy.

    chyba da radę jakoś za pomocą - nie wiem - extern czy jakoś ustawić to tak aby do kodu wynikowego kompilowały się tylko użyte w nim funkcje???

    używam tandemu AVRStudio oraz GCC

    pozdr
  • Pomocny post
    #5 5230792
    zumek
    Poziom 39  
    Jeżeli w tej "bibliotece" lcd.c masz niewiele funkcji , to możesz zastosować kompilację warunkową.
    Np.
    global.h
    
    //...
    #define  LCD_CURSOR_ON
    //...
    

    lcd.c
    
    #include "global.h"
    //...
    #ifdef LCD_CURSOR_ON
    
        void lcd_cursor_on()
        {
        }
    
    #endif
    

    Ot , prosty - żeby nie powiedzieć prostacki - sposób ;)

    Piotrek
  • Pomocny post
    #6 5230847
    shg
    Poziom 35  
    Biblioteki tak jak tu na przykład:
    https://www.elektroda.pl/rtvforum/topic952275.html

    W najnowszym WinAVR chyba jest zmieniony sposób tworzenia bibliotek (szablon makefile), ale to można w szablonie tym doczytać, a reszta tak samo.

    Po stworzeniu biblioteki należy ją oczywiście zlinkować z projektem, podejrzyj sobie w makefile, tak samo jak są tam zrobione biblioteki printf i math.
  • #8 5230936
    mirekk36
    Poziom 42  
    ... bardzo dziękuję za podpowiedzi. Teraz mi się rozjaśniło. Shg - dosyć dokładnie to opisał, ale też dzięki temu stwierdziłem, że na razie dam sobie spokój z tworzeniem bibliotek tym bardziej, że aby zrobić je uniwersalne dla różnych procków to trzeba by nieźle pokombinować w opcjach linkera , w samym makefile itp - więc temat odłożę na później

    w związku z tym bardzo pomocną okazała się oczywiście prosta ale skuteczna opcja (jak dla mnie w zupełności wystraczająca na ten czas), którą polecił Zumek(Piotrek) - dzięki. Coraz lepiej poznaję dyrektywy preprocesora dzięki takim uwagom.

    pozdrawiam
  • #9 5231242
    szelus
    Poziom 34  
    Chciałbym tylko uzupełnić, gdyby to nie było jasne, że aby z biblioteki linker dołączał tylko potrzebne funkcje, źródła biblioteki muszą być skonstruowane tak, jak napisał Balu - każda funkcja w oddzielnym pliku źródłowym.
  • #10 5231251
    mirekk36
    Poziom 42  
    selus -> tak oczywiście zgadzam się z tym co pisał Balu - tylko, że tu chodzi o generowanie biblioteki. A samo to, że trzeba je trzymać w oddzielnych plikach to tylko mały szczegół jeśli chodzi o temat generowania całych bibliotek i to jeszcze linkowanych dynamicznie.
  • #11 5231300
    fantom
    Poziom 31  
    mirekk36 napisał:
    tylko, że tu chodzi o generowanie biblioteki.

    Tak proste jak:
    
    ar rcs libutil.a algorithm.o converter.o processor.o
    


    Cytat:
    i to jeszcze linkowanych dynamicznie.


    To nie jest linkowanie dynamiczne tylko statyczne, nie mylmy pojec.

    Co do potrzeby trzymania kazdej funkcji w osobnych plikach to nie jestem pewien ale mysle ze watpie. Linker szuka w bibliotekach tzw. niezdefiniowanych symboli i tylko te niezdefiniowane symbole dolacza do kodu wynikowego.
  • #12 5231389
    szelus
    Poziom 34  
    fantom napisał:

    To nie jest linkowanie dynamiczne tylko statyczne, nie mylmy pojec.

    Oczywiście. W przypadku ośmiobitowców nie stosuje się linkowania dynamicznego - to by dopiero było. ;)
    Zresztą dotyczy to w wiekszości mikrokontrolerów, może z wyjątkiem tych największych, gdzie używa się systemów operacyjnych w rodzaju Linux itp :)
    fantom napisał:

    Co do potrzeby trzymania kazdej funkcji w osobnych plikach to nie jestem pewien ale mysle ze watpie. Linker szuka w bibliotekach tzw. niezdefiniowanych symboli i tylko te niezdefiniowane symbole dolacza do kodu wynikowego.


    I tak, i nie. Obiektem w bibliotece (statycznej) jest pojedynczy plik obj (.o). Symbole, zdefiniowane i niezdefiniowane, sa powiązane z tym obiektem. Na podstawie tych symboli linker decyduje, które obiekty dołączyć (tak, aby "rozwiązać" wszystkie niezdefiniowane symbole).
    Niestety, w pliku .o nie ma wystarczającej informacji, aby wydzielić z niego mniejsze obiekty niż cały plik, więc linker musi operować całymi plikami.

    Cały czas piszę tu o narzędziach GNU. W przypadku innych kompilatorów nie musi tak być, choć przeważnie jest. O wyjątkach tylko słyszałem i nie wiem nic pewnego. :)
REKLAMA