Cela faisait longtemps que je cherchais une bonne réponse à cette question.
En règle générale, tout projet Arduino, mais le plus simple, comprendra:
- Le fichier de code source principal
MyProject.ino
- Bibliothèques spécifiques au projet (
MyProjectLibrary1.h
,MyProjectLibrary1.cpp
...) - Bibliothèques tierces (généralement open source, ajoutées manuellement au répertoire des bibliothèques Arduino)
- Schémas, diagrammes de PCB
- Documentation
- ...
Tout cela rend difficile de garder tout le code et la documentation d'un projet sous Gestion du code source (par exemple, sur Subversion, Git ou GitHub).
La gestion du contrôle de la source de votre projet implique la gestion de la version de tous les fichiers utilisés par le projet, y compris les bibliothèques tierces.
Maintenant, pour un seul projet, je dois définir une structure de répertoire qui:
- Inclut tous les fichiers de projet décrits ci-dessus
- Je peux entièrement m'engager dans un outil de gestion de code source (y compris les dépendances de tiers)
- Je peux commander n'importe où sur mon disque dur et construire le projet à partir de là (faut-il que ce soit un emplacement unique tel qu'imposé par Arduino IDE)
- Je peux zipper dans une archive autonome que je peux envoyer à un ami pour qu'il le construise aussi facilement que possible (pas de téléchargement manuel supplémentaire)
Ce que je trouve particulièrement délicat avec les projets Arduino, c’est la gestion des dépendances de bibliothèques externes. Les développeurs de projets Java disposent de référentiels maven pour cela, ce qui facilite grandement la gestion de tous les dépôts externes. Mais nous n'avons pas de système équivalent pour les bibliothèques Arduino.
Je serais intéressé de savoir comment d'autres porteurs de projets Arduino traitent de ces aspects dans leurs propres projets.
Notez également que je suis ouvert à la modification de mon processus de développement, y compris de mon IDE (actuellement, j'utilise Eclipse avec le plug-in Arduino la plupart du temps, puis je veille à ce que mes projets puissent également fonctionner directement avec l'IDE Arduino).
la source
Réponses:
Ma façon d’organiser un projet arduino est assez simple, tous mes projets sont des dépôts git afin qu’il y ait au moins les éléments suivants:
J'ai une préférence pour mon éditeur préféré et un Makefile que j'ai conçu pour fonctionner avec la plupart des cas d'utilisation (et j'ai même amélioré celui que je vais partager prochainement).
Pour les bibliothèques, je préfère les conserver comme leurs propres référentiels et utiliser le sous-module git pour les inclure dans le projet. Comme de nombreuses bibliothèques écrites par la communauté sont partagées en tant que référentiels git, c'est une bonne solution générique. Ensuite, dans le Makefile, je dois juste ajouter le chemin des bibliothèques que je veux inclure dans la variable LOCALLIBS .
Bien que, pour certains projets, il soit logique d'encapsuler les bibliothèques dans une bibliothèque de couche d'abstraction matérielle conçue pour le projet, je préfère utiliser un chemin tel que:
project
project.ino
Makefile
project_hal_lib
library1
library2
library3
Cependant, avec arduino 1.5.x, une nouvelle méthode de spécification de bibliothèques est proposée, ce qui vous permettra de créer et de construire des projets arduino de la même manière que nous le faisons déjà avec pipy et virtualenv en python, c’est-à-dire que vous définissez le jeu de bibliothèques dont vous avez besoin. se télécharger.
la source
flash
utiliser un programmeur ou d'upload
utiliser le chargeur de démarrage. Ainsi que la gestion de la fusion du chargeur de démarrage avec le firmware. J'ai aussi écrit un ajusteur de fusibles intégré à un fichier.La méthode la plus simple consiste à copier les fichiers d’en-tête et de code de la bibliothèque dans votre répertoire source et à les inclure.
Dans votre code, vous pouvez faire
include "somelib.h"
L'inconvénient est que les bibliothèques doivent se trouver dans le même dossier, et non dans des sous-dossiers, de sorte que votre répertoire a l'air malpropre.
En ce qui concerne la structure de répertoires de tout mon projet, y compris les schémas et la documentation, la mienne ressemble généralement à ceci:
la source
Les sous - modules Git sont extrêmement puissants pour organiser plusieurs référentiels imbriqués. La gestion de plusieurs bibliothèques à partir de sources différentes, et même la gestion de parties de votre propre projet pouvant être stockées dans différentes sources devient plus facile avec les sous-modules git.
Structure du répertoire
Un moyen d'organiser vos projets serait:
projectA - Répertoire parent
projectA - Répertoire de code source contenant le code Arduino
docs - Votre répertoire principal de documentation
schémas - ceux-ci peuvent être conservés séparément sur un référentiel Git séparé ou une partie du même référentiel
libs - Ceci contiendra vos bibliothèques tierces.
Licence
LISEZMOI
Makefile - Nécessaire pour gérer les dépendances entre les répertoires
Flux de travail
Vous suivriez votre cycle normal de modification, d’ajout et de validation en ce qui concerne le référentiel principal. Les choses deviennent intéressantes avec les sous-dépôts.
Vous avez la possibilité d'ajouter un référentiel dans le répertoire parent de votre référentiel principal. Cela signifie que toute partie de votre structure de répertoires, c.-à-d. La documentation, les schémas, etc., peut être conservée en tant que référentiel distinct et continuellement mise à jour.
Vous pouvez le faire en utilisant la
git submodule add <repo.git>
commande. Pour le garder à jour, vous pouvez utilisergit submodule update <path>
.Lorsqu'il s'agit de gérer plusieurs bibliothèques tierces au sein de votre référentiel, chacune d'entre elles pouvant être contrôlée en tant que telle ou pouvant être mise à jour au besoin, git submodule vous permet de sauvegarder à nouveau votre journée!
Pour ajouter un référentiel tiers aux bibliothèques , utilisez la commande
git submodule add <lib1.git> libs/lib1
. Ensuite, pour maintenir la bibliothèque à un point fixe du cycle de publication, extrayez la bibliothèque et effectuez une validation. Pour maintenir la bibliothèque à jour, utilisez la commandegit submodule update <path>
.Vous pouvez désormais gérer plusieurs référentiels dans un référentiel principal ainsi que plusieurs bibliothèques tierces au cours de leurs étapes indépendantes de publication.
Approche par répertoire unique
Bien que l' approche de répertoire unique soit la plus simple, il n'est pas possible de contrôler la version de parties d'un répertoire sans trop de difficultés. Par conséquent, l'approche simple ne permet pas de prendre en charge différents référentiels avec des états variables dans le projet.
Cette approche permet de gérer plusieurs référentiels, mais nécessite la création d’un Makefile pour gérer le processus de compilation et de liaison.
Selon la complexité de votre projet, l'approche optimale peut être sélectionnée.
la source
vendor
,node_modules
, etc.). Git les référence et en garde la trace.Voici comment j'ai finalement décidé de suivre pour mes projets.
Arduino-CMake
La première décision importante que j'ai prise a été le choix d'un outil de compilation qui puisse fonctionner pour mon environnement (Windows), mais ne s'y limitait pas (je veux que mes projets soient facilement réutilisables par d'autres personnes).
J'ai testé divers outils de production Open Source Arduino:
J'ai aussi trouvé ArduinoDevel , un autre outil de compilation Arduino (que je n'ai pas encore expérimenté), capable de générer des Makefiles Unix ou des fichiers ant
build.xml
; celui-ci semblait intéressant mais un peu limité en termes de fonctionnalité.Finalement, j'ai décidé d'aller avec Arduino-CMake :
CMakeLists.txt
fichier de configuration pour adapter les propriétés nécessaires à mon environnement, par exemple le type Arduino, le port série)dans la marque générée, plusieurs cibles sont créées pour prendre en charge:
Structure du projet
Comme Arduono-CMake n’impose aucune structure de répertoires pour votre projet, vous pouvez choisir celui qui vous convient le mieux.
Voici ce que j’ai fait personnellement (il reste encore à préciser, mais j’en suis heureux maintenant):
J'ai décidé de placer tous mes projets dans un
arduino-stuff
répertoire commun (que je m'engage à github dans son ensemble, je sais que je pourrais utiliser des sous-modules git pour une meilleure organisation sur github, mais je n'ai pas encore le temps de vérifier cela).arduino-stuff
a le contenu suivant:build
: c’est un répertoire où cmake et make vont générer tout leur contenu (makefiles, cache, fichiers objets, etc.); celui-ci ne s'engage pas à githubcmake
: celui-ci est juste une copie (non modifiée) du répertoire Arduino-CMake cmake . Celui-ci est sur github pour que ce soit plus facile pour quelqu'un qui veut construire mes projetsCMakeLists.txt
: c'est la configuration "globale" de CMake qui déclare toutes les valeurs par défaut pour mon environnement (carte, port série) et la liste des sous-répertoires de la cible de constructionTaskManager
: ceci est mon premier projet basé sur Arduino-CMake, celui-ci est une bibliothèque avec des exemples; cet identificateur contient également unCMakeLists.txt
qui indique les cibles du projetPoints à améliorer
La solution actuelle n’est cependant pas parfaite. Parmi les améliorations que je vois (c'est plutôt pour le projet Arduino-CMake d'inclure ces améliorations si elles le jugent utile):
la source
Dossier MyProject (racine du référentiel)
La raison pour laquelle je suggère le
MyProject
dossier racine apparemment redondant est que vous avez mentionné l'utilisation de GitHub. Lorsque vous téléchargez (plutôt que clonez) le contenu d'un référentiel GitHub, le nom de la branche ou de la balise est ajouté au nom du référentiel (par exemple:MyProject-master
). L'EDI Arduino requiert que le nom du dossier d'esquisse corresponde à celui du fichier d'esquisse. Si vous ouvrez un fichier .ino se trouvant dans un dossier ne correspondant pas au nom de l'esquisse, l'IDE Arduino vous invite à créer un dossier d'esquisse nommé de manière appropriée et à déplacer l'esquisse dans ce dossier. En plus de ne pas constituer une très bonne expérience initiale pour l'utilisateur, le plus gros problème est que l'IDE Arduino peut ne pas copier tous les autres fichiers associés dans le dossier nouvellement créé, ce qui pourrait empêcher le programme de se compiler. En plaçant l'esquisse dans un sous-dossier, vous évitez que GitHub modifie le nom du dossier d'esquisse.Si le nom de fichier GitHub n’est pas un problème pour vous, le dossier racine redondant n’est pas nécessaire.
dossier de données
Je vous recommande d'utiliser le
data
sous - dossier pour vos fichiers non codés, car l'IDE Arduino applique un traitement spécial aux sous-dossiers de ce nom. Ils sont copiés dans le nouvel emplacement lorsque vous effectuez une Fichier> Enregistrer sous ... . Les sous-dossiers de tout autre nom ne le sont pas.dossier src
Le
src
sous-dossier a la propriété spéciale d'autoriser la compilation récursive . Cela signifie que vous pouvez laisser les bibliothèques dans ce dossier et les inclure à partir de votre croquis de la manière suivante:La structure de dossiers au format Arduino 1.5 Library est également prise en charge. Vous devez uniquement ajuster vos
#include
instructions en conséquence.Notez que seuls Arduino IDE 1.6.10 (arduino-builder 1.3.19) et les versions plus récentes prennent en charge la compilation d’esquisses récursive.
Malheureusement, certaines bibliothèques utilisent une
#include
syntaxe incorrecte pour les fichiers locaux inclus (par exemple,#include <ThirdPartyLibrary.h>
au lieu de#include "ThirdPartyLibrary.h"
). Cela fonctionne toujours lorsque la bibliothèque est installée dans l'un deslibraries
dossiers Arduino mais ne fonctionne pas lorsque la bibliothèque est fournie avec l'esquisse. Ainsi, certaines bibliothèques peuvent nécessiter des modifications mineures pour utiliser cette méthode.Je préfère nettement cela à l’alternative de vider tous les fichiers de la bibliothèque à la racine du dossier d’esquisse car c’est désordonné et chaque fichier de bibliothèque sera affiché dans l’EDI Arduino sous forme d’onglets lorsque vous ouvrez l’esquisse (bien sûr, tous les fichiers source être éditable depuis l’EDI Arduino doit être placé dans le dossier racine de l’esquisse).
Pouvoir utiliser les bibliothèques groupées sur place correspond également à un autre de vos objectifs:
En supprimant la nécessité d'installer manuellement les bibliothèques, le projet est beaucoup plus facile à utiliser.
Cela évitera également tout risque de conflit avec d'autres versions de fichiers de bibliothèque du même nom pouvant être précédemment installés.
la source
Vous pouvez utiliser le fichier Makefile https://github.com/sudar/Arduino-Makefile pour compiler les codes Arduino. Vous n'avez pas nécessairement besoin de l'IDE.
la source
Probablement très tard pour le jeu mais c'est une question assez populaire pour répondre en utilisant des méthodes légèrement différentes de celles déjà postées.
Si vous devez maintenir directement la compatibilité avec Arduino IDE, vous pouvez utiliser quelque chose comme celui que j'ai décrit ici:
https://gitlab.com/mikealger/ExampleArduinoProjectStructure/tree/master/ExampleSketchBook
Je me suis principalement basé sur les notes d’ Arduino - Structure du processus et processus de construction , ainsi que sur les conseils que j’ai choisis au fil des ans.
Je ne sais vraiment pas pourquoi il est si difficile de trouver cela directement via les pages Arduino. Cela semble ridicule de la part d'un milieu semi-professionnel que le processus de construction soit si obtus.
bonne chance là-bas
la source