microgeek.eu

Witam serdecznie.


Dzisiaj pokażę, w jaki sposób zebrać wszystkie napisane przez nas (i nie tylko) libsy w jednym folderze na twardym dysku. Libsy te będą dostępne w projekcie bez konieczności każdorazowego ich importowania do folderu projektu. Co to daje? Po pierwsze, nie mamy libsa np. "uart" zaimportowanego 127 razy do każdego projektu w naszym workspace. Po drugie, w przypadku konieczności poprawy działania libsa, wystarczy go poprawić w jednym miejscu, a cała reszta projektów automatycznie będzie miała dostęp do zaktualizowanej wersji. Ok, no to do dzieła.

Przede wszystkim tworzę sobie na dysku C folder i nazywam go AVR_Libraries. Do folderu wrzucam folder o nazwie uart, a w nim: uart.c, uart.h, mcudeps.h. Ot, mój libsik do uartu, który do tej pory importowałem do każdego projektu, w którym chciałem skorzystać z uartu w AVR. No dobra, mamy zrobiony folder z libsami (póki co z jednym). Odpalamy eclipse. Na potrzeby znalezienia tego rozwiązania stworzyłem sobie nowy workspace (tak na wszelki wypadek - gdybym coś przypadkiem zepsuł), ale można niniejszy sposób zastosować na już istniejącym. Ok, eclipse odpalony, tworzę nowy projekt o nazwie TEST1. następnie prawym klawiszem myszy klikam w projekt i wybieram properties/C/C++ Generall/Paths and Symbols:




W zakładce Includes klikamy w Add, a następnie wybieramy file system i z drzewka wybieramy folder AVR8_Libraries. Klikamy OK i okienko się zamyka. Zaznaczamy "add to all configurations" oraz "add to all languages", żeby potem nie musieć przy tym grzebać, gdy przesiądziemy się np. na C++.


Ponownie klikamy OK i małe okienko się zamyka. przechodzimy do zakładki Source location:



Tutaj klikamy w Link folder, otworzy się okienko:



Zaznaczamy "link to folder in the file system", a następnie klikamy Browse. Z drzewka wybieramy AVR8_Libraries i klikamy OK. No i to wszystko. Konfiguracja gotowa. W oknie Paths and Symbols klikamy Apply, a potem OK.

Wracamy do projektu TEST1. Dodajemy do niego plik main.c, a w nim napiszemy test poprawności podłączenia libsa. Proszę bardzo:



Do pliku dodane są standardowe includy, czyli stdbool.h oraz io.h. Ostatnim includem jest mój libsik umieszczony w folderze AVR8_Libraries. Na zdjęciu powyżej zaznaczyłem strzałką z lewej strony nowy element, który pojawił się w drzewku projektu. Tam można przeglądać dostępne libsy.

Proszę zauważyć, że libsy dołączone do projektu w ten sposób inkluduje się z zastosowaniem nawiasów trójkątnych, ponieważ nie znajdują się one wewnątrz folderu z projektem.

Pozdrawiam!

Świetna sprawa. Dzięki.

A jak wygląda sprawa z kompilacją, kompiluje się tylko zainkludowany libs (uart.h), czy wszystkie z katalogu (AVR8_Libraries)?

Kompilują się tylko te pliki, które dołączysz do projektu dyrektywą #include. Muszę jeszcze spróbować dołączyć libsa do I2C, skompilować, a następnie odłączyć ten libs od projektu. W tradycyjnym podejściu, czyli z libsami wewnątrz projektu, Eclipse miewa nawyk pamiętania o libsie, który odłączyłem od projektu (przestałem go inkludować). Dziś wieczorem to sprawdzę i dam znać.

Wykonałem test z dwoma libsami. W folderze AVR8_Libraries znajdują się dwa libsy: uart oraz i2c. Dopóki nie zainkludowałem i2c w projekcie, kompilacja uwzględniała plik main.c oraz pliki zawarte w folderze uart. Niestety...gdy dodałem na chwilę i2c i puściłem kompilację, późniejsze usuwanie #include<I2C/i2c.h> nie powodowało automatycznego wykluczania tego folderu z kompilacji. Rozwiązania są dwa:

1. Dowiązywać do projektu nie cały folder ze zbiorem libsów (w moim przypadku AVR8_Libraries), a podfoldery z konkretnymi libsami.
2. Dowiązywać cały folder ze zbiorem libsów, a następnie w drzewku projektu wykonać na każdym nieużywanym podfolderze z libsem "exclude from build". W przypadku posiadania dużej ilości libsów może to być kłopotliwe.

Osobiście skłaniam się ku pierwszemu rozwiązaniu.

W ustawieniach projektu można sobie dowolnie odpinać i dopinać foldery. Myślę jednak, że chodzi Ci o pliki startowe dla STM, a tam to jest chyba inaczej rozwiązane. W wolnej chwili przyjrzę się temu.

Podpowiem jeszcze przy okazji zastosowanie - to jest mega przydatne, gdy robimy sobie jakąś komunikację z adresowaniem itp i w jednym pliku mamy wszystkie te adresy urządzeń nadawczych odbiorczych itp. Wtedy zmieniamy w jednym pliku adres jednego i omijamy masę błędów związanych z zapomnieniem zmiany w jednym projekcie.

Odkopuję temat - trochę odnośnie pytania, które zadał rezasurmar.

Załóżmy, mega prosty przykład - że mamy np bibliotekę do migania trzema diodami i używamy jej w 3 różnych projektach. Niby lib i funkcje takie same, ale w każdym projekcie są podpięte pod inne piny - jak to można ogarnąć? Zazwyczaj kwestie pinologii trzymałem w plikach h znajdujących się w bibliotekach. Można znaleźć jakieś pośrednie rozwiązanie, czy trzeba tak pisać biblioteki, by kwestie sprzętowe też jej przekazywać z poziomu głównego programu (chodzi mi np o GPIOA i pin8 jako parametry do podania bibliotece, coś jak rejestracja callbaczków)?

Można stworzyć dodatkowy plik nagłówkowy i w nim trzymać lokalną konfigurację pinów, a potem ją dopinać do biblioteki...ale to takie trochę sztuczne rozwiązywanie problemów. Moim zdaniem najlepiej rejestrować funkcje sterujące sprzętem (pinami, IIC, SPI.. itp.) i w ten sposób, przy okazji, tworzyć biblioteki zupełnie oderwane od warstwy sprzętowej. Podczas inicjalizacji dopinasz/rejestrujesz funkcję wysyłającą dane na szynę, czy jakąś funkcję machającą 15 pinami... i tyle. Biblioteka będzie z niej korzystała nie mając pojęcia, z jakim prockiem "rozmawia"

Tak - dla modułów tak mam - powiedzmy, że jest to moduł BLE no to przesyłam ładuje do niego dane po uarcie (ale równie dobrze mogą to być dane z czegokolwiek) i on mi zwraca callbacki jak odbierze jakieś dane na charakterystykach itp. Dla takich modułów nie ma problemu, ale już poziom niżej - dla biblioteki od uartu jest - bo to zawsze jest na innych pinach i jest praktycznie w każdym projekcie używane.

Zgadzam się w pełni z określeniem, ze dodatkowy plik to "sztuczne rozwiązanie problemu". Ale mam też jeszcze jeden pomysł, ale też taki pośredni - w pliku .h mieć "#if defined" - dla projektów, które wykorzystują daną bibliotekę i w projekcie definiować w ustawieniach projektu wartość dla jakiejś flagi - była wcześniej mowa o STMach - tam jest podobny mechanizm - pliki są wspólne dla wieeelu procków i właściwe części do uruchomienia rozpoznawane są po symbolu (ustawia się to w tym samym menu co ścieżki).
Obiektywny rzut okiem na ten pomysł:
Zalety:
- nie dodajemy jakiegoś zewnętrznego pliku do każdego projektu osobno
- nie wymaga wielkich modyfikacji w aktualnych bibliotekach (jedynie dopisanie tych "#if defined" w pliku *.h)
Wady:
- trzeba pamiętać o dodaniu tego symbolu, aczkolwiek można to robić przy linkowaniu folderu z biblioteką za jednym razem
- zrobi się potem wielgachny plik nagłówkowy z tego

Mogę zapytać o opinie o odnośnie tego pomysłu?

dambo pisze:pliki są wspólne dla wieeelu procków i właściwe części do uruchomienia rozpoznawane są po symbolu

Tak, wtedy budujemy swoje własne arduino lub mbed... Oczywiście przesadzam, ale to zmierza w tym kierunku. To nie oznacza, że rozwiązanie jest złe, ale plik nagłówkowy "lowest level" zaczyna się mocno rozrastać. Mam taki plik przy biblioteczce obsługującej wszystkie uarty w ATmegach - dodawałem procki, dodawałem...i nie było widać końca Prawda jest taka, że nie ma idealnego rozwiązania. Zawsze jakiś procek będzie odstawał od reszty i specjalnie dla niego trzeba będzie naginać te wypracowane i dopieszczane przez lata zasady budowania własnych bibliotek.

Ja mam pomysł na ten temat. Mianowicie do każdego projektu dodajecie globalny plik konfiguracyjny (np. main.h czy projCFG.h), w którym konfigurujecie potrzebne biblioteki (czy piny do nich), po czym w pliku main.c jako pierszwszy inkludujecie plik konfigurujący dany projekt. Nie trzeba nawet w libsach nic dopisywać (oczywiście o ile dało się w nich logikę zabezpieczenia przed nie istniejącymi wpisami np. przez #ifndef). Macie 1 wersję plików biblioteki (bo i we wspólnym katalogu plików o tej samej nazwie nie może być więcej, a ciągła zmiana danych w plikach libs pod projekt mija się z celem ideologią tego zabiegu /żeby libsy były wspólne dla wszystkich projektów/), a do każdego projektu indywidualnie macie plik konfiguracyjny "lokalnie".