この質問に対する良い答えを探していたのは久しぶりです。

通常、任意のArduinoプロジェクトが最も単純なプロジェクトに含まれます：

• メインソースコードファイル MyProject.ino
• プロジェクト固有のライブラリ（MyProjectLibrary1.h、MyProjectLibrary1.cpp...）
• サードパーティライブラリ（通常は無料のオープンソース、Arduinoライブラリディレクトリに手動で追加）
• 回路図、PCBダイアグラム
• ドキュメンテーション
• ...

これにより、1つのプロジェクトのコード全体とドキュメントをソースコード管理（Subversion、Git、GitHubなど）の下に保持することが難しくなります。

プロジェクトのソース管理の管理とは、サードパーティのライブラリを含むプロジェクトで使用されるすべてのファイルのバージョンを管理することを意味します。

ここで、1つのプロジェクトについて、次のディレクトリ構造を定義する必要があります。

• 上記のすべてのプロジェクトファイルが含まれます
• ソースコード管理ツールに完全にコミットできます（サードパーティの依存関係を含む）
• ハードドライブのどこでもチェックアウトし、そこからプロジェクトをビルドできます（Arduino IDEによって課される単一の場所である必要があります）
• 自己完結型のアーカイブに圧縮して、友人ができるだけ簡単に構築できるように送信できます（追加の手動ダウンロードは不要です）

Arduinoプロジェクトで特に注意が必要なのは、外部ライブラリの依存関係の管理です。Javaプロジェクトの開発者はそのためのMavenリポジトリを持っているため、すべての外部開発を管理するのに非常に役立ちます。ただし、Arduinoライブラリに対応するシステムはありません。

他のArduinoプロジェクトメーカーが自分のプロジェクトでこれらの側面をどのように扱っているかを知りたいと思います。

また、IDEを含め、開発プロセスを変更することもできます（現在、ほとんどの場合、ArduinoプラグインでEclipseを使用しています。その後、プロジェクトがArduino IDEで直接動作することを確認しています）。

arduinoプロジェクトを整理する私の方法は非常に簡単です。私のプロジェクトはすべてgitリポジトリであるため、少なくとも次のものがあります。

• 事業/
  • project.ino
  • メイクファイル

私は私の使って好み持って好きなエディタとMakefileの私は、ほとんどのユースケースに対して動作するように細工している（と私も、私はすぐに共有するつもりですその1に改善します）。

ライブラリについては、独自のリポジトリとして保持し、gitサブモジュールを使用してプロジェクトに含めることを好みます。コミュニティによって書かれた多くのライブラリはgitリポジトリとして共有されているため、これは優れた汎用ソリューションです。次に、Makefile内で、LOCALLIBS変数に含めるライブラリパスを追加するだけです。

ただし、一部のプロジェクトでは、プロジェクト用に作成されたハードウェアアブストラクションレイヤライブラリにライブラリをカプセル化するのが理にかなっていますが、次のようなパスを使用することを好みます。

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

しかし、arduino 1.5.xaではライブラリを指定する新しい方法が提供されますが、これは既にPythonでpipyとvirtualenvを使用して行うのと同じ方法でarduinoプロジェクトを作成および構築する方法を提供します。ダウンロードしてください。

これを行う最も簡単な方法は、ライブラリのヘッダーファイルとコードファイルをソースディレクトリにコピーし、それらを含めることです。

myproject/
    myproject.ino
    somelib.h
    somelib.cpp

あなたのコードでは、次のことができます include "somelib.h"

これの欠点は、ライブラリがサブフォルダではなく同じフォルダにある必要があるため、ディレクトリが乱雑に見えることです。

回路図とドキュメントを含む私のプロジェクト全体のディレクトリ構造に関して、私のものは通常次のようになります：

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

Gitサブモジュールは、ネストされた複数のリポジトリを整理する際に非常に強力です。さまざまなソースからの複数のライブラリの処理、さらにはさまざまなソースに格納される可能性のある独自のプロジェクトの一部の処理も、gitサブモジュールを使用して簡単になります。

ディレクトリ構造

プロジェクトを整理する方法は次のとおりです。

• projectA-親ディレクトリ

  • projectA -Arduinoコードを含むソースコードディレクトリ

    1. projectA.ino
    2. header.h
    3. implementation.cpp

  • docs-メインのドキュメントディレクトリ

  • 回路図 -これらは別個のGitリポジトリまたは同じリポジトリの一部で個別に維持できます

  • libs-これにはサードパーティのライブラリが含まれます。

    1. libA-これらはサードパーティのリポジトリとして維持される場合があります
    2. libC-...

  • ライセンス

  • README

  • Makefile-ディレクトリ間の依存関係を処理するために必要

ワークフロー

メインリポジトリに関する限り、通常の変更サイクル、追加、コミットのサイクルに従います。サブリポジトリで物事が面白くなります。

メインリポジトリの親ディレクトリにリポジトリを追加するオプションがあります。これは、ディレクトリ構造のどの部分、つまりドキュメント、回路図なども、個別のリポジトリとして維持し、そこから継続的に更新できることを意味します。

これを行うには、git submodule add <repo.git>コマンドを使用します。最新の状態に保つには、を使用できますgit submodule update <path>。

リポジトリ内で複数のサードパーティライブラリを維持し、それぞれをそれ自体でバージョン管理できるようにするか、必要に応じてそれぞれを最新の状態に保つことができるようになると、gitサブモジュールが再び時間を節約します！

libsにサードパーティのリポジトリを追加するには、コマンドを使用しgit submodule add <lib1.git> libs/lib1ます。次に、リリースサイクルの固定ポイントでライブラリを維持するには、ライブラリをチェックアウトしてコミットします。ライブラリを最新の状態に保つには、コマンドを使用しgit submodule update <path>ます。

現在、メインリポジトリ内の複数のリポジトリと、リリースの独立した段階で複数のサードパーティライブラリを管理できます。

単一ディレクトリアプローチと

一方で、単一のディレクトリのアプローチが最も簡単です、それは多くの痛みなしに、ディレクトリのバージョン管理の部分には不可能です。したがって、この単純なアプローチでは、プロジェクト内のさまざまな状態のさまざまなリポジトリに対応できません。

このアプローチにより、複数のリポジトリを維持できますが、Makefileがコンパイルおよびリンクプロセスを処理する必要が生じます。

プロジェクトの複雑さに応じて、最適なアプローチを選択できます。

これが、私がプロジェクトに最終的に従うことにした方法です。

Arduino-CMake

私が最初に行った重要な決定は、自分の環境（Windows）で機能するビルドツールを選択することでしたが、それに限定されません（プロジェクトを他の人が簡単に再利用できるようにしたい）。

さまざまなオープンソースのArduino makeツールをテストしました。

• Guyzmo Makefile（@zmo answerが推奨）：これはArduinoビルド用に手作りされた標準のMakefileです。これは、Unix Makefileのですが、そこにある良いポートの Unixのは、Windowsのために作ります。それでも、残念ながら、このMakefileはUnixでのみ機能します。もちろんWindowsにも適用できますが、「すぐに使用できる」ツールが必要でした。
• Arduino-Makefile（@adnues回答で推奨）：これは、すべてのArduinoプロジェクトで簡単に再利用できるようにすることを目的とした、Unix Makefileに基づくより高度なプロジェクトです。Mac、Linux、およびWindowsで動作することが文書化されていますが、私の最初の実験ではWindowsのサポートが間違っていることが判明しました（Unixシェルへの多くの依存関係）。
• Graduino（いずれかの答えによって示唆されていない）：このビルド・ツールのベースとなる、よく知られているのGradleからのビルドツールグルーヴィーな世界。このツールは非常によくできているように見えますが、いくつかの（小さな）groovy / gradleに関する知識が必要であり、ドキュメントはほとんどありません。groovyとgradleをインストールするだけの負担があるため、私はこれを使用しないことにしました（自分の環境でプロジェクトをビルドしたい人にあまりにも多くの前提条件を与えないようにします）。
• Arduino-CMake（どの回答でも提案されていません）：これは何よりも優れているようです。長い歴史があり、多くのサポーターとメンテナーがいます。ウェブ、例えばこことそこ。これは、「クロスプラットフォームメイク」である CMakeに基づいています。

また、別のArduinoビルドツールであるArduinoDevelを見つけました。これは、まだ実験していませんが、Unix Makefileまたはant build.xmlファイルを生成できます。その1つは面白そうに見えましたが、機能面で少し制限されていました。

最後に、Arduino-CMakeを使用することにしました。

• セットアップは簡単でした。マシンにCMakeをインストールし、Arduino-CMakeをプロジェクトディレクトリから（相対パスで）簡単にアクセスできるディレクトリにコピーするだけです。
• サンプルはそのままCMakeLists.txt使用できました（構成ファイルのコメントに従って、Arduinoタイプ、シリアルポートなど、環境に必要なプロパティを調整します）
• プロジェクトを自由に編成できます
• Eclipseプロジェクトを含む、さまざまなビルドツールの構成ファイルを生成できます（ただし、Unix Makefileのみをテストしました）。

• 生成されたmakeでは、いくつかのターゲットが作成されてサポートされます。

  • ライブラリビルド
  • プログラム構築
  • ボードへのプログラムのアップロード
  • シリアルモニターの起動
  • まだテストしていない他のいくつか

プロジェクト構造

Arduono-CMakeはプロジェクトのディレクトリ構造を強制しないため、最適なディレクトリ構造を選択できます。

ここに私が個人的にやったことを示します（これにはさらに改良が必要ですが、今は満足しています）：

すべてのプロジェクトを共通のarduino-stuffディレクトリの下に置くことにしました（全体としてgithubにコミットします。githubでより良い組織のためにgitサブモジュールを使用できることはわかっていますが、まだ確認する時間はありませんでした）。

arduino-stuff 次のコンテンツがあります。

• build：cmakeとmakeがすべてのもの（メイクファイル、キャッシュ、オブジェクトファイルなど）を生成するディレクトリです。これはgithubにコミットされません
• cmake：これはArduino-CMake cmakeディレクトリの単なるコピー（変更なし）です。これはgithubにあるので、プロジェクトをビルドしたい人にとっては簡単です
• CMakeLists.txt：これは、環境（ボード、シリアルポート）のすべてのデフォルトとビルドターゲットサブディレクトリのリストを宣言する「グローバルな」CMake構成です。
• TaskManager：これはArduino-CMakeに基づいた私の最初のプロジェクトです。これは例のあるライブラリです。このidrectoryにCMakeLists.txtは、プロジェクトのターゲットを示すが含まれています

改善点

しかし、現在の解決策は完全ではありません。私が見る改善の中で（むしろ、Arduino-CMakeプロジェクトがこれらの改善が適切であると判断した場合、それを含めることです）：

• ライブラリディレクトリを現在のプロジェクトからArduinoライブラリディレクトリにコピーする機能
• ライブラリをGitHubにアップロードする機能
• githubからライブラリをダウンロードする機能

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

MyProjectフォルダー（リポジトリールート）

一見冗長なMyProjectルートフォルダーを推奨する理由は、GitHubを使用して言及したためです。GitHubリポジトリのコンテンツを（クローンではなく）ダウンロードすると、リポジトリ名にブランチ名またはタグ名が追加されます（例：MyProject-master）。Arduino IDEでは、スケッチフォルダー名がスケッチファイル名と一致する必要があります。スケッチ名と一致しないフォルダーにある.inoファイルを開くと、Arduino IDEは適切な名前のスケッチフォルダーを作成し、そのフォルダーにスケッチを移動するように求めます。これはユーザーにとって非常に良い初期体験ではないことに加えて、より大きな問題は、Arduino IDEが他のすべての関連ファイルを新しく作成されたフォルダーにコピーせず、プログラムがコンパイルできなくなる可能性があることです。スケッチをサブフォルダーに入れることにより、GitHubがスケッチフォルダーの名前を変更するのを防ぎます。

GitHubファイル名が問題にならない場合は、冗長なルートフォルダーは必要ありません。

データフォルダ

dataArduino IDEにはその名前のサブフォルダーの特別な処理があるため、非コードファイルにはサブフォルダーを使用することをお勧めします。File> Save As ...を実行すると、新しい場所にコピーされます。他の名前のサブフォルダーはそうではありません。

srcフォルダー

srcサブフォルダは、許可の特殊な性質がある再帰的なコンパイルを。これは、そのフォルダーにライブラリを残し、次のようにスケッチからライブラリを含めることができることを意味します。

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

Arduinoの1.5ライブラリ形式のフォルダ構造はまた、あなただけのあなたの調整する必要があり、サポートされている#includeに応じて文を。

Arduino IDE 1.6.10（arduino-builder 1.3.19）以降のみが再帰スケッチコンパイルをサポートしていることに注意してください。

残念ながら、一部のライブラリは、#includeローカルファイルインクルードに誤った構文を使用します（例：の#include <ThirdPartyLibrary.h>代わりに#include "ThirdPartyLibrary.h"）。ライブラリがArduino librariesフォルダの1つにインストールされている場合でも機能しますが、ライブラリがスケッチにバンドルされている場合は機能しません。そのため、一部のライブラリでは、この方法を使用するために若干の編集が必要になる場合があります。

スケッチフォルダーのルートにあるすべてのライブラリファイルをダンプする代わりに、これが非常に好きです。これは、すべてのライブラリファイルがArduino IDEでスケッチを開くときにタブとして表示されるためです（もちろん、ソースファイルArduino IDEから編集可能にする場合は、スケッチルートフォルダーに配置する必要があります）。

バンドルされたライブラリを所定の場所で使用できるようにすることも、別の目標と一致しています。

友だちに送って、できるだけ簡単に構築できるようにする

ライブラリを手動でインストールする要件を削除すると、プロジェクトがはるかに使いやすくなります。

これにより、以前にインストールされた同じ名前の他のバージョンのライブラリファイルと競合する可能性も回避されます。

Arduinoコードのコンパイルには、メイクファイルhttps://github.com/sudar/Arduino-Makefileを使用でき ます。IDEは必ずしも必要ではありません。

おそらく本当にゲームに遅れましたが、すでに投稿されているものとは少し異なる方法を使用して答えるのに十分な人気のある質問です。

Arduino IDEとの互換性を直接維持する必要がある場合は、ここで説明したようなものを使用できます。

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

このほとんどはArduinoのメモ-プロジェクトの構造とビルドプロセス、および長年にわたって取り上げてきたいくつかのヒントに基づいています。

Arduinoのページから直接これを見つけるのがなぜ難しいのかは本当にわかりませんが、半プロのバックグラウンドから来ているのは愚かなようで、ビルドプロセスはとても鈍いです。

幸運を祈ります