Dawno nie szukałem dobrej odpowiedzi na to pytanie.

Zazwyczaj każdy projekt Arduino, ale najprostszy obejmuje:

• Główny plik kodu źródłowego MyProject.ino
• Biblioteki specyficzne dla projektu ( MyProjectLibrary1.h, MyProjectLibrary1.cpp...)
• Biblioteki innych firm (ogólnie bezpłatne oprogramowanie typu open source, dodawane ręcznie do katalogu bibliotek Arduino)
• Schematy, diagramy PCB
• Dokumentacja
• ...

Wszystko to sprawia, że ​​trudno jest zachować cały kod i dokument jednego projektu w ramach zarządzania kodem źródłowym (np. W Subversion, Git lub GitHub).

Zarządzanie kontrolą źródła projektu oznacza zarządzanie wersją wszystkich plików używanych przez projekt, w tym bibliotek zewnętrznych.

Teraz dla jednego projektu muszę zdefiniować strukturę katalogów, która:

• Obejmuje wszystkie pliki projektu, jak opisano powyżej
• Mogę całkowicie zaangażować się w narzędzie do zarządzania kodem źródłowym (w tym zależności osób trzecich)
• Mogę kasować w dowolnym miejscu na dysku twardym i stamtąd budować projekt (czy musi to być pojedyncza lokalizacja narzucona przez Arduino IDE)
• Mogę spakować do samodzielnego archiwum, które mogę wysłać znajomemu, aby zbudował go tak łatwo, jak to możliwe (bez dodatkowego ręcznego pobierania)

Szczególnie trudne w projektach Arduino jest zarządzanie zależnościami bibliotek zewnętrznych. Projekty mają programistów Java Maven repozytoriów za to i to bardzo pomaga w zarządzaniu wszystkie deps zewnętrznych. Ale nie mamy równoważnego systemu dla bibliotek Arduino.

Chciałbym wiedzieć, jak inni twórcy Arduino radzą sobie z tymi aspektami we własnych projektach.

Zauważ też, że jestem otwarty na zmianę mojego procesu rozwoju, w tym mojego IDE (obecnie używam Eclipse z wtyczką Arduino przez większość czasu, a następnie zapewniam, że moje projekty mogą również współpracować bezpośrednio z Arduino IDE).

Mój sposób organizowania projektu arduino jest dość prosty, wszystkie moje projekty to repozytoria git, więc są co najmniej następujące:

• projekt/
  • project.ino
  • Makefile

Preferuję używanie mojego ulubionego edytora i pliku Makefile, który przygotowałem do pracy z większością przypadków użycia (a nawet ulepszyłem ten, który wkrótce udostępnię).

W przypadku bibliotek wolę zachować je jako własne repozytoria i użyć modułu podrzędnego git, aby uwzględnić je w projekcie. Ponieważ wiele bibliotek napisanych przez społeczność jest udostępnianych jako repozytoria git, jest to dobre ogólne rozwiązanie. Następnie w pliku Makefile muszę tylko dodać ścieżkę bibliotek, którą chcę uwzględnić w zmiennej LOCALLIBS .

Chociaż w przypadku niektórych projektów sensowne jest enkapsulowanie bibliotek w bibliotekę warstw abstrakcji sprzętowej przygotowaną dla projektu, wolę użyć ścieżki takiej jak:

• project
  • project.ino
  • Makefile
  • project_hal_lib
    • library1
    • library2
    • library3
    • …

Chociaż w arduino 1.5.x oferowany jest nowy sposób określania bibliotek , który zapewni sposób tworzenia i budowania projektów arduino w taki sam sposób, jak już to robimy z pipy i virtualenv w pythonie, tj. Definiujesz zestaw bibliotek, których potrzebujesz pobierz.

Najprostszym sposobem na to jest skopiowanie plików nagłówka i kodu biblioteki do katalogu źródłowego i dołączenie ich.

myproject/
    myproject.ino
    somelib.h
    somelib.cpp

W swoim kodzie możesz to zrobić include "somelib.h"

Wadą tego jest to, że biblioteki muszą znajdować się w tym samym folderze, a nie w podfolderach, przez co katalog wygląda na bałagan.

Jeśli chodzi o strukturę katalogów całego mojego projektu, w tym schematy i dokumentację, mój zwykle wygląda tak:

myproject/
  schematics/ - eagle files or whatever you may have
  docs/       - include relevant datasheets here
  test/       - any test cases or other code to test parts of the system.
  myproject/  - since Arduino code must be in a directory of the same name
    myproject.ino
    ...

Podmoduły Git są niezwykle potężne, jeśli chodzi o organizowanie wielu zagnieżdżonych repozytoriów. Obsługa wielu bibliotek z różnych źródeł, a nawet obsługa części własnego projektu, które mogą być przechowywane w różnych źródłach, stają się łatwe dzięki podmodułom git.

Struktura katalogów

Sposobem na zorganizowanie projektów będzie:

• projectA - Parent Directory

  • projectA - katalog kodu źródłowego zawierający kod Arduino

    1. projectA.ino
    2. nagłówek. h
    3. Implementacja.cpp

  • docs - Twój główny katalog dokumentacji

  • schematy - można je przechowywać osobno na osobnym repozytorium Git lub części tego samego repozytorium

  • libs - Będzie zawierał biblioteki stron trzecich.

    1. libA - mogą być przechowywane jako repozytoria stron trzecich
    2. libC - ...

  • licencja

  • CZYTAJ

  • Makefile - niezbędny do obsługi zależności między katalogami

Przepływ pracy

Śledziłbyś normalny cykl wprowadzania zmian, dodawania i zatwierdzania w odniesieniu do głównego repozytorium. Z pod-repozytoriami robi się ciekawie.

Masz możliwość dodania repozytorium do katalogu nadrzędnego głównego repozytorium. Oznacza to, że dowolna część twojej struktury katalogów, tj. Dokumenty, schematy itp. Może być utrzymywana jako osobne repozytorium i stale aktualizowana.

Możesz to zrobić za pomocą git submodule add <repo.git>polecenia. Aby go aktualizować, możesz użyć git submodule update <path>.

Jeśli chodzi o utrzymywanie wielu bibliotek stron trzecich w twoim repozytorium, tak aby każda z nich mogła być kontrolowana sama w sobie lub aktualizowana w razie potrzeby, podmoduł git ponownie oszczędza Twój dzień!

Aby dodać repozytorium innej firmy do libs , użyj polecenia git submodule add <lib1.git> libs/lib1. Następnie, aby utrzymać bibliotekę w stałym punkcie w cyklu wydania, sprawdź bibliotekę i dokonaj zatwierdzenia. Aby aktualizować bibliotekę, użyj polecenia git submodule update <path>.

Teraz możesz utrzymywać wiele repozytoriów w głównym repozytorium, a także wiele bibliotek stron trzecich na niezależnych etapach wydania.

W porównaniu z podejściem z pojedynczym katalogiem

Chociaż podejście z jednym katalogiem jest najprostsze, nie jest możliwe kontrolowanie wersji części katalogu bez większego bólu. Dlatego proste podejście nie uwzględnia różnych repozytoriów o różnych stanach w projekcie.

Takie podejście pozwala na utrzymanie wielu repozytoriów, ale wymaga Makefile do obsługi procesu kompilacji i łączenia.

W zależności od złożoności projektu można wybrać optymalne podejście.

Oto sposób, w jaki ostatecznie zdecydowałem się pójść za moimi projektami.

Arduino-CMake

Pierwszą ważną decyzją, którą podjąłem, był wybór narzędzia do kompilacji, które mogłoby działać w moim środowisku (Windows), ale nie ograniczało się do niego (chcę, aby moje projekty mogły być łatwo wykorzystywane przez inne osoby).

Testowałem różne narzędzia do tworzenia Arduino typu open source:

• Guyzmo Makefile (sugerowany przez odpowiedź @zmo): jest to tylko standardowy ręcznie wykonany Makefile dla kompilacji Arduino; jest to Unix Makefile ale jest dobry Port of Unix make dla Windows ; niestety ten plik Makefile działa tylko w systemie Unix, oczywiście można go dostosować do systemu Windows, ale chciałem narzędzia, które działa „po wyjęciu z pudełka”.
• Arduino-Makefile (sugerowany przez odpowiedź @adnues): jest to bardziej zaawansowany projekt oparty na Uniksowym Makefile, którego celem jest łatwość ponownego wykorzystania przez wszystkie projekty Arduino; udokumentowano, że działa na komputerach Mac, Linux i Windows, ale obsługa systemu Windows okazała się nieprawidłowa w moich pierwszych eksperymentach (wiele zależności od powłoki Unix).
• Graduino (nie sugerowane przez żadną odpowiedź): to narzędzie do budowania jest oparte na dobrze znanymnarzędziu do tworzenia stopni z groovy world; narzędzie wydaje się całkiem dobrze wykonane, ale wymaga trochę (niewielkiej) wiedzy na temat rowków / stopni i ma tylko niewielką dokumentację; Postanowiłem nie iść z tym ze względu na ciężar instalacji groovy i grad właśnie do tego (chciałbym uniknąć zbyt wielu wymagań wstępnych dla ludzi, którzy chcą budować moje projekty w swoich środowiskach).
• Arduino-CMake (nie sugerowane przez żadną odpowiedź): wydaje się to najlepsze ze wszystkich, ma długą historię, ma wielu zwolenników i opiekunów, jest bardzo dobrze udokumentowane, zawiera proste przykłady, a także kilka dobrych postów na blogu z samouczkami na Sieć, np. Tu i tam . Opiera się na CMake , „Cross-Platform Make”.

Znalazłem również ArduinoDevel , kolejne narzędzie do kompilacji Arduino - którego nie eksperymentowałem - które może generować pliki Makefile lub pliki Ant build.xml ; ten wydawał się interesujący, ale nieco ograniczony pod względem funkcjonalności.

W końcu zdecydowałem się na Arduino-CMake :

• konfiguracja była łatwa: wystarczy zainstalować CMake na swoim komputerze i skopiować Arduino-CMake do katalogu, który jest łatwo dostępny (poprzez ścieżki względne) z katalogów projektów.
• przykłady zadziałały dla mnie po wyjęciu z pudełka (po prostu podążyłem za komentarzami w CMakeLists.txtpliku konfiguracyjnym, aby dostosować właściwości, które były potrzebne w moim środowisku, np. typ Arduino, port szeregowy)
• możesz organizować swoje projekty w dowolny sposób
• potrafi generować pliki konfiguracyjne dla różnych narzędzi do kompilacji (testowałem tylko Makefile Unixa ), w tym projekty Eclipse .

• w wygenerowanej marce tworzy się kilka celów do obsługi:

  • budowanie bibliotek
  • budowanie programów
  • wgrywanie programu na tablice
  • uruchomienie monitora szeregowego
  • i kilka innych, których jeszcze nie testowałem

Struktura projektu

Ponieważ Arduono-CMake nie narzuca żadnej struktury katalogów dla twojego projektu, możesz wybrać ten, który najbardziej Ci odpowiada.

Oto, co zrobiłem osobiście (wciąż wymaga to dopracowania, ale teraz jestem z tego zadowolony):

Zdecydowałem się umieścić wszystkie moje projekty we wspólnym arduino-stuffkatalogu (który zobowiązuję się do github jako całości, wiem, że mógłbym użyć podmodułów git dla lepszej organizacji na githubie, ale nie miałem jeszcze czasu, aby to sprawdzić).

arduino-stuff ma następującą treść:

• build: to katalog, w którym cmake i make wygenerują wszystkie swoje rzeczy (makefile, pamięć podręczna, pliki obiektów ...); ten nie angażuje się w github
• cmake: ten jest tylko kopią (niemodyfikowaną) katalogu cmake Arduino-CMake . Ten dostaje się na github, więc łatwiej jest komuś, kto chce budować moje projekty
• CMakeLists.txt: to jest „globalna” konfiguracja CMake, która deklaruje wszystkie wartości domyślne dla mojego środowiska (płyta, port szeregowy) i listę podkatalogów docelowych kompilacji
• TaskManager: to mój pierwszy projekt oparty na Arduino-CMake, ten jest biblioteką z przykładami; ta idrectory zawiera również wartość określającą CMakeLists.txtcele dla projektu

Punkty do poprawy

Obecne rozwiązanie nie jest jednak idealne. Wśród ulepszeń, które widzę (dotyczy to raczej projektu Arduino-CMake, aby uwzględnić te ulepszenia, jeśli uznają to za stosowne):

• Funkcja kopiowania katalogu biblioteki z bieżącego projektu do katalogu bibliotek Arduino
• Funkcja przesyłania biblioteki do github
• Funkcja pobierania biblioteki z github

MyProject
|_MyProject
  |_MyProject.ino
  |_data
  |  |_documentation 
  |  |_PCB
  |  |_schematics
  |_src
     |_MyProjectLibrary1
     |_ThirdPartyLibrary

Folder MyProject (katalog główny repozytorium)

Powodem, dla którego sugeruję pozornie zbędny MyProjectfolder główny, jest to, że wspomniałeś o korzystaniu z GitHub. Podczas pobierania (zamiast klonowania) zawartości repozytorium GitHub nazwa gałęzi lub tagu jest dołączana do nazwy repozytorium (np.MyProject-master). Arduino IDE wymaga, aby nazwa folderu szkicu była zgodna z nazwą pliku szkicu. Jeśli otworzysz plik .ino, który znajduje się w folderze, który nie pasuje do nazwy szkicu, Arduino IDE wyświetli monit o utworzenie odpowiednio nazwanego folderu szkicu i przeniesienie szkicu do tego folderu. Oprócz tego, że nie jest to bardzo dobre początkowe doświadczenie dla użytkownika, większym problemem jest to, że Arduino IDE może nie kopiować wszystkich innych powiązanych plików do nowo utworzonego folderu, co może spowodować, że program nie będzie się już kompilował. Umieszczając szkic w podfolderze, unikniesz GitHub zmieniającego nazwę folderu szkicu.

Jeśli nazwa pliku GitHub nie jest dla Ciebie problemem, to zbędny folder główny nie jest konieczny.

folder danych

Polecam używanie datapodfolderu do plików innych niż kod, ponieważ Arduino IDE ma specjalne traktowanie podfolderów o tej nazwie. Są one kopiowane do nowej lokalizacji, kiedy wykonujesz Plik> Zapisz jako ... . Podfoldery o innych nazwach nie są.

folder src

srcPodfolder ma szczególną właściwość pozwala rekurencyjną kompilację . Oznacza to, że możesz pozostawić biblioteki w tym folderze i dołączyć je ze szkicu w następujący sposób:

#include "src/MyProjectLibrary1/MyProjectLibrary1.h"
#include "src/ThirdPartyLibrary/ThirdPartyLibrary.h"

Arduino 1.5 Biblioteka Folder Format struktura jest również wspierany, trzeba tylko dostosować swoje #includeoświadczenia odpowiednio.

Należy pamiętać, że tylko Arduino IDE 1.6.10 (arduino-builder 1.3.19) i nowsze obsługują kompilację szkiców rekurencyjnych.

Niestety niektóre biblioteki używają niepoprawnej #includeskładni dla plików lokalnych (np. #include <ThirdPartyLibrary.h>Zamiast #include "ThirdPartyLibrary.h"). To nadal działa, gdy biblioteka jest zainstalowana w jednym z librariesfolderów Arduino, ale nie działa, gdy biblioteka jest dołączona do szkicu. Dlatego niektóre biblioteki mogą wymagać drobnych zmian w celu użycia w ten sposób.

Zdecydowanie wolę tę opcję niż zrzucanie wszystkich plików bibliotecznych w katalogu głównym folderu szkicu, ponieważ jest to bałagan, a każdy plik biblioteki będzie wyświetlany w Arduino IDE jako zakładki po otwarciu szkicu (oczywiście wszystkie pliki źródłowe robisz chcesz być edytowalne z Arduino IDE należy umieścić w folderze głównym szkicu).

Możliwość korzystania z dołączonych bibliotek w miejscu jest również zgodna z innym celem:

wysłać do przyjaciela, aby zbudował tak łatwo, jak to możliwe

Usunięcie wymogu ręcznego instalowania bibliotek znacznie ułatwia korzystanie z projektu.

Pozwoli to również uniknąć szans na konflikt z innymi wersjami plików biblioteki o tej samej nazwie, które mogą być wcześniej zainstalowane.

Możesz użyć makefile https://github.com/sudar/Arduino-Makefile do kompilacji kodów Arduino. Niekoniecznie potrzebujesz IDE.

Prawdopodobnie naprawdę późno do gry, ale jest to wystarczająco popularne pytanie, aby odpowiedzieć przy użyciu nieco innych metod niż te już opublikowane.

Jeśli chcesz bezpośrednio zachować zgodność z Arduino IDE, możesz użyć czegoś takiego jak ten, który tutaj przedstawiłem:

https://gitlab.com/mikealger/ExampleArduinoProjectStructure/tree/master/ExampleSketchBook

Większość tego opierałem na notatkach Arduino - Struktura projektu i proces kompilacji oraz kilka wskazówek, które zbierałem przez lata.

Naprawdę nie wiem, dlaczego tak trudno jest znaleźć bezpośrednio na stronach Arduino, wydaje się to głupie, biorąc pod uwagę półprofesjonalne tło, że proces kompilacji jest tak tępy.

powodzenia tam