Faz muito tempo que estou procurando uma boa resposta para essa pergunta.

Normalmente, qualquer projeto do Arduino, mas o mais simples, inclui:

• O principal arquivo de código fonte MyProject.ino
• Bibliotecas específicas para o projeto ( MyProjectLibrary1.h, MyProjectLibrary1.cpp...)
• Bibliotecas de terceiros (geralmente de código aberto gratuito, adicionados manualmente ao diretório de bibliotecas do Arduino)
• Esquemas, diagramas de PCB
• Documentação
• ...

Tudo isso dificulta a manutenção de todo o código e o documento de um projeto no Gerenciamento de código-fonte (por exemplo, no Subversion, Git ou GitHub).

Gerenciar o controle de origem do seu projeto significa gerenciar a versão de todos os arquivos usados ​​pelo projeto, incluindo bibliotecas de terceiros.

Agora, para um único projeto, preciso definir uma estrutura de diretórios que:

• Inclui todos os arquivos de projeto, conforme descrito acima
• Posso me comprometer totalmente com uma ferramenta de Gerenciamento de Código Fonte (incluindo dependências de terceiros)
• Posso fazer checkout em qualquer lugar do meu disco rígido e criar o projeto a partir daí (ele precisa ser um único local, conforme imposto pelo IDE do Arduino)
• Posso compactar em um arquivo independente que posso enviar a um amigo para que ele crie o mais fácil possível (sem download manual extra)

O que acho particularmente complicado nos projetos do Arduino é o gerenciamento de dependências de bibliotecas externas. Os desenvolvedores de projetos Java possuem repositórios maven para isso e isso ajuda muito no gerenciamento de todos os deps externos. Mas não temos um sistema equivalente para bibliotecas do Arduino.

Eu estaria interessado em saber como outros fabricantes de projetos do Arduino lidam com esses aspectos em seus próprios projetos.

Observe também que estou aberto a alterar meu processo de desenvolvimento, incluindo meu IDE (atualmente uso o Eclipse com o plug-in Arduino na maioria das vezes e, em seguida, garanto que meus projetos também possam trabalhar diretamente com o Arduino IDE).

Minha maneira de organizar um projeto arduino é bastante simples, todo o meu projeto são repositórios git, de modo que haja pelo menos o seguinte:

• projeto/
  • project.ino
  • Makefile

Eu tenho uma preferência usando o meu editor favorito e um Makefile que criei para trabalhar contra a maioria dos casos de uso (e até aprimorei aquele que vou compartilhar em breve).

Para as bibliotecas, prefiro mantê-las como seus próprios repositórios e usar o submódulo git para incluí-las no projeto. Como muitas bibliotecas escritas pela comunidade são compartilhadas como repositórios git, essa é uma boa solução genérica. Então, dentro do Makefile, eu apenas tenho que adicionar o caminho das bibliotecas que quero incluir na variável LOCALLIBS .

Embora, para alguns projetos, faça sentido encapsular as bibliotecas em uma biblioteca de camada de abstração de hardware criada para o projeto, prefiro usar um caminho como:

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

Embora, com o arduino 1.5.xa, seja oferecida uma nova maneira de especificar bibliotecas , isso oferecerá uma maneira de criar e construir projetos do arduino da mesma maneira que já fazemos com o pipy e o virtualenv em python, ou seja, você define o conjunto de bibliotecas que você precisa e elas seja baixado.

A maneira mais simples de fazer isso é copiar os arquivos de cabeçalho e código da biblioteca no diretório de origem e incluí-los.

myproject/
    myproject.ino
    somelib.h
    somelib.cpp

No seu código, você pode fazer include "somelib.h"

O lado negativo disso é que as bibliotecas devem estar na mesma pasta, não nas subpastas, para que seu diretório pareça confuso.

Em relação à estrutura de diretórios de todo o meu projeto, incluindo esquemas e documentação, a minha geralmente se parece com isso:

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
    ...

Os submódulos do Git são extremamente poderosos quando se trata de organizar vários repositórios aninhados. O manuseio de várias bibliotecas de fontes diferentes e até o manuseio de partes do seu próprio projeto, que podem ser armazenadas em fontes diferentes, ficam fáceis com os submódulos git.

Estrutura de Diretórios

Uma maneira de organizar seus projetos seria:

• projectA - Diretório pai

  • projectA - Diretório de código-fonte que contém o código do Arduino

    1. projectA.ino
    2. header.h
    3. Implementação.cpp

  • docs - Seu diretório de documentação principal

  • esquemáticos - eles podem ser mantidos separadamente em um repositório Git separado ou em parte do mesmo repositório

  • libs - Isso conterá suas bibliotecas de terceiros.

    1. libA - Estes podem ser mantidos como repositórios de terceiros
    2. libC - ...

  • licença

  • LEIA-ME

  • Makefile - Necessário para lidar com dependências entre diretórios

Workflow

Você seguiria seu ciclo normal de fazer alterações, adicionar e confirmar no que diz respeito ao repositório principal. As coisas ficam interessantes com os sub-repositórios.

Você tem a opção de adicionar um repositório ao diretório pai do seu repositório principal. Isso significa que qualquer parte de sua estrutura de diretórios, como documentos, esquemas etc., pode ser mantida como um repositório separado e continuamente atualizada.

Você pode fazer isso usando o git submodule add <repo.git>comando Para mantê-lo atualizado, você pode usar git submodule update <path>.

Quando se trata de manter várias bibliotecas de terceiros dentro do seu repositório, de modo que cada uma possa ser controlada por versão em si ou cada uma delas possa ser atualizada, se necessário, o submodule git novamente salva seu dia!

Para adicionar uma terceira repo parte libs , use o comando git submodule add <lib1.git> libs/lib1. Em seguida, para manter a biblioteca em um ponto fixo no ciclo de lançamento, faça check-out da biblioteca e faça uma confirmação. Para manter a biblioteca até à data, use o comando git submodule update <path>.

Agora, você pode manter vários repositórios em um repositório principal e várias bibliotecas de terceiros em seus estágios independentes de lançamento.

Abordagem de diretório único versus

Embora a abordagem de diretório único seja a mais simples, não é possível controlar a versão de partes de um diretório sem muita dificuldade. Portanto, a abordagem simples falha em acomodar repositórios diferentes com estados variáveis ​​no projeto.

Essa abordagem permite manter vários repositórios, mas traz a necessidade de um Makefile para lidar com o processo de compilação e vinculação.

Dependendo da complexidade do seu projeto, a abordagem ideal pode ser selecionada.

Aqui está o caminho que finalmente decidi seguir para meus projetos.

Arduino-CMake

A primeira decisão importante que tomei foi a escolha de uma ferramenta de construção que pudesse funcionar no meu ambiente (Windows), mas não se limitou a ela (quero que meus projetos sejam facilmente reutilizáveis ​​por outras pessoas).

Eu testei várias ferramentas de código-fonte aberto do Arduino:

• Guyzmo Makefile (sugerido pela @zmo answer): este é apenas um Makefile padrão feito à mão para compilações do Arduino; este é um Unix Makefile, mas existe uma boa porta do Unix make para Windows ; ainda assim, infelizmente, esse Makefile funciona apenas para Unix, é claro que poderia ser adaptado para Windows, mas eu queria uma ferramenta que funcionasse "fora da caixa".
• Arduino-Makefile (sugerido pela resposta @adnues): este é um projeto mais avançado, baseado no Unix Makefile, que visa ser facilmente reutilizável por todos os projetos do Arduino; está documentado como funcionando no Mac, Linux e Windows, mas o suporte ao Windows se mostrou errado nas minhas primeiras experiências (muitas dependências no shell do Unix).
• Graduino (não sugerido por nenhuma resposta): esta ferramenta de construção é baseada na conhecidaferramenta de construção de gradles domundo groovy ; a ferramenta parece muito bem-feita, mas requer algum (pouco) conhecimento groovy / gradle e possui apenas pouca documentação; Decidi não concordar com isso devido ao ônus de instalar o groovy e o gradle apenas para ele (eu gostaria de evitar muitos pré-requisitos para as pessoas que desejam criar meus projetos em seus ambientes).
• Arduino-CMake (não sugerido por nenhuma resposta): isso parece o melhor de todos, tem uma longa história, tem muitos apoiadores e mantenedores, está muito bem documentado, vem com exemplos simples e também possui algumas boas postagens de blog tutorial no Web, por exemplo, aqui e ali . É baseado no CMake , uma "Marca de Plataforma Cruzada".

Eu também encontrei o ArduinoDevel , outra ferramenta de construção do Arduino - que eu não experimentei - que pode gerar Makefiles do Unix ou arquivos ant build.xml ; esse parecia interessante, mas um pouco limitado em termos de funcionalidade.

Por fim, decidi usar o Arduino-CMake :

• foi fácil de configurar: basta instalar o CMake em sua máquina e copiar o Arduino-CMake em algum diretório que seja facilmente acessível (por caminhos relativos) nos diretórios dos projetos.
• os exemplos funcionaram prontamente para mim (apenas segui os comentários no CMakeLists.txtarquivo de configuração para adaptar as propriedades necessárias para o meu ambiente, por exemplo, tipo Arduino, porta serial)
• você pode organizar seus projetos da maneira que quiser
• ele pode gerar arquivos de configuração para várias ferramentas de construção disponíveis no mercado ( embora eu só tenha testado o Unix Makefiles ), incluindo projetos Eclipse .

• na marca gerada, vários destinos são criados para oferecer suporte:

  • construção de bibliotecas
  • construção de programas
  • upload de programa para placas
  • lançamento do monitor serial
  • e alguns outros que ainda não testei

Estrutura do Projeto

Como o Arduono-CMake não impõe nenhuma estrutura de diretórios para o seu projeto, você pode escolher a que melhor se adequa a você.

Aqui está o que eu fiz pessoalmente (que ainda requer refinamentos adicionais, mas estou feliz com isso agora):

Decidi colocar todos os meus projetos em um arduino-stuffdiretório comum (que me comprometo com o github como um todo, sei que poderia usar os submodules git para uma organização melhor no github, mas ainda não tive tempo de verificar isso).

arduino-stuff tem o seguinte conteúdo:

• build: esse é um diretório em que cmake e make gerará todo o seu material (makefiles, cache, arquivos de objetos ...); este não se compromete com o github
• cmake: esse é apenas uma cópia (não modificada) do diretório cmake do Arduino-CMake . Este entra no github para que seja mais fácil para quem quer criar meus projetos
• CMakeLists.txt: essa é a configuração "global" do CMake que declara todos os padrões do meu ambiente (placa, porta serial) e a lista de subdiretórios de destino da construção
• TaskManager: este é meu primeiro projeto baseado no Arduino-CMake, este é uma biblioteca com exemplos; esse diretório também contém um CMakeLists.txtque indica os destinos para o projeto

Pontos a melhorar

A solução atual não é perfeita. Entre as melhorias que eu vejo (é melhor que o projeto Arduino-CMake inclua essas melhorias, se assim entenderem):

• Recurso para copiar um diretório de biblioteca do projeto atual para o diretório de bibliotecas do Arduino
• Recurso para carregar uma biblioteca no github
• Recurso para baixar uma biblioteca do github

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

Pasta MyProject (raiz do repositório)

A razão pela qual sugiro a MyProjectpasta raiz aparentemente redundante é que você mencionou o uso do GitHub. Quando você baixa (em vez de clonar) o conteúdo de um repositório do GitHub, o nome do ramo ou da marca é anexado ao nome do repositório (por exemplo,MyProject-master) O IDE do Arduino exige que o nome da pasta de esboço corresponda ao nome do arquivo de esboço. Se você abrir um arquivo .ino que está em uma pasta que não corresponde ao nome do esboço, o IDE do Arduino solicitará que você crie uma pasta de esboço com nome apropriado e mova o esboço para essa pasta. Além de não ser uma experiência inicial muito boa para o usuário, o maior problema é que o IDE do Arduino pode não copiar todos os outros arquivos associados para a pasta recém-criada, o que pode causar a compilação do programa. Ao colocar o esboço em uma subpasta, você evita que o GitHub altere o nome da pasta de esboço.

Se o nome do arquivo GitHub não for um problema para você, a pasta raiz redundante não será necessária.

pasta de dados

Eu recomendo usar a datasubpasta para arquivos que não sejam de código, porque o IDE do Arduino possui um tratamento especial para as subpastas desse nome. Eles são copiados para o novo local quando você faz uma Arquivo> Salvar como ... . Subpastas de qualquer outro nome não são.

pasta src

A srcsubpasta tem a propriedade especial de permitir compilação recursiva . Isso significa que você pode deixar as bibliotecas nessa pasta e incluí-las no seu esboço assim:

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

A estrutura de pastas no formato da biblioteca do Arduino 1.5 também é suportada; você só precisa ajustar suas #includeinstruções de acordo.

Observe que apenas o Arduino IDE 1.6.10 (arduino-builder 1.3.19) e o mais recente suportam a compilação recursiva de esboços.

Infelizmente, algumas bibliotecas usam a #includesintaxe incorreta para inclusões de arquivos locais (por exemplo, em #include <ThirdPartyLibrary.h>vez de #include "ThirdPartyLibrary.h"). Isso ainda funciona quando a biblioteca é instalada em uma das librariespastas do Arduino, mas não funciona quando a biblioteca é empacotada com o esboço. Portanto, algumas bibliotecas podem exigir edições menores para serem usadas dessa maneira.

Eu prefiro isso à alternativa de descarregar todos os arquivos de biblioteca na raiz da pasta de esboço, porque isso é confuso e todos os arquivos de biblioteca serão mostrados no Arduino IDE como guias quando você abre o esboço (é claro que qualquer arquivo de origem que você faz deseja ser editável a partir do IDE do Arduino deve ser colocado na pasta raiz do esboço).

A capacidade de usar bibliotecas agrupadas no local também está alinhada com outro de seus objetivos:

envie a um amigo para ele construir o mais fácil possível

A remoção do requisito de instalação manual de bibliotecas torna o projeto muito mais fácil de usar.

Isso também evitará qualquer chance de conflito com outras versões dos arquivos de biblioteca com o mesmo nome que podem ser instalados anteriormente.

Você pode usar o makefile https://github.com/sudar/Arduino-Makefile para compilar códigos do Arduino. Você não precisa necessariamente do IDE.

Provavelmente muito tarde para o jogo, mas é uma pergunta popular o suficiente para responder usando métodos ligeiramente diferentes dos já publicados.

Se você precisar manter a compatibilidade com o Arduino IDE diretamente, poderá usar algo como o que descrevi aqui:

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

Baseei a maior parte disso nas notas do Arduino - Estrutura do projeto e no processo de construção , e em algumas dicas que aprendi ao longo dos anos.

Eu realmente não sei por que isso é tão difícil de encontrar diretamente através das páginas do Arduino, parece bobagem de uma formação semiprofissional que o processo de compilação é tão obtuso.

boa sorte lá fora