Vraag:
Hoe de structuur van mijn Arduino-projecten organiseren voor eenvoudige broncontrole?
jfpoilpret
2014-02-22 13:31:10 UTC
view on stackexchange narkive permalink

Het is lang geleden dat ik op zoek was naar een goed antwoord op deze vraag.

Typisch zal elk Arduino-project, maar het eenvoudigste, omvatten:

  • Het belangrijkste broncodebestand MyProject.ino
  • Bibliotheken specifiek voor het project ( MyProjectLibrary1.h , MyProjectLibrary1.cpp . ..)
  • Bibliotheken van derden (over het algemeen gratis open source, handmatig toegevoegd aan de map Arduino-bibliotheken)
  • Schema's, PCB-diagrammen
  • Documentatie
  • ...

Dit alles maakt het moeilijk om de hele code en het document van één project onder Source Code Management te houden (bijv. op Subversion, Git of GitHub).

Het beheren van bronbeheer van uw project betekent het beheren van de versie van alle bestanden die door het project worden gebruikt, inclusief bibliotheken van derden.

Nu moet ik voor een enkel project een directorystructuur definiëren die:

  • Omvat alle projectbestanden zoals hierboven beschreven
  • Ik kan me volledig inzetten voor een broncodebeheertool (inclusief 3e- afhankelijkheden van partijen)
  • Ik kan overal op mijn harde schijf afrekenen en het project van daaruit bouwen (moet het een enkele locatie zijn zoals opgelegd door Arduino IDE)
  • Ik kan in een op zichzelf staand archief dat ik naar een vriend kan sturen zodat hij het zo gemakkelijk mogelijk kan bouwen (geen extra handmatige download)

Wat ik bijzonder lastig vind bij Arduino-projecten, is het beheer van externe afhankelijkheden van bibliotheken. Ontwikkelaars van Java-projecten hebben daarvoor maven repositories en dat helpt veel bij het beheren van alle externe deps. Maar we hebben geen equivalent systeem voor Arduino-bibliotheken.

Ik zou graag willen weten hoe andere Arduino-projectmakers met deze aspecten omgaan in hun eigen projecten.

Merk ook op dat Ik sta open voor het wijzigen van mijn ontwikkelingsproces, inclusief mijn IDE (momenteel gebruik ik Eclipse meestal met de Arduino-plug-in, en dan zorg ik ervoor dat mijn projecten ook rechtstreeks met de Arduino IDE kunnen werken).

Ik heb hier ook moeite mee gehad. Ik heb twee projecten die verschillende versies van een externe bibliotheek nodig hebben, en momenteel vallen ze buiten versiebeheer.
Houd er rekening mee dat dit *** Pakketbeheerders *** zijn voor verder onderzoek. JavaScript kreeg Node.js / npm en bower, PHP kreeg PEAR en Composer, enz.
Zeven antwoorden:
#1
+31
zmo
2014-03-03 17:57:40 UTC
view on stackexchange narkive permalink

Mijn manier om een ​​arduino-project te organiseren is vrij eenvoudig, al mijn projecten zijn git-repositories, zodat er tenminste het volgende is:

Ik gebruik mijn favoriete editor en een Makefile die ik heb gemaakt om tegen de meeste use-cases te werken (en ik heb zelfs de versie verbeterd die ik binnenkort ga delen).

Voor de bibliotheken geef ik de voorkeur aan om ze als hun eigen repositories te houden en git submodule te gebruiken om ze in het project op te nemen. Aangezien veel bibliotheken die door de community zijn geschreven, worden gedeeld als git-repositories, is dat een goede generieke oplossing. Vervolgens hoef ik binnen de Makefile alleen het bibliothekenpad toe te voegen dat ik wil opnemen in de variabele LOCALLIBS.

Hoewel het voor sommige projecten zinvol is om de bibliotheken in te kapselen in een hardware-abstractielaagbibliotheek die voor het project is gemaakt, dan gebruik ik liever een pad zoals:

  • project
    • project. ino
    • Makefile
    • project_hal_lib
      • bibliotheek1
      • bibliotheek2
      • bibliotheek3

Hoewel, met arduino 1.5.x een nieuwe manier om bibliotheken te specificeren wordt aangeboden, die een manier zal bieden om op dezelfde manier arduino-projecten te maken en te bouwen we doen al met pipy en virtualenv in python, dwz je definieert de set bibliotheken die je nodig hebt en ze worden gedownload.

Ik werkte aan een soortgelijk antwoord. Je hebt me verslagen!
+1 Bedankt! Deze manier ziet er best interessant uit. Ik zal het deze week eens moeten proberen (ik moet echter eerst kijken hoe ik de Makefile-dingen moet instellen).
@AsheeshR als uw antwoord vergelijkbaar was, betekent dat dat er nog steeds enkele verschillen zijn, toch? Ik zou hier graag over willen weten!
eigenlijk zijn de belangrijkste veranderingen die met de volgende versie van mijn Makefile komen, de mogelijkheid om te "flashen" met een programmeur of te "uploaden" met de bootloader. Evenals het afhandelen van het samenvoegen van bootloader met firmware. Ik heb ook een in-makefile fuse setter geschreven.
@zmo-premie verdiende, hoewel uw Makefile-oplossing niet kan werken in mijn situatie (met Windows, maar ik heb dat punt niet gespecificeerd). Maar ik ben ervan overtuigd dat het gebruik van een van de bestaande makefile-oplossingen de juiste keuze is. Zodra ik er een heb gevonden die voor mij geschikt is, zal ik mijn antwoord hier plaatsen.
nou, eigenlijk heb ik mijn Makefile ontworpen om op de een of andere manier Windows-compatibel te zijn ... hoewel ik op dat moment geen Windows had om het te testen! Dus zeker, als je wilt helpen om het te verbeteren, ben je welkom :-)
#2
+23
sachleen
2014-02-23 00:38:39 UTC
view on stackexchange narkive permalink

De eenvoudigste manier om dit te doen is door de header- en codebestanden van de bibliotheek naar uw brondirectory te kopiëren en ze op te nemen.

  myproject / myproject.ino somelib.h somelib.cpp  

In je code kun je doen include "somelib.h"

De keerzijde hiervan is dat de bibliotheken in de dezelfde map, geen submappen, dus je map ziet er rommelig uit.


Met betrekking tot de mapstructuur van mijn hele project, inclusief schema's en documentatie, ziet de mijne er meestal als volgt uit:

  mijnproject / schematics / - eagle-bestanden of wat je ook hebt docs / - voeg hier relevante datasheets toe test / - eventuele testgevallen of andere code om delen van het systeem te testen. myproject / - aangezien Arduino-code in een directory met dezelfde naam moet staan ​​myproject.ino ...  
Een ander nadeel is dat ik bij veel projecten dezelfde bibliotheken moet kopiëren. Het is mij ook niet duidelijk of u alleen UW bibliotheken daarin plaatst of ook bibliotheken van derden?
Eerste punt: dat is niet echt een keerzijde, dat is slechts een neveneffect van het bij elkaar houden van bibliotheken en projectbronnen zoals je wilde met versiebeheer. Wat moet ik doen als een ander project een bijgewerkte versie van de bibliotheek nodig heeft? Wat als u het wijzigt? Tweede punt: beide zullen werken.
Akkoord. Waar zet je nu andere bestanden voor het project en de bibliotheken (schema's, documentatie)? In een subdir, in het project, daarbuiten?
@jfpoilpret Ik heb mijn antwoord bijgewerkt met mijn typische directorystructuur.
Bedankt voor de update, +1 voor je antwoord. Ik ben benieuwd wat anderen doen voor hun eigen projecten.
Nog een vraag, na het dupliceren van uw eigen bibliotheken in de verschillende projecten die ze gebruiken, kan een van deze projecten enkele bugs of verbeteringen van een gedupliceerde bibliotheek aantreffen; dan moet je de wijzigingen overal weer dupliceren, dat is foutgevoelig en tijdrovend! Als u een van deze bibliotheken op zichzelf (buiten elk project) wilt "openen" zodat anderen ze kunnen gebruiken, moet u ook de wijzigingen daarin dupliceren. Heeft u een truc om dit probleem te omzeilen?
Ik doe niet. De Arduino IDE is op veel manieren vrij beperkt. Misschien wilt u een betere werkomgeving zoeken die hiervoor een betere ondersteuning biedt. Mensen hebben op maat gemaakte bestanden gemaakt waarmee u ook bibliotheken uit andere bronnen kunt importeren.
Dit is geen goede manier om projecten te organiseren vanuit het oogpunt van softwarelicenties. Als u bibliotheken van derden in uw project opneemt, die mogelijk verschillende licenties hebben, dan overtreedt u deze mogelijk zodra u het projectbestand begint te delen. Verschillende open source licenties zijn * over het algemeen * niet compatibel met elkaar.
@AsheeshR met al uw bestanden in één map zodat de arduino IDE niet klaagt, is helemaal geen goede manier om projecten te organiseren. Het is gewoon * een * manier. Voel je vrij om een ​​betere oplossing voor te stellen. Ik ken er geen waarmee je nog steeds de Arduino-software kunt gebruiken.
#3
+21
asheeshr
2014-03-04 21:54:18 UTC
view on stackexchange narkive permalink

Git-submodules zijn buitengewoon krachtig als het gaat om het organiseren van meerdere geneste repositories. Het verwerken van meerdere bibliotheken uit verschillende bronnen, en zelfs het afhandelen van delen van je eigen project die in verschillende bronnen kunnen zijn opgeslagen, wordt gemakkelijk met git submodules.

Directorystructuur

Een manier om je projecten te organiseren zou zijn:

  • projectA - Parent Directory

    • projectA - Bron codedirectory met Arduino-code

      1. projectA.ino
      2. header.h
      3. implementatie.cpp
    • documenten - Uw hoofddocumentatiemap

    • schema's - deze kunnen afzonderlijk op een aparte Git-opslagplaats of deel van dezelfde opslagplaats

    • libs - Dit bevat uw bibliotheken van derden.

      1. libA - Deze kunnen worden onderhouden als opslagplaatsen van derden.
      2. libC - ...
    • licentie

    • LEESMIJ

    • Makefile - Noodzakelijk om afhankelijk te zijn ies tussen mappen

Workflow

Je volgt je normale cyclus van wijzigingen aanbrengen, toevoegen en vastleggen voor zover de belangrijkste repository betreft. Het wordt interessant met de sub-repositories.

Je hebt de mogelijkheid om een ​​repository toe te voegen aan de bovenliggende directory van je hoofdrepository. Dit betekent dat elk deel van je directorystructuur, dwz docs, schema's, etc. kan worden onderhouden als een aparte repository en continu kan worden bijgewerkt vanaf.

Je kunt dit doen met behulp van de git submodule add <repo. git> commando. Om het up-to-date te houden, kun je git submodule update <path> gebruiken.

Als het aankomt op het onderhouden van meerdere bibliotheken van derden binnen je repository, zodat ze allemaal op zichzelf kunnen worden gecontroleerd of elk up-to-date gehouden kan worden indien nodig, dan scheelt git submodule opnieuw je dag!

Om een ​​repo van een derde partij toe te voegen aan libs , gebruik je het commando git submodule add <lib1.git> libs / lib1 . Om de bibliotheek vervolgens op een vast punt in de releasecyclus te onderhouden, moet u de bibliotheek uitchecken en een commit maken. Om de bibliotheek up-to-date te houden, gebruik je het commando git submodule update <path> .

Nu kun je meerdere repositories binnen een hoofdrepository onderhouden, evenals meerdere bibliotheken van derden in hun onafhankelijke stadia van uitgave.

Versus Single Directory Approach

Hoewel de enkele directory-benadering de eenvoudigste is, is het niet mogelijk om zonder veel moeite delen van een directory te beheren . Daarom slaagt de eenvoudige benadering er niet in om verschillende repositories met verschillende statussen in het project te accommoderen.

Deze benadering staat het onderhouden van meerdere repositories toe, maar brengt de behoefte aan een Makefile met zich mee om het compilatie- en koppelingsproces af te handelen.

Afhankelijk van de complexiteit van uw project, kan de optimale aanpak worden gekozen.

+1, maar alleen als kanttekening: Git-submodules zijn behoorlijk onstabiel en waarschijnlijk los van het spoor. Het maakt niet uit of je een enkele directory of veelvouden gebruikt (zoals 'vendor', 'node_modules', etc.). Git verwijst ernaar en houdt het bij.
"Het maakt niet uit of je een enkele directory of veelvouden gebruikt (zoals vendor, node_modules, etc.)." Ik begreep dit gedeelte niet. Kunt u dit toelichten?
#4
+18
jfpoilpret
2014-03-30 15:23:10 UTC
view on stackexchange narkive permalink

Dit is de manier waarop ik uiteindelijk besloot te volgen voor mijn projecten.

Arduino-CMake

De eerste belangrijke beslissing die ik nam was de keuze van een build-tool die zou kunnen werken voor mijn omgeving (Windows) maar was er niet toe beperkt (ik wil dat mijn projecten gemakkelijk herbruikbaar zijn door andere mensen).

Ik heb verschillende open source Arduino-tools getest:

  • Guyzmo Makefile (voorgesteld door @zmo antwoord): dit is gewoon een standaard Makefile, handgemaakt voor Arduino-builds; dit is een Unix Makefile maar er is een goede port van Unix make for Windows ; toch werkt dit Makefile helaas alleen voor Unix, het zou natuurlijk aangepast kunnen worden voor Windows, maar ik wilde een tool die "out of the box" werkt.
  • Arduino-Makefile (voorgesteld door @adnues antwoord): dit is een geavanceerder project, gebaseerd op Unix Makefile, dat ernaar streeft gemakkelijk herbruikbaar te zijn door alle Arduino-projecten; het is gedocumenteerd als werkend op Mac, Linux en Windows, maar Windows-ondersteuning bleek onjuist in mijn eerste experimenten (veel afhankelijkheden van Unix-shell).
  • Graduino (door geen enkel antwoord gesuggereerd): deze buildtool is gebaseerd op de bekende gradle buildtool uit de groovy wereld; de tool lijkt redelijk goed gedaan maar vereist wat (beetje) groovy / gradle kennis, en heeft maar weinig documentatie; Ik besloot er niet mee door te gaan vanwege de last van het installeren van groovy en gradle alleen ervoor (ik zou graag te veel vereisten willen vermijden voor mensen die mijn projecten op hun omgeving willen bouwen).
  • Arduino-CMake (door geen enkel antwoord gesuggereerd): dit lijkt het beste van allemaal, het heeft een lange geschiedenis, heeft veel supporters en beheerders, is zeer goed gedocumenteerd, wordt geleverd met eenvoudige voorbeelden en heeft ook een paar goede tutorial blogposts op het web, bijv hier en daar. Het is gebaseerd op CMake, een "Cross-Platform Make".

Ik heb ook ArduinoDevel gevonden, een andere Arduino-buildtool -waar ik niet mee heb geëxperimenteerd- die Unix Makefiles of kan genereren ant build.xml bestanden; die leek interessant, maar een beetje beperkt in termen van functionaliteit.

Uiteindelijk besloot ik voor Arduino-CMake:

  • het was gemakkelijk instellen: installeer gewoon CMake op uw machine en kopieer Arduino-CMake in een map die gemakkelijk toegankelijk is (via relatieve paden) vanuit uw projectmappen.
  • de voorbeelden zijn uitgewerkt het vak voor mij (volg gewoon de opmerkingen in het CMakeLists.txt -configuratiebestand om eigenschappen aan te passen die nodig zijn voor mijn omgeving, bijv.Arduino-type, seriële poort)
  • je kunt je projecten op elke gewenste manier
  • het kan configuratiebestanden genereren voor verschillende build-tools die er zijn (ik heb echter alleen Unix Makefiles getest), inclusief Eclipse -projecten .
  • in het gegenereerde make, worden verschillende doelen gemaakt om te ondersteunen:

    • bibliotheken bouwen
    • programma's bouwen
    • programma uploaden naar borden
    • starten van seriële monitor
    • en een paar o deze heb ik nog niet getest

Projectstructuur

Aangezien Arduono-CMake geen mapstructuur oplegt voor uw project, kunt u kies degene die het beste bij je past.

Dit is wat ik persoonlijk heb gedaan (dat moet nog verder worden verfijnd, maar ik ben er nu blij mee):

enter image description here

Ik heb besloten om al mijn projecten in een gemeenschappelijke arduino-stuff -directory te plaatsen (die ik vastleg aan github als geheel, ik weet dat ik git submodules voor een betere organisatie op github, maar had nog geen tijd om dat te controleren).

arduino-stuff heeft de volgende inhoud:

  • build : dat is een map waarin cmake en make al hun spullen genereren (makefiles, cache, objectbestanden ...); deze wordt niet vastgelegd in github
  • cmake : die is slechts een kopie (ongewijzigd) van de map Arduino-CMake cmake. Deze komt op github zodat het gemakkelijker is voor iemand die mijn projecten wil bouwen
  • CMakeLists.txt : dat is de "globale" CMake-configuratie die alle standaardinstellingen voor mijn omgeving declareert ( board, seriële poort) en de lijst met subdirectory's voor builddoeleinden
  • TaskManager : dit is mijn eerste project op basis van Arduino-CMake, dit is een bibliotheek met voorbeelden; deze idrectory bevat ook een CMakeLists.txt die de doelen voor het project aangeeft

Te verbeteren punten

De huidige oplossing is echter niet perfect Onder de verbeteringen die ik zie (dat is eerder voor het Arduino-CMake-project om deze verbeteringen op te nemen als ze dat nodig achten):

  • Functie om een ​​bibliotheekdirectory van het huidige project naar de Arduino-bibliothekendirectory te kopiëren
  • Functie om een ​​bibliotheek te uploaden naar github
  • Functie om een ​​bibliotheek te downloaden van github
Heb je PlatformIO al geprobeerd? Misschien was het er niet toen je deze vraag stelde .. http://platformio.org/
Het lijkt erop dat het project een paar keer is gestorven en herrezen: [arduino-cmake] (https://github.com/queezythegreat/arduino-cmake) → [forked arduino-cmake] (https://github.com/arduino- cmake / arduino-cmake) → [Arduino-CMake-NG] (https://github.com/arduino-cmake/Arduino-CMake-NG) → [Arduino-CMake-Toolchain] (https://github.com/ a9183756-gh / Arduino-CMake-Toolchain).
#5
+6
per1234
2017-11-04 09:30:49 UTC
view on stackexchange narkive permalink
  MyProject | _MyProject | _MyProject.ino | _data | | _documentatie | | _PCB | | _schematics | _src | _MyProjectLibrary1 | _ThirdPartyLibrary  

MyProject-map (repository-root)

De reden dat ik de schijnbaar overtollige MyProject -hoofdmap suggereer is die je noemde met GitHub. Wanneer je de inhoud van een GitHub-repository downloadt (in plaats van klonen), wordt de branch- of tagnaam toegevoegd aan de repositorynaam (bijv. MyProject-master ). De Arduino IDE vereist dat de naam van de schetsmap overeenkomt met de naam van het schetsbestand. Als u een .ino-bestand opent dat zich in een map bevindt die niet overeenkomt met de schetsnaam, vraagt ​​de Arduino IDE u om een ​​schetsmap met de juiste naam te maken en de schets naar die map te verplaatsen. Behalve dat dit geen erg goede eerste ervaring is voor de gebruiker, is het grotere probleem dat de Arduino IDE mogelijk niet alle andere bijbehorende bestanden naar de nieuw gemaakte map kopieert, waardoor het programma mogelijk niet langer compileert. Door de schets in een submap te plaatsen, vermijdt u dat GitHub de naam van de schetsmap wijzigt.

Als de GitHub-bestandsnaam geen probleem voor u is, is de overtollige hoofdmap niet nodig.

datamap

Ik raad aan om de submap data te gebruiken voor je niet-codebestanden, omdat de Arduino IDE een speciale behandeling heeft voor submappen met die naam. Ze worden naar de nieuwe locatie gekopieerd als u een Bestand> Opslaan als ... uitvoert. Submappen met een andere naam zijn dat niet.

src-map

De src -submap heeft de speciale eigenschap om recursieve compilatie toe te staan. Dit betekent dat u de bibliotheken in die map kunt laten staan ​​en ze als volgt uit uw schets kunt opnemen:

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

De mapstructuur in Arduino 1.5-bibliotheekformaat wordt ook ondersteund, u hoeft alleen uw #include -instructies dienovereenkomstig aan te passen.

Merk op dat alleen Arduino IDE 1.6.10 (arduino-builder 1.3.19) en nieuwere ondersteunen recursieve sketch compilatie.

Helaas gebruiken sommige bibliotheken de onjuiste #include syntaxis voor lokale file include (bijv. > #include <ThirdPartyLibrary.h> in plaats van #include "ThirdPartyLibrary.h" ). Dit werkt nog steeds wanneer de bibliotheek is geïnstalleerd in een van de Arduino bibliotheken -mappen, maar werkt niet wanneer de bibliotheek is gebundeld met de schets. Dus sommige bibliotheken hebben mogelijk kleine bewerkingen nodig om op deze manier te gebruiken.

Ik geef de voorkeur aan het alternatief om alle bibliotheekbestanden in de root van de schetsmap te dumpen, omdat dat rommelig is en elk bibliotheekbestand zal worden getoond in de Arduino IDE als tabbladen wanneer je de sketch opent (natuurlijk moeten alle bronbestanden die je wilt bewerken vanuit de Arduino IDE in de hoofdmap van de sketch worden geplaatst).

In staat zijn om gebundelde bibliotheken te gebruiken op zijn plaats is ook in lijn met een van je andere doelen:

naar een vriend sturen zodat hij zo gemakkelijk mogelijk kan bouwen

De vereiste om handmatig install bibliotheken maakt het project veel gemakkelijker te gebruiken.

Dit voorkomt ook mogelijke conflicten met andere versies van bibliotheekbestanden met dezelfde naam die eerder zijn geïnstalleerd.

#6
+3
anujdeshpande
2014-03-15 15:22:25 UTC
view on stackexchange narkive permalink

Je zou het makefile https://github.com/sudar/Arduino-Makefile kunnen gebruiken voor het compileren van Arduino-codes. Je hebt niet per se de IDE nodig.

Ik heb het geprobeerd, maar helaas werkt het alleen op Unix-machines en heb ik Windows-ondersteuning nodig. Momenteel evalueer ik een ander project op basis van CMake, maar ik ben er nog niet klaar mee. Ik zal een antwoord plaatsen als ik een tool heb gekozen.
#7
+1
Mike Alger
2017-06-07 20:34:19 UTC
view on stackexchange narkive permalink

Waarschijnlijk erg laat in het spel, maar het is een vraag die populair genoeg is om te beantwoorden met iets andere methoden dan de reeds geposte.

Als je de compatibiliteit met Arduino IDE direct wilt behouden, kun je zoiets gebruiken als degene die ik hier heb beschreven:

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

Ik heb het meeste hiervan gebaseerd op de aantekeningen van Arduino - Projectstructuur en bouwproces, en enkele tips die ik heb opgepikt tijdens de jaren.

Ik weet echt niet waarom dit zo moeilijk rechtstreeks via Arduino-pagina's te vinden is, het lijkt dwaas vanuit een semi-professionele achtergrond dat het bouwproces zo stom is.

geluk daarbuiten

De gitlab-link lijkt te zijn verbroken
vreemd werkt het zonder de directe link? d.w.z. https://gitlab.com/mikealger/ExampleArduinoProjectStructure
Eigenlijk werken beide links in Firefox, maar geen van beide werkt in mijn verouderde Chrome-versie 49.0.2623.112 (64-bit). Niets om je zorgen over te maken, denk ik. :-)


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...