ESP32-C3 ワイヤレス アドベンチャー

ESP32-C3 ワイヤレス アドベンチャー

IoTの総合ガイド

エスプレッシフシステムズ 12年2023月XNUMX日

仕様

• 製品: ESP32-C3 ワイヤレスアドベンチャー
• メーカー: Espressif Systems
• 日付: 12年2023月XNUMX日

製品使用説明書

準備

ESP32-C3ワイヤレスアドベンチャーを使用する前に、
IoTの概念とアーキテクチャに精通していること。
デバイスがより大きなIoTエコシステムにどのように適合するかを理解している
スマートホームにおけるその潜在的な応用について。

IoTプロジェクトの紹介と実践

このセクションでは、典型的なIoTプロジェクトについて学びます。
一般的なIoTデバイス用の基本モジュール、基本モジュールを含む
クライアントアプリケーションと共通のIoTクラウドプラットフォーム。これにより
理解と創造の基盤を提供します
独自の IoT プロジェクト。

実践: スマートライトプロジェクト

この練習プロジェクトでは、スマートな
ESP32-C3ワイヤレスアドベンチャーを使用したライト。プロジェクト構造、
機能、ハードウェアの準備、開発プロセスは
詳細に説明しました。

プロジェクト構造

このプロジェクトは、以下のいくつかの要素で構成されています。
ESP32-C3 ワイヤレスアドベンチャー、LED、センサー、クラウド
バックエンド。

プロジェクト機能

スマートライトプロジェクトでは、明るさを制御し、
モバイルアプリを介してLEDの色を遠隔操作したり、 web
インタフェース。

ハードウェアの準備

プロジェクトの準備として、
ESP32-C3ワイヤレスなどの必要なハードウェアコンポーネント
アドベンチャーボード、LED、抵抗器、電源。

開発プロセス

開発プロセスには開発環境の構築が含まれる
環境、LEDを制御するコードの記述、
クラウドバックエンド、スマートデバイスの機能テスト
ライト。

ESP RainMakerの紹介

ESP RainMakerはIoTを開発するための強力なフレームワークです
デバイス。このセクションでは、ESP RainMakerとは何か、
プロジェクトにどのように実装できるか。

ESP RainMakerとは何ですか?

ESP RainMakerは、一連の機能を提供するクラウドベースのプラットフォームです。
IoT デバイスを構築および管理するためのツールとサービス。

ESP RainMakerの実装

このセクションでは、
クレームサービスを含むESP RainMakerの実装
RainMaker エージェント、クラウド バックエンド、および RainMaker クライアント。

実践: ESP RainMaker を使った開発のポイント

この練習セクションでは、
ESP RainMakerで開発する際に考慮すべき事項。これにはデバイスが含まれます
請求、データ同期、ユーザー管理。

ESP RainMakerの特徴

ESP RainMakerはユーザー管理、エンドユーザー向けのさまざまな機能を提供します。
ユーザー、管理者が簡単にデバイスを管理できます。
セットアップ、リモートコントロール、監視。

開発環境のセットアップ

このセクションでは、view ESP-IDF（Espressif IoT）の
開発フレームワーク（公式開発フレームワーク）
ESP32ベースのデバイス用。
ESP-IDF と開発環境の設定方法。

ハードウェアとドライバーの開発

ESP32-C3 ベースのスマート ライト製品のハードウェア設計

このセクションでは、スマートライトのハードウェア設計に焦点を当てます。
ESP32-C3ワイヤレスアドベンチャーをベースにした製品。
スマートライト製品の機能と構成、および
ESP32-C3 コアシステムのハードウェア設計。

スマートライト製品の特徴と構成

このサブセクションでは、
スマートライト製品について解説します。さまざまな機能について説明します
スマート ライトを作成するための設計上の考慮事項について説明します。

ESP32-C3 コアシステムのハードウェア設計

ESP32-C3コアシステムのハードウェア設計には電源が​​含まれています
電源、電源投入シーケンス、システムリセット、SPIフラッシュ、クロックソース、
RFとアンテナに関する考慮事項。このサブセクションでは、
これらの側面に関する詳細な情報。

よくある質問

Q: ESP RainMakerとは何ですか?

A: ESP RainMakerはクラウドベースのプラットフォームで、ツールを提供します
IoTデバイスの構築と管理のためのサービス。
開発プロセスが簡素化され、デバイスのセットアップが簡単になり、リモート
制御、監視。

Q: 開発環境をどのように設定すればよいですか？
ESP32-C3?

A: ESP32-C3の開発環境をセットアップするには、
ESP-IDF（Espressif IoT開発フレームワーク）をインストールし、
提供された指示に従って設定してください。ESP-IDFは
ESP32 ベースのデバイス用の公式開発フレームワーク。

Q: ESP RainMaker の機能は何ですか?

A: ESP RainMakerには、ユーザーインターフェイスを含むさまざまな機能があります。
管理、エンドユーザー機能、管理者機能。ユーザー管理
デバイスの請求とデータの同期が簡単に行えます。エンドユーザー
モバイルアプリや
web インターフェース。管理機能にはデバイス監視ツールが備わっている。
および管理。

ESP32-C3 ワイヤレス アドベンチャー
IoTの総合ガイド
エスプレッシフシステムズ 12年2023月XNUMX日

コンテンツ

I 準備

1

1 IoT入門

3

1.1 IoT のアーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 スマートホームにおける IoT アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 IoTプロジェクトの紹介と実践

9

2.1 一般的な IoT プロジェクトの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 一般的な IoT デバイスの基本モジュール . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 クライアントアプリケーションの基本モジュール . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.3 一般的な IoT クラウド プラットフォームの概要 . . . . . . . . . . . . . . . . 11

2.2 実践: スマート ライト プロジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 プロジェクト構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 プロジェクトの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 ハードウェアの準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 開発プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 ESP RainMakerの紹介

19

3.1 ESP RainMaker とは何ですか? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 ESP RainMaker の実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 クレームサービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 RainMaker エージェント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 クラウド バックエンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.4 RainMaker クライアント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 実践: ESP RainMaker を使った開発のポイント . . . . . . . . . . . . . 25

3.4 ESP RainMaker の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 ユーザー管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 エンドユーザー機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.3 管理機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 開発環境の設定

31

4.1 ESP-IDF終了view 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 31

4.1.1 ESP-IDF のバージョン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3

4.1.2 ESP-IDF Gitワークフロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 適切なバージョンの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4 以上view ESP-IDF SDK ディレクトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2 ESP-IDF 開発環境のセットアップ . . . . . . . . . . . . . . . . . . . . 38 4.2.1 Linux での ESP-IDF 開発環境のセットアップ . . . . . . . . . 38 4.2.2 Windows での ESP-IDF 開発環境のセットアップ . . . . . . . 40 4.2.3 Mac での ESP-IDF 開発環境のセットアップ . . . . . . . . . 45 4.2.4 VS Code のインストール . . . . . . . . . . . . . 46 サードパーティ開発環境の紹介 . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 46 ESP-IDF コンパイル システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 47 コンパイル システムの基本概念 . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 47 プロジェクト File 構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 コンパイルシステムのデフォルトのビルドルール . . . . . . . . . . . . . . . . 50 4.3.4 コンパイルスクリプトの紹介 . . . . . . . . . . . . . . . . . . . . . 51 4.3.5 共通コマンドの紹介 . . . . . . . . . . . . . . . . . . . . . . . 52 4.4 練習: Ex のコンパイルampプログラム「Blink」 . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.1 例amp53 ログファイルの分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 56 Blink プログラムのコンパイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 59 Blink プログラムのフラッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 60 Blink プログラムのシリアル ポート ログ分析 . . . . . . . . . . . . . . . 4.5 63 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XNUMX

II ハードウェアとドライバの開発

65

5 ESP32-C3 ベースのスマート ライト製品のハードウェア設計

67

5.1 スマートライト製品の機能と構成 . . . . . . . . . . . . . . . . . 67

5.2 ESP32-C3 コアシステムのハードウェア設計 . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2.1 電源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2 電源投入シーケンスとシステムリセット . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.3 SPI フラッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.4 クロック ソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.5 RF とアンテナ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.6 ストラップピン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2.7 GPIO および PWM コントローラ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 実践: ESP32-C3 を使用したスマート ライト システムの構築 . . . . . . . . . . . . . . 80

5.3.1 モジュールの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3.2 PWM信号のGPIOの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.3.3 ファームウェアのダウンロードとデバッグインターフェース . . . . . . . . . . . . . 82

5.3.4 RF 設計のガイドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 電源設計のガイドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 ドライバー開発

87

6.1 ドライバ開発プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 ESP32-C3 周辺機器アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 LED ドライバの基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.1 カラースペース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2 LED ドライバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.3 LED 調光 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.4 PWM の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.4 LED 調光ドライバの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 不揮発性ストレージ (NVS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.4.2 LED PWM コントローラ (LEDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.4.3 LED PWMプログラミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 実践: スマート ライト プロジェクトへのドライバーの追加 . . . . . . . . . . . . . . . . . . . . 103

6.5.1 ボタンドライバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5.2 LED 調光ドライバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.6 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

III 無線通信と制御

109

7 Wi-Fiの設定と接続

111

7.1 Wi-Fi の基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.1 Wi-Fi の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.2 IEEE 802.11 の進化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.3 Wi-Fi の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.1.4 Wi-Fi 接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2 Bluetooth の基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.2.1 Bluetooth の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.2 Bluetooth の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.2.3 Bluetooth 接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Wi-Fi ネットワーク構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.3.1 Wi-Fi ネットワーク構成ガイド . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.3.2 ソフトAP . 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 132

7.3.3 SmartConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

7.3.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7.3.5 その他の方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.4 Wi-Fi プログラミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 ESP-IDF の Wi-Fi コンポーネント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 演習: Wi-Fi 接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 演習: スマート Wi-Fi 接続 . . . . . . . . . . . . . . . . . . . . . . . 145
7.5 実践: Smart Light プロジェクトでの Wi-Fi 構成 . . . . . . . . . . . . . . . . . . . 156 7.5.1 Smart Light プロジェクトでの Wi-Fi 接続 . . . . . . . . . . . . . . . . . . . . 156 7.5.2 Smart Wi-Fi 構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8ローカルコントロール

159

8.1 ローカル制御の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1.1 ローカル制御の適用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.2アドバンtagローカルコントロールの es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.3 スマートフォンを介した制御対象デバイスの検出 . . . . . . . . . . 161

8.1.4 スマートフォンとデバイス間のデータ通信 . . . . . . . . 162

8.2 一般的なローカル検出方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

8.2.1 ブロードキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

8.2.2 マルチキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

8.2.3 ブロードキャストとマルチキャストの比較 . . . . . . . . . . . . . . . . 176

8.2.4 ローカル検出のためのマルチキャストアプリケーションプロトコル mDNS . . . . . . . . 176

8.3 ローカルデータ用の共通通信プロトコル . . . . . . . . . . . . . . . . . 179

8.3.1 伝送制御プロトコル (TCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

8.3.2 ハイパーテキスト転送プロトコル (HTTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

8.3.3 ユーザーデーtagRAM プロトコル (UDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

8.3.4 制約付きアプリケーションプロトコル（CoAP） . . . . . . . . . . . . . . . . . . . . . 192

8.3.5 Bluetooth プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.3.6 データ通信プロトコルの概要 . . . . . . . . . . . . . . . . . . 203

8.4 データセキュリティの保証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

8.4.1 トランスポート層セキュリティ (TLS) の概要 . . . . . . . . . . . . . . 207

8.4.2 Daの紹介tagram トランスポート層セキュリティ (DTLS) . . . . . . . 213

8.5 実践: スマート ライト プロジェクトにおけるローカル制御 . . . . . . . . . . . . . . . . . . . . . . 217

8.5.1 Wi-Fi ベースのローカル制御サーバーの作成 . . . . . . . . . . . . . . . . . 217

8.5.2 スクリプトを使用したローカル制御機能の検証 . . . . . . . . . . . 221

8.5.3 Bluetoothベースのローカル制御サーバーの作成 . . . . . . . . . . . . . 222

8.6 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 クラウド コントロール

225

9.1 リモート コントロールの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

9.2 クラウドデータ通信プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

9.2.1 MQTT の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 9.2.2 MQTT の原則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.3 MQTT メッセージ形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.4 プロトコルの比較 . . . . . . . . . . . . . . 233 Linux および Windows での MQTT ブローカーの設定 . . . . . . . . . . . . . . . . . 9.2.5 233 ESP-IDF に基づく MQTT クライアントの設定 . . . . . . . . . . . . . . . . . . . . . 9.2.6 235 MQTT データ セキュリティの確保 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 237 証明書の意味と機能 . . . . . . . . . . . . . . . . . 9.3.1 ローカルでの証明書の生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.2 MQTT ブローカーの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 MQTT クライアントの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 演習: ESP RainMaker によるリモート制御 . . . . . . . . . . . . . . . . . 241 9.4 ESP RainMaker の基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.1 ノードとクラウド バックエンドの通信プロトコル . . . . . . . . . . . . . 243 9.4.2 クライアントとクラウド バックエンド間の通信 . . . . . . . . . . . . . . 244 9.4.3 ユーザー ロール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 9.4.4 基本サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 スマートライトExamp255 RainMaker アプリとサードパーティの統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.7 262 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5

10 スマートフォンアプリ開発

269

10.1 スマートフォンアプリ開発入門 . . . . . . . . . . . . . . . . . . . . . . . 269

10.1.1オーバーview スマートフォンアプリ開発 . . . . . . . . . . . . . . . . . 270

10.1.2 Android プロジェクトの構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

10.1.3 iOS プロジェクトの構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

10.1.4 Android アクティビティのライフサイクル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

10.1.5 iOSのライフサイクル Viewコントローラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

10.2 新しいスマートフォン アプリ プロジェクトを作成する . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

10.2.1 Android 開発の準備 . . . . . . . . . . . . . . . . . . . . . . . . 275

10.2.2 新しい Android プロジェクトの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

10.2.3 MyRainmaker の依存関係の追加 . . . . . . . . . . . . . . . . . . . . 276

10.2.4 Android での権限リクエスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

10.2.5 iOS 開発の準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

10.2.6 新しい iOS プロジェクトの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

10.2.7 MyRainmaker の依存関係の追加 . . . . . . . . . . . . . . . . . . . . 279

10.2.8 iOS での権限リクエスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

10.3 アプリの機能要件の分析 . . . . . . . . . . . . . . . . . . . . . 281

10.3.1 プロジェクトの機能要件の分析 . . . . . . . . . . . . 282

10.3.2 ユーザ管理要件の分析 . . . . . . . . . . . . . . . . . . 282 10.3.3 デバイスのプロビジョニングおよびバインド要件の分析 . . . . . . . . . 283 10.3.4 リモート制御要件の分析 . . . . . . . . . . . . . . . . . . 283 10.3.5 スケジュール要件の分析 . . . . . . . . . . . . . . . . . . . . . . 284 10.3.6 ユーザ センター要件の分析 . . . . . . . . . . . . . . . . . . . 285 10.4 ユーザー管理の開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.1 RainMaker API の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.2 スマートフォン経由の通信の開始 . . . . . . . . . . . . . . . . . . . . . . 286 10.4.3 アカウントの登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 10.4.4 アカウントログイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 10.5 デバイスプロビジョニングの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 10.5.1 デバイスのスキャン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 10.5.2 デバイスの接続 . . . . . . . . . . . . 295 秘密キーの生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.3 298 ノード ID の取得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.4 298 デバイスのプロビジョニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.5 300 デバイス制御の開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6 302 クラウド アカウントへのデバイスのバインド . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.1 303 デバイスのリストの取得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.2 305 デバイス ステータスの取得 . . . . . . . . . . . . . . . . 10.6.3 デバイスステータスの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 10.6.4 デバイスのステータスの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 10.7 スケジュールとユーザセンターの開発 . . . . . . . . . . . . . . . . . . . . . . . . 313 10.7.1 スケジュール機能の実装 . . . . . . . . . . . . . . . . . . . . . . . . 313 10.7.2 ユーザセンターの実装 . . . . . . . . . . . . . 315 その他のクラウド API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7.3 318 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8

11 ファームウェアのアップグレードとバージョン管理

321

11.1 ファームウェアのアップグレード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

11.1.1オーバーview パーティションテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

11.1.2 ファームウェアのブートプロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

11.1.3オーバーview OTAメカニズムの. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

11.2 ファームウェアバージョン管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.1 ファームウェアのマーキング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.2 ロールバックとアンチロールバック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

11.3 実践: 無線 (OTA) 例ampル。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 332

11.3.1 ローカルホスト経由でファームウェアをアップグレードする . . . . . . . . . . . . . . . . . . . . 332

11.3.2 ESP RainMaker によるファームウェアのアップグレード . . . . . . . . . . . . . . . . . 335

11.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

IV 最適化と大量生産

343

12 電力管理と低電力最適化

345

12.1 ESP32-C3 電源管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

12.1.1 動的周波数スケーリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

12.1.2 電源管理の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . 348

12.2 ESP32-C3 低電力モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

12.2.1 モデムスリープモード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

12.2.2 ライトスリープ モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

12.2.3 ディープスリープモード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

12.2.4 異なる電源モードでの電流消費 . . . . . . . . . . . . . 358

12.3 電力管理と低電力デバッグ . . . . . . . . . . . . . . . . . . . . . 359

12.3.1 ログのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

12.3.2 GPIO デバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

12.4 実践: スマートライトプロジェクトにおける電力管理 . . . . . . . . . . . . . . . . 363

12.4.1 電源管理機能の設定 . . . . . . . . . . . . . . . . . . . . . 364

12.4.2 電源管理ロックの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

12.4.3 電力消費の確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

12.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

13 強化されたデバイスセキュリティ機能

369

13.1オーバーview IoT デバイスのデータセキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

13.1.1 IoT デバイスのデータを保護する理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

13.1.2 IoT デバイスのデータセキュリティの基本要件 . . . . . . . . . . . . 371

13.2 データ整合性保護 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

13.2.1 整合性検証方法の概要 . . . . . . . . . . . . . . . 372

13.2.2 ファームウェアデータの整合性検証 . . . . . . . . . . . . . . . . . . . . . . 373

13.2.3例ampル。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 374

13.3 データの機密性の保護 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.1 データ暗号化の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.2 フラッシュ暗号化スキームの概要 . . . . . . . . . . . . . . . . . . . . . 376

13.3.3 フラッシュ暗号化キーの保存 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

13.3.4 フラッシュ暗号化の動作モード . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

13.3.5 フラッシュ暗号化プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

13.3.6 NVS 暗号化の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

13.3.7例ampフラッシュ暗号化とNVS暗号化の概要 . . . . . . . . . . . . 384

13.4 データの正当性の保護 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.1 デジタル署名の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.2オーバーview セキュア ブート スキーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

13.4.3 ソフトウェア セキュア ブートの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 388 13.4.4 ハードウェア セキュア ブートの概要 . . . . . . . . . . . . . . . . . . . . 390 13.4.5 Examp394 実践: 量産におけるセキュリティ機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5 396 フラッシュ暗号化とセキュア ブート . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.1 396 バッチ フラッシュ ツールを使用してフラッシュ暗号化とセキュア ブートを有効にする . . 13.5.2 397 Smart Light プロジェクトでフラッシュ暗号化とセキュア ブートを有効にする . . . 13.5.3 398 要約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6

14 量産に向けたファームウェアの書き込みとテスト

399

14.1 量産におけるファームウェアの焼き付け . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.1 データ パーティションの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.2 ファームウェアの書き込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

14.2 量産テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

14.3 実践: スマートライトプロジェクトにおける量産データ . . . . . . . . . . . . . 404

14.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

15 ESP Insights: リモート監視プラットフォーム

405

15.1 ESP Insights の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

15.2 ESP Insights の使用を開始する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

15.2.1 esp-insights プロジェクトの ESP Insights の使用開始 . . . . . . 409

15.2.2 実行例ampesp-insightsプロジェクトのle . . . . . . . . . . . . . . . . . . . 411

15.2.3 コアダンプ情報の報告 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

15.2.4 関心のあるログのカスタマイズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

15.2.5 再起動理由の報告 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.2.6 カスタムメトリックのレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.3 実践: スマート ライト プロジェクトでの ESP Insights の使用 . . . . . . . . . . . . . . . . 416

15.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

導入
ESP32-C3は、オープンソースのRISC-Vアーキテクチャに基づくシングルコアWi-FiおよびBluetooth 5（LE）マイクロコントローラSoCです。電力、I/O機能、セキュリティの適切なバランスを実現し、接続されたデバイスに最適なコスト効率の高いソリューションを提供します。ESP32-C3ファミリーのさまざまなアプリケーションを紹介するために、Espressifのこの本は、IoTプロジェクト開発と環境設定の基礎から実践的な例まで、AIoTの興味深い旅にあなたを導きます。amp最初の 5 つの章では、IoT、ESP RainMaker、ESP-IDF について説明します。第 6 章と第 XNUMX 章では、ハードウェア設計とドライバー開発について簡単に説明します。学習を進めると、Wi-Fi ネットワークとモバイル アプリを使用してプロジェクトを構成する方法がわかります。最後に、プロジェクトを最適化して大量生産する方法を学びます。
関連分野のエンジニア、ソフトウェア アーキテクト、教師、学生、または IoT に興味のある方であれば、この本はあなたにぴったりです。
コードをダウンロードするには、amp本書で使用されている le は、GitHub の Espressif のサイトから取得しました。IoT 開発の最新情報については、弊社の公式アカウントをフォローしてください。

序文
情報化の世界
インターネットの波に乗って、モノのインターネット (IoT) が華々しくデビューし、デジタル経済における新しいタイプのインフラストラクチャとなりました。このテクノロジーを一般の人々により身近なものにするために、Espressif Systems は、あらゆる分野の開発者が IoT を使用して現代の最も差し迫った問題のいくつかを解決できるというビジョンのもとに取り組んでいます。「すべてのモノのインテリジェント ネットワーク」の世界こそ、私たちが将来期待しているものです。
独自のチップ設計は、そのビジョンの重要な要素です。これは、技術の限界を常に突破しなければならないマラソンです。「ゲームチェンジャー」ESP8266から、Wi-FiとBluetoothr（LE）接続を統合したESP32シリーズ、そしてAIアクセラレーションを搭載したESP32-S3まで、EspressifはAIoTソリューション向け製品の研究開発を決してやめません。IoT開発フレームワークESP-IDF、メッシュ開発フレームワークESP-MDF、デバイス接続プラットフォームESP RainMakerなどのオープンソースソフトウェアを使用して、AIoTアプリケーションを構築するための独立したフレームワークを作成しました。
2022年800月現在、EspressifのIoTチップセットの累計出荷数は32億を超え、Wi-Fi MCU市場をリードし、世界中の膨大な数のコネクテッドデバイスに電力を供給しています。卓越性を追求することで、Espressifのすべての製品は、その高いレベルの統合とコスト効率により大ヒットとなっています。ESP3-C32のリリースは、Espressifの自社開発技術の重要なマイルストーンです。これは、400KBのSRAMを備えたシングルコアの160ビットRISC-VベースのMCUで、2.4MHzで動作できます。5GHz Wi-FiとBluetooth 32（LE）を統合し、長距離サポートを備えています。電力、I/O機能、セキュリティの絶妙なバランスを実現し、コネクテッドデバイスに最適なコスト効率の高いソリューションを提供します。このような強力なESP3-CXNUMXをベースに、詳細なイラストと実用的な例でIoT関連の知識を理解するのに役立つ本です。ampレ。
なぜこの本を書いたのでしょうか?
Espressif Systems は単なる半導体企業ではありません。IoT プラットフォーム企業でもあり、テクノロジー分野で常にブレークスルーとイノベーションを目指しています。同時に、Espressif は自社開発のオペレーティング システムとソフトウェア フレームワークをオープンソース化してコミュニティと共有し、独自のエコシステムを形成しています。エンジニア、メーカー、テクノロジー愛好家は、Espressif 製品をベースに新しいソフトウェア アプリケーションを積極的に開発し、自由にコミュニケーションを取り、経験を共有しています。開発者の魅力的なアイデアは、YouTube や GitHub などのさまざまなプラットフォームでいつでも見ることができます。Espressif 製品の人気に刺激されて、英語、中国語、ドイツ語、フランス語、日本語など 100 を超える言語で、Espressif チップセットをベースにした XNUMX 冊以上の本を出版した著者が増えています。

Espressif の継続的なイノベーションを後押ししているのは、コミュニティ パートナーのサポートと信頼です。「当社は、チップ、オペレーティング システム、フレームワーク、ソリューション、クラウド、ビジネス プラクティス、ツール、ドキュメント、文章、アイデアなどを、現代の生活で最も差し迫った問題に対する人々の答えにさらに関連したものにするよう努めています。これが Espressif の最大の目標であり、道徳的な指針です」と、Espressif の創設者兼 CEO である Teo Swee Ann 氏は述べています。
Espressif は読書とアイデアを重視しています。IoT 技術の継続的なアップグレードにより、エンジニアに対する要求が高まっています。どうすれば、より多くの人々が IoT チップ、オペレーティングシステム、ソフトウェアフレームワーク、アプリケーションスキーム、クラウドサービス製品を迅速に習得できるようにできるでしょうか。諺にあるように、魚を与えるよりも、魚の釣り方を教える方がよいでしょう。ブレインストーミングセッションで、IoT 開発の重要な知識を体系的に整理する本を書くことができると私たちは思いつきました。私たちは意気投合し、すぐに上級エンジニアのグループを集め、組み込みプログラミング、IoT ハードウェア、ソフトウェア開発における技術チームの経験を組み合わせ、この本の出版に貢献しました。執筆の過程で、私たちは客観性と公平性を保ち、繭を脱ぎ捨て、簡潔な表現でモノのインターネットの複雑さと魅力を伝えるよう最善を尽くしました。よくある質問を注意深くまとめ、コミュニティのフィードバックと提案を参考にして、開発プロセスで遭遇した質問に明確に答え、関連する技術者と意思決定者に実用的な IoT 開発ガイドラインを提供しました。
本の構成
本書はエンジニア中心の視点から、IoT プロジェクト開発に必要な知識を段階的に解説しており、以下の 4 つのパートで構成されています。
· 準備（第 1 章）：この部分では、IoT プロジェクト開発の強固な基盤を築くために、IoT のアーキテクチャ、一般的な IoT プロジェクト フレームワーク、ESP RainMakerr クラウド プラットフォーム、開発環境 ESP-IDF を紹介します。
· ハードウェアとドライバーの開発 (第 5 章): ESP6-C32 チップセットに基づいて、この部分では最小限のハードウェア システムとドライバーの開発について詳しく説明し、調光、カラー グレーディング、ワイヤレス通信の制御を実装します。
· 無線通信と制御（第7章）：このパートでは、ESP11-C32チップに基づくインテリジェントなWi-Fi構成スキーム、ローカルおよびクラウド制御プロトコル、デバイスのローカルおよびリモート制御について説明します。また、スマートフォンアプリの開発、ファームウェアのアップグレード、バージョン管理のスキームも提供します。
· 最適化と量産（第 12 章～第 15 章）：このパートは、高度な IoT アプリケーションを対象としており、電源管理、低電力最適化、セキュリティ強化における製品の最適化に重点を置いています。また、量産時のファームウェアの書き込みとテスト、リモート監視プラットフォーム ESP Insights を通じてデバイス ファームウェアの実行状態とログを診断する方法についても紹介します。

ソースコードについて
読者はexを実行できますamp本書のプログラムは、手動でコードを入力するか、本書に付属するソース コードを使用して実行できます。理論と実践の組み合わせを重視しているため、ほぼすべての章に Smart Light プロジェクトに基づく実践セクションを設けています。すべてのコードはオープン ソースです。読者はソース コードをダウンロードして、GitHub の本書に関連するセクションや公式フォーラム esp32.com で議論することができます。本書のオープン ソース コードは、Apache License 2.0 の条件に従います。
著者注
この本は、Espressif Systems が正式に制作し、同社の上級エンジニアによって執筆されました。IoT 関連業界の管理者や研究開発担当者、関連専攻の教師や学生、モノのインターネット分野の愛好家に適しています。この本が、仕事のマニュアル、参考書、ベッドサイドブックとして、良き家庭教師や友人のような存在になることを願います。
本書の編集にあたり、国内外の専門家、学者、技術者の関連研究成果を参考にし、学術規範に則って引用するよう最善を尽くしました。しかし、どうしても抜け漏れが出てしまうため、ここに関係する著者の方々に深く敬意と感謝の意を表します。また、インターネットからの引用もございますので、原著者および出版社に感謝するとともに、すべての情報源を明示できないことをお詫び申し上げます。
質の高い本を制作するために、私たちは社内で何度も議論を重ね、読者や出版社の編集者からの提案やフィードバックを参考にしてきました。ここで、この成功に貢献してくれた皆様のご協力に改めて感謝申し上げます。
最後になりますが、弊社製品の誕生と普及に尽力していただいたEspressifの皆様に、心より感謝申し上げます。
IoT プロジェクトの開発には、幅広い知識が必要です。本書の長さ、著者のレベルと経験の制限により、抜け漏れは避けられません。したがって、専門家と読者の皆様には、誤りを批判し、訂正していただくようお願いいたします。本書についてご提案がありましたら、book@espressif.com までご連絡ください。皆様のフィードバックをお待ちしております。

この本の使い方は？
この本に掲載されているプロジェクトのコードはオープンソース化されています。GitHub リポジトリからダウンロードして、公式フォーラムでご意見やご質問を共有することができます。GitHub: https://github.com/espressif/book-esp32c3-iot-projects フォーラム: https://www.esp32.com/bookc3 本書全体を通じて、以下に示すように強調表示された部分があります。
ソースコードこの本では、理論と実践の組み合わせを重視しており、ほぼすべての章にスマートライトプロジェクトの実践セクションを設けています。対応する手順とソースページは、 tag ソースコード。
注記/ヒント ここには、プログラムのデバッグを成功させるための重要な情報や注意事項が記載されています。これらは、 tag 注意事項またはヒント。
この本で紹介するコマンドのほとんどは、文字「$」でプロンプトが示される Linux で実行されます。コマンドの実行にスーパーユーザー権限が必要な場合は、プロンプトが「#」に置き換えられます。Mac システムのコマンド プロンプトは、セクション 4.2.3 Mac への ESP-IDF のインストールで使用されているように、「%」です。
この本の本文は憲章で印刷され、コードexはampファイル、コンポーネント、関数、変数、コード file 名前、コード ディレクトリ、および文字列は Courier New になります。
ユーザーが入力する必要があるコマンドやテキスト、および「Enter」キーを押して入力できるコマンドは、Courier New 太字で印刷されます。ログとコード ブロックは、水色のボックスで表示されます。
Examp上：
次に、esp-idf/components/nvs flash/nvspartition generator/nvspartitiongen.pyを使用してNVSパーティションバイナリを生成します。 file 開発ホストで次のコマンドを実行します。
$ python $IDF PATH/components/nvs flash/nvs パーティション ジェネレーター/nvs パーティション gen.py –input mass prod.csv –output mass prod.bin –size NVS パーティション サイズ

第1章

導入

に

IoT

20世紀末、コンピュータネットワークと通信技術の台頭により、インターネットは急速に人々の生活に溶け込んでいきました。インターネット技術が成熟するにつれ、モノのインターネット（IoT）という概念が生まれました。文字通り、IoTとはモノがつながるインターネットを意味します。本来のインターネットは空間と時間の制限を打ち破り、「人と人」の距離を縮めましたが、IoTは「モノ」を重要な参加者にし、「人」と「モノ」をより近づけます。近い将来、IoTは情報産業の原動力となるでしょう。
では、モノのインターネットとは何でしょうか?
モノのインターネットは、その意味と範囲が絶えず進化しているため、正確に定義することは困難です。 1995年、ビル・ゲイツは著書「The Road Ahead」で初めてIoTのアイデアを提唱しました。簡単に言えば、IoTは、オブジェクトがインターネットを介して互いに情報を交換できるようにします。 その究極の目標は、「あらゆるもののインターネット」を確立することです。 これはIoTの初期の解釈であり、将来のテクノロジーの空想でもあります。 XNUMX年後、経済とテクノロジーの急速な発展により、空想は現実になりつつあります。 スマートデバイス、スマートホーム、スマートシティ、車両のインターネット、ウェアラブルデバイスから、IoTテクノロジーがサポートする「メタバース」まで、新しい概念が絶えず登場しています。 この章では、モノのインターネットのアーキテクチャの説明から始め、次に最も一般的なIoTアプリケーションであるスマートホームを紹介し、IoTを明確に理解できるようにします。
1.1 IoTのアーキテクチャ
モノのインターネットには、さまざまな業界でさまざまな応用ニーズと形態を持つ複数の技術が関わっています。IoT の構造、主要な技術、応用特性を整理するには、統一されたアーキテクチャと標準技術システムを確立する必要があります。本書では、IoT のアーキテクチャを、認識および制御層、ネットワーク層、プラットフォーム層、アプリケーション層の 4 つの層に簡単に分けています。
知覚と制御層 IoTアーキテクチャの最も基本的な要素である知覚と制御層は、IoTの包括的なセンシングを実現するための中核です。その主な機能は、情報を収集、識別、制御することです。知覚、識別、制御機能を備えたさまざまなデバイスで構成されています。
3

識別、制御、実行を担当し、材料特性、行動傾向、デバイスの状態などのデータを取得して分析する役割を担います。このようにして、IoT は実際の物理世界を認識するようになります。さらに、このレイヤーはデバイスの状態を制御することもできます。
この層で最も一般的なデバイスは、情報の収集と識別に重要な役割を果たすさまざまなセンサーです。センサーは人間の感覚器官に似ています。たとえば、視覚に相当する感光センサー、聴覚に相当する音響センサー、嗅覚に相当するガスセンサー、触覚に相当する圧力と温度に敏感なセンサーなどです。これらすべての「感覚器官」により、オブジェクトは「生きた」ものとなり、物理的世界をインテリジェントに知覚、認識、操作できるようになります。
ネットワーク層 ネットワーク層の主な機能は、認識および制御層から取得したデータを含む情報を特定のターゲットに送信することと、アプリケーション層から発行されたコマンドを認識および制御層に戻すことです。これは、IoT システムのさまざまな層を接続する重要な通信ブリッジとして機能します。モノのインターネットの基本モデルを設定するには、オブジェクトをネットワークに統合するための 2 つの手順、つまりインターネットへのアクセスとインターネットを介した送信が必要です。
インターネットへのアクセス インターネットは人と人の間の相互接続を可能にしますが、モノを大きな家族に含めることはできません。 IoT の出現前は、ほとんどのモノは「ネットワーク化可能」ではありませんでした。 技術の継続的な発展のおかげで、IoT はモノをインターネットに接続し、「人とモノ」や「モノとモノ」の相互接続を実現しました。 インターネット接続を実装する一般的な方法は、有線ネットワーク アクセスと無線ネットワーク アクセスの 2 つです。
有線ネットワーク アクセス方法には、イーサネット、シリアル通信 (RS-232、RS-485 など)、USB などがありますが、無線ネットワーク アクセスは無線通信に依存しており、さらに短距離無線通信と長距離無線通信に分けられます。
短距離無線通信には、ZigBee、Bluetoothr、Wi-Fi、近距離無線通信 (NFC)、無線周波数識別 (RFID) などがあります。長距離無線通信には、拡張マシンタイプ通信 (eMTC)、LoRa、狭帯域モノのインターネット (NB-IoT)、2G、3G、4G、5G などがあります。
インターネットを介した伝送インターネットアクセスのさまざまな方法は、対応する物理的なデータ伝送リンクにつながります。次に、データを送信するためにどの通信プロトコルを使用するかを決定します。インターネット端末と比較して、ほとんどのIoT端末は現在、より少ない
4 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

処理性能、ストレージ容量、ネットワーク速度など、利用可能なリソースによって通信プロトコルの消費量は異なるため、IoT アプリケーションでは占有リソースが少ない通信プロトコルを選択する必要があります。現在広く使用されている通信プロトコルには、Message Queuing Telemetry Transport (MQTT) と Constrained Application Protocol (CoAP) の 2 つがあります。
プラットフォーム層 プラットフォーム層は主に IoT クラウド プラットフォームを指します。すべての IoT 端末がネットワーク化されている場合、それらのデータは IoT クラウド プラットフォームに集約され、計算および保存される必要があります。プラットフォーム層は主に IoT アプリケーションをサポートし、大量のデバイスへのアクセスと管理を容易にします。IoT 端末をクラウド プラットフォームに接続し、端末データを収集し、端末にコマンドを発行してリモート コントロールを実行します。プラットフォーム層は、機器を業界アプリケーションに割り当てる中間サービスとして、IoT アーキテクチャ全体の接続役割を果たし、抽象的なビジネス ロジックと標準化されたコア データ モデルを持ち、デバイスの迅速なアクセスを実現するだけでなく、業界のアプリケーション シナリオのさまざまなニーズを満たす強力なモジュール機能も提供します。プラットフォーム層には主に、デバイス アクセス、デバイス管理、セキュリティ管理、メッセージ通信、監視操作と保守、データ アプリケーションなどの機能モジュールが含まれます。
· デバイスアクセス、端末と IoT クラウド プラットフォーム間の接続と通信を実現します。
· デバイス管理（デバイスの作成、デバイスのメンテナンス、データの変換、データの同期、デバイスの配布などの機能を含む）。
· セキュリティ認証と通信セキュリティの観点から IoT データ伝送のセキュリティを確保するセキュリティ管理。
· メッセージ通信には、端末が IoT クラウド プラットフォームにデータを送信し、IoT クラウド プラットフォームがサーバー側または他の IoT クラウド プラットフォームにデータを送信し、サーバー側が IoT デバイスをリモート制御するという 3 つの伝送方向が含まれます。
· 監視と診断、ファームウェアのアップグレード、オンラインデバッグ、ログサービスなどを含む O&M の監視。
· データの保存、分析、適用を伴うデータアプリケーション。
アプリケーション層 アプリケーション層は、プラットフォーム層からのデータを使用してアプリケーションを管理し、データベースや分析ソフトウェアなどのツールを使用してデータをフィルタリングおよび処理します。生成されたデータは、スマートヘルスケア、スマート農業、スマートホーム、スマートシティなどの実際の IoT アプリケーションに使用できます。
もちろん、IoTのアーキテクチャはより多くのレイヤーに細分化できますが、レイヤーの数に関係なく、基本的な原理は基本的に同じです。学習
第1章 IoT 5の概要

IoT のアーキテクチャに関する知識は、IoT テクノロジーの理解を深め、完全に機能する IoT プロジェクトを構築するのに役立ちます。
1.2 スマートホームにおける IoT アプリケーション
IoT はあらゆる分野に浸透しており、私たちにとって最も関連性の高い IoT アプリケーションはスマート ホームです。多くの従来の家電製品には現在 1.1 つ以上の IoT デバイスが搭載されており、新築住宅の多くは最初から IoT 技術を使用して設計されています。図 XNUMX に、一般的なスマート ホーム デバイスをいくつか示します。
図1.1. 一般的なスマートホームデバイス スマートホームの開発は、スマート製品とスマートホームデバイスに簡単に分けることができます。tage、シーンの相互接続tageとインテリジェントstage、図1.2に示すように。
図1.2. 開発tagスマートホームのe 6 ESP32-C3ワイヤレスアドベンチャー：IoTの包括的なガイド

最初のstagスマートホームとは、従来の住宅とは異なり、IoTデバイスがセンサーで信号を受信し、Wi-Fi、Bluetooth LE、ZigBeeなどの無線通信技術を介してネットワーク化される住宅のことです。ユーザーは、スマートフォンアプリ、音声アシスタント、スマートスピーカーコントロールなど、さまざまな方法でスマート製品を制御できます。tagシーンのつながりに焦点を当てています。tag例えば、開発者はもはや単一のスマート製品の制御ではなく、2つ以上のスマート製品を相互接続し、ある程度自動化し、最終的にカスタムシーンモードを形成することを考えています。例えば、ampたとえば、ユーザーがシーン モード ボタンを押すと、照明、カーテン、エアコンが自動的にプリセットに適応します。もちろん、トリガー条件や実行アクションなどのリンク ロジックがすぐにセットアップされているという前提条件があります。室内温度が 10°C を下回るとエアコンの暖房モードがトリガーされ、朝 7 時に音楽が流れてユーザーを起こし、スマート カーテンが開き、スマート ソケットを介して炊飯器またはトースターが起動し、ユーザーが起きて洗濯を終えると、朝食がすでに用意されているため、仕事に行くのが遅れることはありません。私たちの生活はどれほど便利になったことでしょう。tageはインテリジェンスsに行くtage. スマートホームデバイスへのアクセスが増えると、生成されるデータの種類も増えます。クラウドコンピューティング、ビッグデータ、人工知能の助けを借りて、スマートホームには「よりスマートな脳」が埋め込まれ、ユーザーからの頻繁なコマンドは不要になります。以前のやり取りからデータを収集し、ユーザーの行動パターンと好みを学習して、意思決定のための推奨事項の提供を含むアクティビティを自動化します。現在、ほとんどのスマートホームは、現場の相互接続stage. スマート製品の普及率と知能化が進むにつれ、通信プロトコル間の障壁が取り除かれつつあります。将来、スマートホームは、アイアンマンのAIシステムJarvisのように、ユーザーがさまざまなデバイスを制御し、日常業務を処理するだけでなく、スーパーコンピューティングパワーと思考能力も備えた、本当に「スマート」なものになるでしょう。tagつまり、人類は量的にも質的にもより良いサービスを受けることになります。
第1章 IoT 7の概要

8 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

2つのIoTプロジェクトの紹介と実践
第1章では、IoTのアーキテクチャ、知覚・制御層、ネットワーク層、プラットフォーム層、アプリケーション層の役割と相互関係、スマートホームの開発について紹介しました。しかし、絵を描くことを学ぶときと同じように、理論的な知識を知るだけでは十分ではありません。テクノロジーを本当に習得するには、IoTプロジェクトを実践するために「手を汚す」必要があります。さらに、プロジェクトが量産段階に移行すると、tage、ネットワーク接続、構成、IoTクラウドプラットフォームの相互作用、ファームウェアの管理と更新、量産管理、セキュリティ構成など、より多くの要素を考慮する必要があります。では、完全なIoTプロジェクトを開発する際には、何に注意する必要がありますか？第1章では、スマートホームは最も一般的なIoTアプリケーションシナリオのXNUMXつであり、スマートライトは家庭、ホテル、ジム、病院などで使用できる最も基本的で実用的なアプライアンスのXNUMXつであると述べました。したがって、この本では、スマートライトプロジェクトの構築を出発点として、そのコンポーネントと機能を説明し、プロジェクト開発のガイダンスを提供します。このケースから推論を引き出し、より多くのIoTアプリケーションを作成できることを願っています。
2.1 典型的なIoTプロジェクトの紹介
開発の観点から見ると、IoT プロジェクトの基本機能モジュールは、IoT デバイスのソフトウェアとハ​​ードウェアの開発、クライアント アプリケーションの開発、IoT クラウド プラットフォームの開発に分類できます。基本機能モジュールを明確にすることが重要であり、このセクションでさらに詳しく説明します。
2.1.1 一般的なIoTデバイスの基本モジュール
IoTデバイスのソフトウェアとハ​​ードウェアの開発には、次の基本モジュールが含まれます。データ収集
IoT アーキテクチャの最下層として、知覚および制御層の IoT デバイスは、チップと周辺機器を介してセンサーとデバイスを接続し、データの収集と操作制御を実現します。
9

アカウントのバインドと初期設定 ほとんどのIoTデバイスでは、アカウントのバインドと初期設定は1つの操作プロセスで完了します。たとえば、ample、Wi-Fi ネットワークを構成してデバイスをユーザーに接続します。
IoT クラウド プラットフォームとの相互作用 IoT デバイスを監視および制御するには、デバイスを IoT クラウド プラットフォームに接続し、相互の相互作用を通じてコマンドを発行したり、ステータスを報告したりする必要があります。
デバイス制御 IoT クラウド プラットフォームに接続すると、デバイスはクラウドと通信し、登録、バインド、または制御できます。ユーザーは、IoT クラウド プラットフォームまたはローカル通信プロトコルを介して、スマートフォン アプリで製品のステータスを照会したり、その他の操作を実行したりできます。
ファームウェアのアップグレード IoT デバイスは、メーカーのニーズに基づいてファームウェアのアップグレードも実現できます。クラウドから送信されたコマンドを受信することで、ファームウェアのアップグレードとバージョン管理が実現します。このファームウェア アップグレード機能を使用すると、IoT デバイスの機能を継続的に強化し、欠陥を修正し、ユーザー エクスペリエンスを向上させることができます。
2.1.2 クライアントアプリケーションの基本モジュール
クライアント アプリケーション (スマートフォン アプリなど) には、主に次の基本モジュールが含まれます。
アカウント システムと認証 アカウントとデバイスの認証をサポートします。
デバイス制御 スマートフォンアプリには通常、制御機能が搭載されています。ユーザーは簡単に IoT デバイスに接続し、スマートフォンアプリを通じていつでもどこでもデバイスを管理できます。実際のスマートホームでは、デバイスは主にスマートフォンアプリを通じて制御されており、デバイスのインテリジェントな管理が可能になるだけでなく、人件費も節約できます。したがって、デバイス機能属性制御、シーン制御、スケジュール、リモート制御、デバイス連携などのデバイス制御は、クライアントアプリケーションに必須です。スマートホームユーザーは、個人のニーズに応じてシーンをカスタマイズし、照明、家電、玄関などを制御し、家庭生活をより快適で便利にすることもできます。エアコンの時間を計ったり、リモートでオフにしたり、ドアのロックが解除されると廊下のライトを自動的にオンにしたり、ボタン 1 つで「シアター」モードに切り替えたりできます。
通知クライアント アプリケーションは、IoT デバイスのステータスをリアルタイムで更新し、デバイスに異常が発生したときにアラートを送信します。
10 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

アフターセールス顧客サービス スマートフォンアプリは、製品のアフターセールスサービスを提供し、IoT デバイスの障害や技術的な操作に関連する問題をタイムリーに解決できます。
注目の機能 さまざまなユーザーのニーズを満たすために、シェイク、NFC、GPS などの他の機能が追加されることがあります。 GPS は、場所と距離に応じてシーン操作の精度を設定するのに役立ちます。一方、シェイク機能を使用すると、ユーザーはシェイクすることで特定のデバイスまたはシーンに対して実行されるコマンドを設定できます。
2.1.3 一般的な IoT クラウド プラットフォームの概要
IoT クラウド プラットフォームは、デバイス管理、データ セキュリティ通信、通知管理などの機能を統合したオールインワン プラットフォームです。IoT クラウド プラットフォームは、対象グループとアクセス可能性に応じて、パブリック IoT クラウド プラットフォーム (以下、「パブリック クラウド」) とプライベート IoT クラウド プラットフォーム (以下、「プライベート クラウド」) に分けられます。
パブリッククラウドは通常、プラットフォームプロバイダーによって運営および保守され、インターネットを通じて共有される、企業または個人向けの共有 IoT クラウドプラットフォームを指します。無料または低コストで、Alibaba Cloud、Tencent Cloud、Baidu Cloud、AWS IoT、Google IoT などのオープンパブリックネットワーク全体でサービスを提供します。サポートプラットフォームとして、パブリッククラウドは上流のサービスプロバイダーと下流のエンドユーザーを統合し、新しいバリューチェーンとエコシステムを作成できます。
プライベート クラウドは企業専用に構築されているため、データ、セキュリティ、サービス品質を最適に制御できます。そのサービスとインフラストラクチャは企業によって個別に管理され、サポート ハードウェアとソフトウェアも特定のユーザー専用です。企業は、ビジネスのニーズに合わせてクラウド サービスをカスタマイズできます。現在、一部のスマート ホーム メーカーは、すでにプライベート IoT クラウド プラットフォームを導入し、それに基づいてスマート ホーム アプリケーションを開発しています。
パブリッククラウドとプライベートクラウドにはそれぞれの利点があるtagこれについては後で説明します。
通信接続を実現するには、少なくともデバイス側の組み込み開発、業務サーバー、IoT クラウド プラットフォーム、スマートフォン アプリの完成が必要です。このような大規模なプロジェクトに対応するため、パブリック クラウドでは通常、デバイス側とスマートフォン アプリのソフトウェア開発キットが提供され、プロセスのスピードアップが図られます。パブリック クラウドとプライベート クラウドの両方で、デバイス アクセス、デバイス管理、デバイス シャドウ、運用保守などのサービスが提供されます。
デバイスアクセスIoTクラウドプラットフォームは、プロトコルを使用したデバイスアクセスのインターフェースだけでなく、
第2章 IoTプロジェクトの紹介と実践 11

MQTT、CoAP、HTTPSなど Webソケットだけでなく、偽造されたデバイスや違法なデバイスをブロックするデバイスセキュリティ認証機能も備えており、侵害されるリスクを効果的に軽減します。このような認証は通常、さまざまなメカニズムをサポートしているため、デバイスを大量生産する場合は、選択した認証メカニズムに応じてデバイス証明書を事前に割り当て、デバイスに焼き付ける必要があります。
デバイス管理 IoT クラウド プラットフォームが提供するデバイス管理機能は、メーカーがデバイスのアクティベーション状態やオンライン状態をリアルタイムで監視できるだけでなく、デバイスの追加/削除、取得、グループの追加/削除、ファームウェアのアップグレード、バージョン管理などのオプションも提供します。
デバイスシャドウ IoT クラウドプラットフォームは、各デバイスの永続的な仮想バージョン (デバイスシャドウ) を作成でき、デバイスシャドウの状態は、インターネット伝送プロトコルを介してスマートフォンアプリや他のデバイスで同期および取得できます。デバイスシャドウは、各デバイスの最新の報告された状態と予想される状態を保存し、デバイスがオフラインの場合でも、API を呼び出すことで状態を取得できます。デバイスシャドウは常時接続の API を提供するため、デバイスと対話するスマートフォンアプリの構築が容易になります。
運用と保守 O&M 機能には、次の 3 つの側面が含まれます。 · IoT デバイスと通知に関する統計情報を示します。 · ログ管理により、デバイスの動作、メッセージのフローのアップ/ダウン、メッセージの内容に関する情報を取得できます。 · デバイスのデバッグでは、コマンドの配信、構成の更新、IoT クラウド プラットフォームとデバイス メッセージ間の相互作用の確認をサポートします。
2.2 実践: スマートライトプロジェクト
各章の理論的な紹介の後には、スマート ライト プロジェクトに関連する実践セクションがあり、実践的な経験を積むのに役立ちます。このプロジェクトは、Espressif の ESP32-C3 チップと ESP RainMaker IoT クラウド プラットフォームに基づいており、スマート ライト製品のワイヤレス モジュール ハードウェア、ESP32C3 に基づくスマート デバイス用の組み込みソフトウェア、スマートフォン アプリ、および ESP RainMaker のインタラクションをカバーしています。
ソース コード より良い学習と開発体験のために、この本のプロジェクトはオープンソース化されています。ソース コードは、https://github.com/espressif/book-esp32c3-iot-projects の GitHub リポジトリからダウンロードできます。
12 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

2.2.1 プロジェクトの構造
スマートライトプロジェクトは、32つの部分で構成されています。i. ESP3-CXNUMXをベースにしたスマートライトデバイス。IoTクラウドプラットフォームと対話し、LEDのスイッチ、明るさ、色温度を制御します。amp ii. スマートフォン アプリ (Android および iOS で実行されるタブレット アプリを含む)。スマート ライト製品のネットワーク構成、およびそのステータスの照会と制御を担当します。
iii. ESP RainMaker をベースにした IoT クラウド プラットフォーム。本書では、簡略化のため、IoT クラウド プラットフォームとビジネス サーバーを全体として検討します。ESP RainMaker の詳細については、第 3 章で説明します。
スマートライトプロジェクト構造と IoT のアーキテクチャの対応を図 2.1 に示します。
図2.1. スマートライトプロジェクトの構造
2.2.2 プロジェクトの機能
構造別に分けると、各部の機能は下記の通りです。スマートライトデバイス
· ネットワークの構成と接続。 · スイッチ、明るさ、色温度などの LED PWM 制御。 · 自動化またはシーン制御 (例: タイムスイッチ)。 · フラッシュの暗号化とセキュア ブート。 · ファームウェアのアップグレードとバージョン管理。
第2章 IoTプロジェクトの紹介と実践 13

スマートフォン アプリ · ネットワーク構成とデバイスのバインド。 · スイッチ、明るさ、色温度などのスマート ライト製品の制御。 · 時間スイッチなどの自動化またはシーン設定。 · ローカル/リモート制御。 · ユーザー登録、ログインなど。
ESP RainMaker IoTクラウドプラットフォーム · IoTデバイスへのアクセスを可能にします。 · スマートフォンアプリからアクセス可能なデバイス操作APIを提供します。 · ファームウェアのアップグレードとバージョン管理。
2.2.3ハードウェアの準備
プロジェクトを実践したい場合は、スマートライト、スマートフォン、Wi-Fiルーター、開発環境のインストール要件を満たすコンピューターなどのハードウェアも必要になります。スマートライト
スマートライトは、一般的な白熱電球と同じ形状の新しいタイプの電球です。スマートライトは、コンデンサー降圧安定化電源、ワイヤレスモジュール（ESP32-C3内蔵）、LEDコントローラー、RGB LEDマトリックスで構成されています。電源に接続すると、15 V DC電圧がtagコンデンサの降圧、ダイオード整流、調整後の出力は、LED コントローラと LED マトリックスにエネルギーを供給します。LED コントローラは、一定の間隔で高レベルと低レベルを自動的に送信し、RGB LED マトリックスをクローズ (ライトオン) とオープン (ライトオフ) の間で切り替えて、シアン、黄色、緑、紫、青、赤、白の光を発することができます。ワイヤレス モジュールは、Wi-Fi ルーターに接続し、スマート ライトの状態を受信および報告し、LED を制御するためのコマンドを送信する役割を担います。
図 2.2. シミュレーションされたスマートライト
初期の開発段階ではtage、RGB LEDに接続されたESP32-C3DevKitM-1ボードを使用してスマートライトをシミュレートできます。amp ビーズ（図2.2参照）ですが、
14 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

これはスマート ライトを組み立てる唯一の方法ではないことに注意してください。この本のプロジェクトのハードウェア設計には、ワイヤレス モジュール (ESP32-C3 を内蔵) のみが含まれており、完全なスマート ライト ハードウェア設計ではありません。さらに、Espressif は、オーディオでライトを制御するための ESP32-C3 ベースのオーディオ開発ボード ESP32C3-Lyra も製造しています。このボードには、マイクとスピーカー用のインターフェイスがあり、LED ストリップを制御できます。超低コストで高性能なオーディオ ブロードキャスターやリズム ライト ストリップの開発に使用できます。図 2.3 は、32 個の LED ライトのストリップにリンクされた ESP3-C40Lyra ボードを示しています。
図 2.3. ESP32-C3-Lyra を 40 個の LED ライト ストリップに接続
スマートフォン (Android/iOS) Smart Light プロジェクトでは、スマート ライト製品をセットアップおよび制御するためのスマートフォン アプリの開発を行います。
Wi-Fiルーター Wi-Fiルーターは、有線ネットワーク信号とモバイルネットワーク信号をワイヤレスネットワーク信号に変換し、コンピューター、スマートフォン、タブレット、その他のワイヤレスデバイスがネットワークに接続できるようにします。例：ampつまり、家庭内のブロードバンドは、Wi-Fi ルーターに接続するだけで、Wi-Fi デバイスのワイヤレス ネットワークを実現できます。Wi-Fi ルーターがサポートする主流のプロトコル規格は IEEE 802.11n で、平均 TxRate は 300 Mbps、最大 600 Mbps です。IEEE 802.11b および IEEE 802.11g との下位互換性があります。Espressif の ESP32-C3 チップは IEEE 802.11b/g/n をサポートしているため、シングルバンド (2.4 GHz) またはデュアルバンド (2.4 GHz と 5 GHz) の Wi-Fi ルーターを選択できます。
コンピュータ（Linux/macOS/Windows）開発環境については第4章で紹介します。第2章 IoTプロジェクトの紹介と実践 15

2.2.4 開発プロセス
図2.4. スマートライトプロジェクトの開発手順
ハードウェア設計 IoTデバイスのハードウェア設計はIoTプロジェクトに不可欠です。完全なスマートライトプロジェクトは、amp 主電源で動作します。さまざまなメーカーが製造しています。ampさまざまなスタイルとドライバー タイプがありますが、ワイヤレス モジュールの機能は通常同じです。Smart Ligh プロジェクトの開発プロセスを簡素化するために、この本ではワイヤレス モジュールのハードウェア設計とソフトウェア開発のみを取り上げます。
IoT クラウド プラットフォームの構成 IoT クラウド プラットフォームを使用するには、製品の作成、デバイスの作成、デバイスのプロパティの設定など、バックエンドでプロジェクトを構成する必要があります。
IoT デバイス向け組み込みソフトウェア開発 IoT クラウド プラットフォームへの接続、LED ドライバーの開発、ファームウェアのアップグレードなど、Espressif のデバイス側 SDK である ESP-IDF を使用して期待される機能を実装します。
スマートフォンアプリ開発 AndroidおよびiOSシステム向けのスマートフォンアプリを開発し、ユーザー登録やログイン、デバイス制御などの機能を実現します。
IoT デバイスの最適化 IoT デバイス機能の基本的な開発が完了したら、電力の最適化などの最適化タスクに移ることができます。
量産テスト 機器機能テスト、エージングテスト、RF テストなど、関連規格に従って量産テストを実行します。
上記の手順にもかかわらず、スマートライトプロジェクトでは、異なるタスクを同時に実行することもできるため、必ずしもこのような手順に従う必要はありません。たとえば、ampたとえば、組み込みソフトウェアとスマートフォン アプリは並行して開発できます。IoT デバイスの最適化や量産テストなど、一部の手順を繰り返す必要がある場合もあります。
16 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

2.3 要約
この章では、まず IoT プロジェクトの基本コンポーネントと機能モジュールについて詳しく説明し、次に Smart Light の実践事例を紹介して、その構造、機能、ハードウェアの準備、開発プロセスについて説明しました。読者は実践から推論を導き出し、将来 IoT プロジェクトを最小限のミスで実行することに自信を持つことができます。
第2章 IoTプロジェクトの紹介と実践 17

18 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

第3章

導入

に

超能力

レインメーカー

モノのインターネット (IoT) は人々の生活を変える無限の可能性を提供しますが、IoT エンジニアリングの開発には多くの課題が伴います。パブリック クラウドを使用すると、端末メーカーは次のソリューションを通じて製品機能を実装できます。
ソリューションプロバイダーのクラウドプラットフォームをベースとするこの方法では、端末メーカーは製品のハードウェアを設計し、提供された通信モジュールを使用してハードウェアをクラウドに接続し、ガイドラインに従って製品の機能を構成するだけで済みます。これは、サーバー側とアプリケーション側の開発、運用と保守（O＆M）が不要になるため、効率的なアプローチです。端末メーカーは、クラウドの実装を考慮することなく、ハードウェアの設計に集中できます。ただし、このようなソリューション（デバイスファームウェアやアプリなど）は一般にオープンソースではないため、製品機能はプロバイダーのクラウドプラットフォームによって制限され、カスタマイズできません。一方、ユーザーとデバイスのデータもクラウドプラットフォームに属します。
クラウド製品をベースにしたこのソリューションでは、端末メーカーはハードウェア設計を完了した後、パブリッククラウドが提供する1つ以上のクラウド製品を使用してクラウド機能を実装するだけでなく、ハードウェアとクラウドを連携させる必要があります。例：ample、Amazonに接続する Web AWS（AWS）では、端末メーカーはAmazon API Gateway、AWS IoT Core、AWS LambdaなどのAWS製品を使用して、デバイスアクセス、リモートコントロール、データストレージ、ユーザー管理などの基本機能を有効にする必要があります。端末メーカーは、深い理解と豊富な経験に基づいてクラウド製品を柔軟に使用および構成する必要があるだけでなく、初期および後続のサービスの構築と保守コストを考慮する必要があります。tagこれは会社のエネルギーとリソースに大きな課題をもたらします。
パブリッククラウドと比較すると、プライベートクラウドは通常、特定のプロジェクトや製品向けに構築されます。プライベートクラウド開発者には、プロトコル設計とビジネスロジックの実装において最高レベルの自由が与えられます。端末メーカーは、製品や設計スキームを自由に作成し、ユーザーデータを簡単に統合して強化することができます。パブリッククラウドの高いセキュリティ、スケーラビリティ、信頼性と、先進的なクラウドテクノロジーを組み合わせることで、tagプライベートクラウドの先駆者として、EspressifはESPを立ち上げました
19

RainMaker は、Amazon クラウドをベースに高度に統合されたプライベート クラウド ソリューションです。ユーザーは、AWS アカウントだけで ESP RainMaker をデプロイし、プライベート クラウドを構築できます。
3.1 ESP RainMaker とは何ですか?
ESP RainMaker は、複数の成熟した AWS 製品で構築された完全な AIoT プラットフォームです。デバイスのクラウド アクセス、デバイスのアップグレード、バックエンド管理、サードパーティ ログイン、音声統合、ユーザー管理など、量産に必要なさまざまなサービスを提供します。AWS が提供する Serverless Application Repository (SAR) を使用すると、端末メーカーは ESP RainMaker を AWS アカウントにすばやくデプロイできるため、時間効率が良く、操作も簡単です。Espressif によって管理および保守されている ESP RainMaker が使用する SAR は、開発者がクラウドのメンテナンス コストを削減し、AIoT 製品の開発を加速して、安全で安定したカスタマイズ可能な AIoT ソリューションを構築するのに役立ちます。図 3.1 は、ESP RainMaker のアーキテクチャを示しています。
図3.1. ESP RainMakerのアーキテクチャ
Espressif の ESP RainMaker パブリック サーバーは、ESP 愛好家、メーカー、教育者全員がソリューション評価のために無料で利用できます。開発者は、Apple、Google、または GitHub アカウントでログインし、独自の IoT アプリケーション プロトタイプをすばやく構築できます。パブリック サーバーは Alexa と Google Home を統合し、Alexa Skill と Google Actions でサポートされている音声制御サービスを提供します。セマンティック認識機能もサードパーティによって提供されています。RainMaker IoT デバイスは特定のアクションにのみ応答します。サポートされている音声コマンドの完全なリストについては、サードパーティ プラットフォームを確認してください。さらに、Espressif は、ユーザーがスマートフォンから製品を制御できるように、パブリック RainMaker アプリを提供しています。 20 ESP32-C3 ワイヤレス アドベンチャー: IoT の包括的なガイド

3.2 ESP RainMakerの実装
図 3.2 に示すように、ESP RainMaker は XNUMX つの部分で構成されています。 · Claiming Service: RainMaker デバイスが証明書を動的に取得できるようにします。 · RainMaker Cloud (クラウド バックエンドとも呼ばれます) は、メッセージのフィルタリング、ユーザー管理、データ ストレージ、サードパーティ統合などのサービスを提供します。 · RainMaker Agent: RainMaker デバイスが RainMaker Cloud に接続できるようにします。 · RainMaker Client (RainMaker App または CLI スクリプト) は、プロビジョニング、ユーザーの作成、デバイスの関連付けと制御などを行います。
図3.2. ESP RainMakerの構造
ESP RainMakerは、RainMaker SDKなど、製品開発と量産のための完全なツールセットを提供します。
RainMaker SDK は ESP-IDF に基づいており、デバイス側エージェントのソースコードとファームウェア開発用の関連 C API を提供します。開発者はアプリケーションロジックを記述するだけでよく、残りは RainMaker フレームワークに任せることができます。C API の詳細については、https://bookc3.espressif.com/rm/c-api-reference をご覧ください。 RainMaker アプリ RainMaker アプリのパブリックバージョンを使用すると、開発者はデバイスのプロビジョニングを完了し、デバイス (スマート照明製品など) の状態を制御および照会できます。iOS と Android の両方のアプリストアで入手できます。詳細については、第 10 章を参照してください。 REST API REST API を使用すると、ユーザーは RainMaker アプリに似た独自のアプリケーションを構築できます。詳細については、https://swaggerapis.rainmaker.espressif.com/ をご覧ください。
第3章 ESP RainMaker 21の紹介

Python API RainMaker SDK に付属する Python ベースの CLI は、スマートフォンの機能に類似したすべての機能を実装するために提供されています。Python API の詳細については、https://bookc3.espressif.com/rm/python-api-reference をご覧ください。
管理 CLI より高いレベルのアクセスを持つ管理 CLI は、ESP RainMaker プライベート展開でデバイス証明書を一括生成するために提供されます。
3.2.1 クレームサービス
RainMaker デバイスとクラウド バックエンド間のすべての通信は、MQTT+TLS を介して実行されます。ESP RainMaker のコンテキストでは、「クレーム」とは、デバイスがクレーム サービスから証明書を取得してクラウド バックエンドに接続するプロセスです。クレーム サービスはパブリック RainMaker サービスにのみ適用され、プライベート展開の場合は、デバイス証明書を Admin CLI から一括生成する必要があることに注意してください。ESP RainMaker は、次の 3 種類のクレーム サービスをサポートしています: セルフ クレーム
デバイス自体は、インターネットに接続した後、eFuse に事前にプログラムされた秘密キーを通じて証明書を取得します。ホスト駆動型クレーム 証明書は、RainMaker アカウントを使用して開発ホストから取得されます。アシスト型クレーム 証明書は、プロビジョニング中にスマートフォン アプリケーションを介して取得されます。
3.2.2 レインメーカーエージェント
図3.3. RainMaker SDKの構造 RainMakerエージェントの主な機能は、接続を提供し、アプリケーション層がアップリンク/ダウンリンククラウドデータを処理できるように支援することです。これは、RainMaker SDK 22 ESP32-C3ワイヤレスアドベンチャー：IoTの包括的なガイドを通じて構築されます。

RTOS、NVS、MQTTなどのESP-IDFコンポーネントを使用して、実績のあるESP-IDFフレームワークに基づいて開発されています。図3.3は、RainMaker SDKの構造を示しています。
RainMaker SDK には 2 つの主要な機能が含まれています。
繋がり
i. デバイス証明書を取得するために Claiming Service と協力する。
ii. 安全な MQTT プロトコルを使用してクラウド バックエンドに接続し、リモート接続を提供し、リモート制御、メッセージ レポート、ユーザー管理、デバイス管理などを実装します。デフォルトでは ESP-IDF の MQTT コンポーネントを使用し、他のプロトコル スタックとインターフェイスするための抽象化レイヤーを提供します。
iii. Wi-Fi 接続とプロビジョニング用の Wi-Fi プロビジョニング コンポーネント、OTA アップグレード用の ESP https OTA コンポーネント、およびローカル デバイスの検出と接続用の ESP ローカル コントロール コンポーネントを提供します。これらの目的はすべて、簡単な構成で達成できます。
データ処理
i. Claiming Service によって発行されたデバイス証明書と RainMaker の実行時に必要なデータを、デフォルトで nvs フラッシュ コンポーネントによって提供されるインターフェイスを使用して保存し、開発者が直接使用できるように API を提供します。
ii. コールバックメカニズムを使用してアップリンク/ダウンリンクのクラウドデータを処理し、開発者が簡単に処理できるようにアプリケーション層へのデータを自動的にブロック解除します。例：ampさらに、RainMaker SDK は、TSL (Thing Specific Language) データを確立するための豊富なインターフェイスを提供します。これは、IoT デバイスを記述するための TSL モデルを定義し、タイミング、カウントダウン、音声制御などの機能を実装するために必要です。タイミングなどの基本的なインタラクティブ機能については、RainMaker SDK は、必要なときに簡単に有効にできる開発不要のソリューションを提供します。次に、RainMaker エージェントがデータを直接処理し、関連する MQTT トピックを介してクラウドに送信し、コールバック メカニズムを介してクラウド バックエンドでデータの変更をフィードバックします。
3.2.3 クラウドバックエンド
クラウドバックエンドはAWS Serverless Computing上に構築されており、AWS Cognito（アイデンティティ管理システム）、Amazon API Gateway、AWS Lambda（サーバーレスコンピューティングサービス）、Amazon DynamoDB（NoSQLデータベース）、AWS IoT Core（MQTTアクセスとルールフィルタリングを提供するIoTアクセスコア）、Amazon Simple Email Service（SESシンプルメールサービス）、Amazon CloudFront（高速配信ネットワーク）、Amazon Simple Queue Service（SQSメッセージキューイング）、Amazon S3（バケットストレージサービス）を通じて実現され、スケーラビリティとセキュリティの最適化を目指しています。ESP RainMakerを使用すると、開発者はクラウドでコードを記述することなくデバイスを管理できます。デバイスから報告されたメッセージは、
第3章 ESP RainMaker 23の紹介

アプリケーションクライアントまたはその他のサードパーティサービス。表 3.1 は、クラウドバックエンドで使用される AWS クラウド製品と機能を示しています。さらに開発中の製品と機能もあります。
表3.1. クラウドバックエンドで使用されるAWSクラウド製品と機能

RainMaker が使用する AWS クラウド製品

関数

AWS コグニート

ユーザー資格情報の管理とサードパーティのログインのサポート

AWS ラムダ

クラウドバックエンドのコアビジネスロジックの実装

Amazon Timestream 時系列データの保存

Amazon DynamoDB 顧客の個人情報の保存

AWS IoT コア

MQTT通信をサポート

アマゾン

メール送信サービスの提供

Amazon CloudFront バックエンドの管理を高速化 webサイトアクセス

アマゾンSQS

AWS IoT Coreからのメッセージの転送

3.2.4 RainMakerクライアント
App や CLI などの RainMaker クライアントは、REST API を介してクラウド バックエンドと通信します。REST API の詳細情報と手順については、Espressif が提供する Swagger ドキュメントを参照してください。RainMaker のモバイル アプリケーション クライアントは、iOS と Android の両方のシステムで使用できます。デバイスのプロビジョニング、制御、共有のほか、カウントダウン タスクの作成と有効化、サードパーティ プラットフォームへの接続が可能です。デバイスから報告された構成に従って UI とアイコンを自動的に読み込み、デバイスの TSL を完全に表示できます。
例えばampスマートライトがRainMaker SDK提供のex上に構築されている場合ampプロビジョニングが完了すると、電球のアイコンとUIが自動的に読み込まれます。ユーザーはインターフェースを通じてライトの色と明るさを変更したり、Alexa Smart Home SkillまたはGoogle Smart Home ActionsをESP RainMakerアカウントにリンクすることでサードパーティの制御を実現したりできます。図3.4は、電球のアイコンとUIの例を示しています。ampAlexa、Google Home、ESP RainMaker アプリでそれぞれ電球の点灯/消灯を制御します。

24 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

(a) 例ampル – アレクサ

(b)例ample – Google ホーム

(c) 例ample – ESP レインメーカー
図3.4.例ampAlexa、Google Home、ESP RainMaker アプリの電球アイコンと UI の例
3.3 実践: ESP RainMaker を使った開発のポイント
デバイス ドライバー レイヤーが完成すると、開発者は、RainMaker SDK によって提供される API を使用して TSL モデルの作成とダウンリンク データの処理を開始し、製品の定義と要件に基づいて ESP RainMaker 基本サービスを有効にできるようになります。
第3章 ESP RainMaker 25の紹介

この本のセクション 9.4 では、RainMaker での LED スマート ライトの実装について説明します。デバッグ中、開発者は RainMaker SDK の CLI ツールを使用してスマート ライトと通信できます (または Swagger から REST API を呼び出します)。
第 10 章では、スマートフォン アプリケーションの開発における REST API の使用について詳しく説明します。LED スマート ライトの OTA アップグレードについては、第 11 章で説明します。開発者が ESP Insights リモート監視を有効にしている場合は、ESP RainMaker 管理バックエンドに ESP Insights データが表示されます。詳細は第 15 章で説明します。
ESP RainMaker はプライベート展開をサポートしますが、パブリック RainMaker サーバーとは次の点で異なります。
クレーム サービス プライベート展開で証明書を生成するには、クレームではなく RainMaker Admin CLI を使用する必要があります。パブリック サーバーでは、ファームウェア アップグレードを実装するために開発者に管理者権限を与える必要がありますが、商用展開ではこれは望ましくありません。したがって、自己クレームに対して個別の認証サービスを提供したり、ホスト駆動型またはアシスト型のクレームに対して管理者権限を提供したりすることはできません。
電話アプリ プライベート展開では、アカウント システムが相互運用できないようにするために、アプリケーションを個別に構成およびコンパイルする必要があります。
サードパーティのログインと音声統合 開発者は、サードパーティのログイン、および Alexa スキルと Google 音声アシスタントの統合を有効にするために、Google および Apple 開発者アカウントを介して個別に構成する必要があります。
ヒント クラウド展開の詳細については、https://customer.rainmaker.espressif.com をご覧ください。ファームウェアに関しては、パブリックサーバーからプライベートサーバーへの移行ではデバイス証明書の置き換えのみが必要なため、移行効率が大幅に向上し、移行と二次デバッグのコストが削減されます。
3.4 ESP RainMakerの機能
ESP RainMaker の機能は、主にユーザー管理、エンド ユーザー、管理者の 3 つの側面を対象としています。特に明記されていない限り、すべての機能はパブリック サーバーとプライベート サーバーの両方でサポートされます。
3.4.1ユーザー管理
ユーザー管理機能により、エンドユーザーは登録、ログイン、パスワードの変更、パスワードの取得などを行うことができます。
26 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

登録とログイン RainMaker でサポートされている登録とログインの方法は次のとおりです: · メール ID + パスワード · 電話番号 + パスワード · Google アカウント · Apple アカウント · GitHub アカウント (パブリック サーバーのみ) · Amazon アカウント (プライベート サーバーのみ)
注意: Google/Amazon を使用してサインアップすると、ユーザーのメール アドレスが RainMaker と共有されます。Apple を使用してサインアップすると、Apple が RainMaker サービス専用にユーザーに割り当てたダミー アドレスが共有されます。Google、Apple、または Amazon アカウントで初めてサインインするユーザーに対して、RainMaker アカウントが自動的に作成されます。
パスワードの変更 メール ID/電話番号ベースのログインにのみ有効です。パスワードを変更すると、他のすべてのアクティブなセッションはログアウトされます。AWS Cognito の動作に従って、ログアウトしたセッションは最大 1 時間アクティブなままになります。
パスワードを取得します。電子メール ID/電話番号に基づくログインにのみ有効です。
3.4.2 エンドユーザー機能
エンド ユーザーに公開される機能には、ローカルおよびリモートの制御と監視、スケジュール設定、デバイスのグループ化、デバイスの共有、プッシュ通知、サードパーティの統合などがあります。
リモート制御と監視 · 1 台またはすべてのデバイスの構成、パラメータ値、接続ステータスを照会します。 · 単一または複数のデバイスのパラメータを設定します。
ローカル制御と監視 ローカル制御を行うには、携帯電話とデバイスを同じネットワークに接続する必要があります。
スケジュール · ユーザーは特定の時間に特定のアクションを事前設定します。 · スケジュールの実行中、デバイスにインターネット接続は必要ありません。 · 単一または複数のデバイスに対して 1 回または繰り返し (日数を指定して) 実行します。
デバイスのグループ化 複数レベルの抽象的なグループ化をサポート グループ メタデータを使用してホーム ルーム構造を作成できます。
第3章 ESP RainMaker 27の紹介

デバイスの共有 1 台以上のデバイスを 1 人以上のユーザーと共有できます。
プッシュ通知 エンドユーザーは、次のようなイベントのプッシュ通知を受け取ります。 · 新しいデバイスの追加/削除 · デバイスのクラウドへの接続 · デバイスのクラウドからの切断 · デバイスの共有リクエストの作成/承認/拒否 · デバイスから報告されたアラートメッセージ
サードパーティの統合 Alexa および Google Voice Assistant がサポートされており、ライト、スイッチ、ソケット、ファン、温度センサーなどの RainMaker デバイスを制御できます。
3.4.3 管理者機能
管理者機能により、管理者はデバイス登録、デバイスのグループ化、OTAアップグレードを実装し、 view 統計と ESP Insights データ。
デバイス登録 デバイス証明書を生成し、管理 CLI を使用して登録します (プライベート サーバーのみ)。
デバイスのグループ化 デバイス情報に基づいて抽象グループまたは構造化グループを作成します (プライベート サーバーのみ)。
無線 (OTA) アップグレード バージョンとモデルに基づいて、1 つ以上のデバイスまたはグループにファームウェアをアップロードします。OTA ジョブを監視、キャンセル、またはアーカイブします。
View 統計 View統計情報には以下が含まれます: · デバイス登録 (管理者が登録した証明書) · デバイスのアクティベーション (初めて接続されたデバイス) · ユーザーアカウント · ユーザーとデバイスの関連付け
View ESPインサイトデータ View利用可能な ESP Insights データには、次のものが含まれます。 · エラー、警告、カスタム ログ · クラッシュ レポートと分析 · 再起動の理由 · メモリ使用量、RSSI などのメトリック · カスタム メトリックと変数
28 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

3.5 要約
この章では、パブリック RainMaker デプロイメントとプライベート デプロイメントの主な違いをいくつか紹介しました。Espressif が立ち上げたプライベート ESP RainMaker ソリューションは、信頼性と拡張性に優れています。ESP32 シリーズ チップはすべて AWS に接続され、適応されているため、コストが大幅に削減されます。開発者は AWS クラウド製品について学習することなく、プロトタイプの検証に集中できます。また、ESP RainMaker の実装と機能、およびプラットフォームを使用した開発の重要なポイントについても説明しました。
Android用のESP RainMakerをダウンロードするにはスキャンしてください iOS用のESP RainMakerをダウンロードするにはスキャンしてください
第3章 ESP RainMaker 29の紹介

30 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

第4章 開発環境の設定
この章では、ESP32-C3の公式ソフトウェア開発フレームワークであるESP-IDFに焦点を当てます。さまざまなオペレーティングシステムで環境を設定する方法を説明し、ESP-IDFのプロジェクト構造とビルドシステム、および関連する開発ツールの使用方法を紹介します。次に、exのコンパイルと実行プロセスを紹介します。ampleプロジェクトでは、各sの出力ログの詳細な説明を提供しながらtage.
4.1 ESP-IDF終了view
ESP-IDF（Espressif IoT開発フレームワーク）は、Espressif Technologyが提供するワンストップIoT開発フレームワークです。主な開発言語としてC/C++を使用し、Linux、Mac、Windowsなどの主流のオペレーティングシステムでのクロスコンパイルをサポートしています。ampこの本に含まれるプログラムは、ESP-IDFを使用して開発されており、次の機能を提供します。 · SoCシステムレベルドライバー。ESP-IDFには、ESP32、ESP32-S2、ESP32-C3、
およびその他のチップ。これらのドライバには、ペリフェラル低レベル（LL）ライブラリ、ハードウェア抽象化レイヤー（HAL）ライブラリ、RTOSサポート、上位層ドライバソフトウェアなどが含まれます。 · 必須コンポーネント。ESP-IDFには、IoT開発に必要な基本コンポーネントが組み込まれています。これには、HTTPやMQTTなどの複数のネットワークプロトコルスタック、動的周波数変調を備えた電源管理フレームワーク、フラッシュ暗号化やセキュアブートなどの機能が含まれます。 · 開発および製造ツール。ESP-IDFは、CMakeに基づくビルドシステム、GCCに基づくクロスコンパイルツールチェーン、JTAG OpenOCD などに基づくデバッグ ツール。ESP-IDF コードは主に Apache 2.0 オープン ソース ライセンスに準拠していることは注目に値します。ユーザーは、オープン ソース ライセンスの条件を遵守しながら、個人用または商用のソフトウェアを制限なく開発できます。さらに、ユーザーには永久的な特許ライセンスが無料で付与され、ソース コードに加えられた変更をオープン ソース化する義務はありません。
31

図4.1.

ビルド、フラッシュ、デバッグ

開発と量産のためのツール

4.1.1 ESP-IDFのバージョン
ESP-IDF コードは、オープンソース プロジェクトとして GitHub でホストされています。現在、v3、v4、v5 の 4.2 つのメジャー バージョンが利用可能です。各メジャー バージョンには通常、v4.3、v30 などのさまざまなサブバージョンが含まれています。Espressif Systems は、リリースされたサブバージョンごとに、バグ修正とセキュリティ パッチの 4.3.1 か月間のサポートを保証します。したがって、v4.2.2、v4.1 などのサブバージョンのリビジョンも定期的にリリースされます。表 XNUMX は、Espressif チップのさまざまな ESP-IDF バージョンのサポート状況を示しており、それらがプレリリース版であるかどうかを示しています。view stage（事前のサポートを提供view バージョンによっては、特定の機能やドキュメントが欠落している場合があります)、または公式にサポートされていない場合があります。

表4.1. EspressifチップのさまざまなESP-IDFバージョンのサポート状況

シリーズ ESP32 ESP32-S2 ESP32-C3 ESP32-S3 ESP32-C2 ESP32-H2

v4.1 をサポート

v4.2 対応 対応

v4.3 対応 対応 対応

v4.4 サポート済み サポート済み サポート済み
前view

v5.0 サポート サポート サポート サポート サポート プレview

32 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

メジャーバージョンの反復には、フレームワーク構造の調整やコンパイルシステムの更新が含まれることがよくあります。たとえば、ampたとえば、v3.* から v4.* への主な変更点は、ビルド システムが Make から CMake に段階的に移行したことです。一方、マイナー バージョンの反復では、通常、新しい機能の追加や新しいチップのサポートが伴います。
安定バージョンと GitHub ブランチの関係を区別して理解することが重要です。v*.* または v*.*.* というラベルの付いたバージョンは、Espressif による完全な内部テストに合格した安定バージョンを表します。修正されると、同じバージョンのコード、ツール チェーン、リリース ドキュメントは変更されません。ただし、GitHub ブランチ (例: release/v4.3 ブランチ) では、頻繁にコードがコミットされ、毎日コミットされることもよくあります。そのため、同じブランチの XNUMX つのコード スニペットが異なる場合があり、開発者はそれに応じてコードを迅速に更新する必要があります。
4.1.2 ESP-IDF Gitワークフロー
Espressif は、ESP-IDF 用の特定の Git ワークフローに従います。概要は次のとおりです。
· 新しい変更は、メインの開発ブランチとして機能するマスターブランチで行われます。マスターブランチのESP-IDFバージョンには常に-devが付いています。 tag 現在開発中であることを示すために、v4.3-devのように表示されます。マスターブランチの変更は、最初にviewEspressif の内部リポジトリで作成およびテストされ、自動テストが完了した後に GitHub にプッシュされます。
· 新しいバージョンがマスターブランチで機能開発を完了し、ベータテストに入るための基準を満たすと、リリース/ v4.3などの新しいブランチに移行します。さらに、この新しいブランチは tagプレリリース版として、v4.3-beta1のように公開されています。開発者はGitHubプラットフォームを参照して、ブランチの完全なリストにアクセスし、 tags ESP-IDF の場合。ベータ版 (プレリリース版) には、既知の問題がまだ多数ある可能性があることに注意してください。ベータ版は継続的にテストされるため、バグ修正はこのバージョンとマスター ブランチの両方に同時に追加されます。一方、マスター ブランチでは、次のバージョンに向けて新機能の開発がすでに開始されている可能性があります。テストがほぼ完了すると、ブランチにリリース候補 (rc) ラベルが追加され、v4.3-rc1 など、正式リリースの候補であることを示します。この時点で、tage、ブランチはプレリリースバージョンのままです。
· 重大なバグが発見または報告されなかった場合、プレリリース バージョンは最終的にメジャー バージョン ラベル (例: v5.0) またはマイナー バージョン ラベル (例: v4.3) を受け取り、公式リリース バージョンとなり、リリース ノート ページに記載されます。その後、このバージョンで特定されたバグはリリース ブランチで修正されます。手動テストが完了すると、ブランチにはバグ修正バージョン ラベル (例: v4.3.2) が割り当てられ、リリース ノート ページにも反映されます。
第4章 開発環境の設定 33

4.1.3 適切なバージョンの選択
ESP-IDF はバージョン v32 から ESP3-C4.3 のサポートを正式に開始し、本書執筆時点では v4.4 はまだ正式リリースされていないため、本書で使用しているバージョンは v4.3.2 の改訂版である v4.3 です。ただし、本書をお読みいただく時点では、すでに v4.4 以降のバージョンが利用可能になっている可能性がありますので、ご注意ください。バージョンを選択する際には、次の点を推奨します。
· 初心者開発者には、安定したv4.3バージョンまたはその改訂版を選択することをお勧めします。これは、exampこの本で使用されているバージョン。
· 大量生産の場合は、最新の技術サポートを受けるために、最新の安定バージョンを使用することをお勧めします。
· 新しいチップを試したり、新しい製品機能を調べたりする場合は、マスター ブランチを使用してください。最新バージョンには最新の機能がすべて含まれていますが、既知または未知のバグが存在する可能性があることに注意してください。
· 使用している安定バージョンに必要な新機能が含まれていない場合、マスター ブランチに関連するリスクを最小限に抑えたい場合は、release/v4.4 ブランチなどの対応するリリース ブランチの使用を検討してください。Espressif の GitHub リポジトリは、最初に release/v4.4 ブランチを作成し、その後、すべての機能開発とテストを完了した後、このブランチの特定の履歴スナップショットに基づいて安定した v4.4 バージョンをリリースします。
4.1.4オーバーview ESP-IDF SDKディレクトリ
ESP-IDF SDKは、esp-idfと.espressifという2つのメインディレクトリで構成されています。前者にはESP-IDFリポジトリのソースコードが含まれています。 files とコンパイル スクリプトが格納され、後者は主にコンパイル ツール チェーンとその他のソフトウェアを格納します。これら 2 つのディレクトリに精通すると、開発者は利用可能なリソースをより有効に活用し、開発プロセスを高速化できます。ESP-IDF のディレクトリ構造を次に示します。
（１）ESP-IDFリポジトリコードディレクトリ（/esp/esp-idf）（図1参照）。
a. コンポーネントディレクトリコンポーネント
このコアディレクトリには、ESP-IDFの数多くの重要なソフトウェアコンポーネントが統合されています。このディレクトリ内のコンポーネントに依存せずにプロジェクトコードをコンパイルすることはできません。これには、さまざまなEspressifチップのドライバサポートが含まれています。周辺機器用のLLライブラリとHALライブラリインターフェイスから、上位レベルのドライバと仮想 File システム（VFS）層のサポートにより、開発者は開発ニーズに応じてさまざまなレベルで適切なコンポーネントを選択できます。ESP-IDFは、TCP / IP、HTTP、MQTTなどの複数の標準ネットワークプロトコルスタックもサポートしています。 Webソケットなど。開発者は、ソケットなどの使い慣れたインターフェースを利用してネットワークアプリケーションを構築できます。コンポーネントは、
34 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

図4.2. ESP-IDFリポジトリコードディレクトリ
非常に多くの機能を備えており、アプリケーションに簡単に統合できるため、開発者はビジネスロジックのみに集中できます。一般的なコンポーネントには次のものがあります。 · ドライバ: このコンポーネントには、さまざまな Espressif 用の周辺ドライバプログラムが含まれています。
GPIO、I2C、SPI、UART、LEDC（PWM）などのチップシリーズ。このコンポーネントの周辺ドライバプログラムは、チップに依存しない抽象インターフェースを提供します。各周辺機器には共通のヘッダーがあります。 file (gpio.h など)、さまざまなチップ固有のサポートの質問に対応する必要がなくなります。 · esp_wifi: Wi-Fi は特別な周辺機器として、別のコンポーネントとして扱われます。これには、さまざまな Wi-Fi ドライバー モードの初期化、パラメーター構成、イベント処理などの複数の API が含まれます。このコンポーネントの特定の機能は、静的リンク ライブラリの形式で提供されます。ESP-IDF は、使いやすさのために包括的なドライバー ドキュメントも提供します。
第4章 開発環境の設定 35

· freertos: このコンポーネントには、完全な FreeRTOS コードが含まれています。このオペレーティング システムの包括的なサポートを提供するほか、Espressif はデュアル コア チップのサポートも拡張しています。ESP32 や ESP32-S3 などのデュアル コア チップの場合、ユーザーは特定のコアでタスクを作成できます。
b. ドキュメントディレクトリ docs
このディレクトリには、スタートガイド、API リファレンス マニュアル、開発ガイドなど、ESP-IDF 関連の開発ドキュメントが含まれています。
注: 自動化ツールによってコンパイルされた後、このディレクトリの内容は https://docs.espressif.com/projects/esp-idf にデプロイされます。ドキュメント ターゲットを ESP32-C3 に切り替え、指定された ESP-IDF バージョンを選択してください。
c. スクリプトツール
このディレクトリには、idf.pyやモニターターミナルツールidf_monitor.pyなどのよく使われるコンパイルフロントエンドツールが含まれています。サブディレクトリcmakeにはコアスクリプトも含まれています。 fileコンパイル システムの s であり、ESP-IDF コンパイル ルールを実装するための基盤として機能します。環境変数を追加すると、ツール ディレクトリ内の内容がシステム環境変数に追加され、idf.py をプロジェクト パスの下で直接実行できるようになります。
d. 例ample プログラムディレクトリ exampレ
このディレクトリには、ESP-IDF exの膨大なコレクションが含まれていますampコンポーネントAPIの使用方法を示すプログラム。ampファイルは、カテゴリに基づいてさまざまなサブディレクトリに整理されます。
· get-started: このサブディレクトリには、初級レベルのexampユーザーが基本を理解できるように、「hello world」や「blink」などのコードを使用します。
· Bluetooth: Bluetooth関連の例が見つかりますampBluetooth LE Mesh、Bluetooth LE HID、BluFi など、その他の Bluetooth 技術については、こちらをご覧ください。
· wifi: このサブディレクトリはWi-Fi exに焦点を当てていますampWi-Fi SoftAP、Wi-Fi Station、espnowなどの基本プログラムや、独自の通信プロトコルexなどのプログラムを含むampEspressifからのファイル。また、複数のアプリケーション層の例も含まれています。ampIperf、Sniffer、Smart Config などの Wi-Fi ベースのファイル。
· 周辺機器: この大規模なサブディレクトリは、周辺機器名に基づいて多数のサブフォルダに分割されています。主に周辺機器ドライバなどが含まれています。ampエスプレッシフチップ用のles、各exampいくつかのサブexをフィーチャーしたleampたとえば、gpioサブディレクトリには2つのexamples: GPIOとGPIOマトリックスキーボード。すべてのexがそうではないことに注意することが重要ですampこのディレクトリ内のファイルは ESP32-C3 に適用可能です。
36 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

例えばampル、元ampusb/host のファイルは、USB ホストハードウェア (ESP32-S3 など) を備えた周辺機器にのみ適用され、ESP32-C3 にはこの周辺機器はありません。コンパイルシステムは通常、ターゲットを設定するときにプロンプ​​トを表示します。README file 各元ampleはサポートされているチップをリストします。 · protocols: このサブディレクトリにはexが含まれていますampMQTT、HTTP、HTTPサーバー、PPPoS、Modbus、mDNS、SNTPなど、さまざまな通信プロトコルのファイル。ampIoT開発に必要なファイル。 · プロビジョニング: ここでは、プロビジョニングの例が見つかります。ampWi-FiプロビジョニングやBluetooth LEプロビジョニングなど、さまざまな方法のファイルが含まれています。 · system: このサブディレクトリには、システムデバッグexが含まれています。ampトレース（スタックトレース、ランタイムトレース、タスク監視など）、電源管理などamp（例えば、さまざまなスリープモード、コプロセッサ）、およびexampコンソール端末、イベントループ、システムタイマーなどの一般的なシステムコンポーネントに関連するファイル。 · ストレージ: このサブディレクトリ内には、exampすべての file ESP-IDFがサポートするシステムとストレージメカニズム（フラッシュ、SDカード、その他のストレージメディアの読み取りと書き込みなど）、およびexamp不揮発性ストレージ（NVS）、FatFS、SPIFFS、その他の file システム操作。 · セキュリティ: このサブディレクトリには、exampフラッシュ暗号化に関連するファイル。（2）ESP-IDFコンパイルツールチェーンディレクトリ（/.espressif）（図4.3参照）。
図4.3. ESP-IDFコンパイルツールチェーンディレクトリ
第4章 開発環境の設定 37

a. ソフトウェア配布ディレクトリ dist
ESP-IDF ツール チェーンおよびその他のソフトウェアは、圧縮パッケージの形式で配布されます。インストール プロセス中、インストール ツールは最初に圧縮パッケージを dist ディレクトリにダウンロードし、次に指定されたディレクトリに解凍します。インストールが完了したら、このディレクトリの内容を安全に削除できます。
b. Python仮想環境ディレクトリ python env
ESP-IDF の異なるバージョンは、特定のバージョンの Python パッケージに依存しています。これらのパッケージを同じホストに直接インストールすると、パッケージ バージョン間で競合が発生する可能性があります。これに対処するために、ESP-IDF は Python 仮想環境を利用して、異なるパッケージ バージョンを分離します。このメカニズムにより、開発者は同じホストに複数のバージョンの ESP-IDF をインストールし、異なる環境変数をインポートすることで簡単に切り替えることができます。
c. ESP-IDFコンパイルツールチェーンディレクトリツール
このディレクトリには、主にESP-IDFプロジェクトをコンパイルするために必要なクロスコンパイルツール（CMakeツール、Ninjaビルドツール、最終的な実行可能プログラムを生成するgccツールチェーンなど）が含まれています。さらに、このディレクトリには、C / C ++言語の標準ライブラリと対応するヘッダーが格納されています。 fileプログラムがシステムヘッダーを参照する場合 file #includeのようにコンパイルツールチェーンはstdio.hを見つけます。 file このディレクトリ内。
4.2 ESP-IDF開発環境の設定
ESP-IDF 開発環境は、Windows、Linux、macOS などの主流のオペレーティング システムをサポートしています。このセクションでは、各システムで開発環境を設定する方法を紹介します。ESP32-C3 は Linux システムで開発することをお勧めします。これについてはここで詳しく説明します。開発ツールが類似しているため、多くの手順はプラットフォーム間で適用できます。したがって、このセクションの内容を注意深く読むことをお勧めします。
注: このセクションで説明したコマンドについては、https://bookc3.espressif.com/esp32c3 にあるオンライン ドキュメントを参照してください。
4.2.1 Linux上でのESP-IDF開発環境の設定
ESP-IDF開発環境に必要なGNU開発およびデバッグツールはLinuxシステムにネイティブです。さらに、Linuxのコマンドラインターミナルは強力でユーザーフレンドリーなので、ESP32-C3開発に最適です。
38 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

好みの Linux ディストリビューションを選択してください。ただし、Ubuntu またはその他の Debian ベースのシステムを使用することをお勧めします。このセクションでは、Ubuntu 20.04 で ESP-IDF 開発環境を設定する方法について説明します。
1. 必要なパッケージをインストールする
新しいターミナルを開き、次のコマンドを実行して必要なパッケージをすべてインストールします。このコマンドは、すでにインストールされているパッケージを自動的にスキップします。
$ sudo apt-get install git wget flex bison gperf python3 python3-pip python3setuptools cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0
ヒント 上記のコマンドには管理者アカウントとパスワードを使用する必要があります。 デフォルトでは、パスワードを入力しても情報は表示されません。 手順を続行するには、「Enter」キーを押すだけです。
GitはESP-IDFの重要なコード管理ツールです。開発環境を正常にセットアップしたら、git logコマンドを使用して view ESP-IDF の作成以降に行われたすべてのコード変更。さらに、ESP-IDF ではバージョン情報を確認するために Git も使用されます。これは、特定のバージョンに対応する正しいツール チェーンをインストールするために必要です。Git とともに、他の重要なシステム ツールには Python があります。ESP-IDF には、Python で書かれた多数の自動化スクリプトが組み込まれています。CMake、Ninja-build、Ccache などのツールは、C/C++ プロジェクトで広く使用されており、ESP-IDF のデフォルトのコード コンパイルおよびビルド ツールとして機能します。libusb-1.0-0 と dfu-util は、USB シリアル通信とファームウェアの書き込みに使用される主なドライバーです。ソフトウェア パッケージがインストールされると、apt show を使用して、各パッケージの詳細な説明を取得するコマンド。例:ample では、apt show git を使用して Git ツールの説明情報を出力します。
Q: Python バージョンがサポートされていない場合はどうすればよいですか? A: ESP-IDF v4.3 では、v3.6 以上の Python バージョンが必要です。Ubuntu の古いバージョンの場合は、手動で上位バージョンの Python をダウンロードしてインストールし、Python3 をデフォルトの Python 環境として設定してください。詳細な手順については、キーワード update-alternatives python を検索すると見つかります。
2. ESP-IDFリポジトリコードをダウンロードする
ターミナルを開き、mkdir コマンドを使用してホーム ディレクトリに esp という名前のフォルダーを作成します。必要に応じて、フォルダーに別の名前を選択できます。フォルダーに入るには、cd コマンドを使用します。
第4章 開発環境の設定 39

$ mkdir -p /esp $ cd /esp
以下に示すように、git clone コマンドを使用して ESP-IDF リポジトリ コードをダウンロードします。
$ git clone -b v4.3.2 –recursive https://github.com/espressif/esp-idf.git
上記のコマンドでは、パラメータ -b v4.3.2 はダウンロードするバージョン（この場合はバージョン 4.3.2）を指定します。パラメータ –recursive は、ESP-IDF のすべてのサブリポジトリが再帰的にダウンロードされることを保証します。サブリポジトリに関する情報は、.gitmodules にあります。 file.
3. ESP-IDF開発ツールチェーンをインストールする
Espressif は、ツール チェーンをダウンロードしてインストールするための自動スクリプト install.sh を提供します。このスクリプトは、現在の ESP-IDF バージョンとオペレーティング システム環境をチェックし、適切なバージョンの Python ツール パッケージとコンパイル ツール チェーンをダウンロードしてインストールします。ツール チェーンのデフォルトのインストール パスは /.espressif です。esp-idf ディレクトリに移動して install.sh を実行するだけです。
$ cd /esp/esp-idf $ ./install.sh
ツールチェーンが正常にインストールされると、ターミナルに次のように表示されます。
完了しました！
この時点で、ESP-IDF 開発環境が正常にセットアップされました。
4.2.2 WindowsでのESP-IDF開発環境のセットアップ
1. ESP-IDFツールインストーラーをダウンロードする
TIPS ESP-IDF開発環境はWindows 10以降で構築することをお勧めします。インストーラーはhttps://dl.espressif.com/dl/esp-idf/からダウンロードできます。インストーラーもオープンソースソフトウェアであり、ソースコードは viewhttps://github.com/espressif/idf-installer で公開されています。
· オンライン ESP-IDF ツール インストーラー
このインストーラーは比較的小さく、サイズは約4MBで、他のパッケージとコードはインストールプロセス中にダウンロードされます。tagオンラインインストーラーの利点は、インストールプロセス中にソフトウェアパッケージとコードをオンデマンドでダウンロードできるだけでなく、ESP-IDFのすべての利用可能なリリースとGitHubコードの最新ブランチ（マスターブランチなど）をインストールできることです。欠点は、tag欠点は、インストール プロセス中にネットワーク接続が必要になるため、ネットワークの問題によりインストールが失敗する可能性があることです。
40 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

· オフラインESP-IDFツールインストーラー このインストーラーはサイズが約1GBと大きく、環境設定に必要なすべてのソフトウェアパッケージとコードが含まれています。主な利点は、tagオフライン インストーラーの利点は、インターネットにアクセスできないコンピューターでも使用できることと、一般的にインストールの成功率が高いことです。オフライン インストーラーでは、v*.* または v*.*.* で識別される ESP-IDF の安定したリリースのみをインストールできることに注意してください。
2. ESP-IDFツールインストーラーを実行します。インストーラーの適切なバージョンをダウンロードした後（たとえば、ESP-IDF Tools Offline 4.3.2）、amp（ここを参照）exeファイルをダブルクリックします file ESP-IDF インストール インターフェイスを起動します。以下は、オフライン インストーラーを使用して ESP-IDF 安定バージョン v4.3.2 をインストールする方法を示しています。
（1）図4.4に示す「インストール言語の選択」インターフェースで、ドロップダウンリストから使用する言語を選択します。
図4.4. 「インストール言語の選択」インターフェース（2）言語を選択したら、「OK」をクリックして「ライセンス契約」インターフェースをポップアップ表示します。
(図 4.5 を参照)。インストール ライセンス契約をよくお読みになった後、「同意します」を選択し、「次へ」をクリックします。
図4.5. 「ライセンス契約」インターフェース 第4章 開発環境の設定 41

（１）再view 「インストール前のシステム チェック」インターフェイスでシステム構成を確認します (図 4.6 を参照)。Windows のバージョンとインストールされているウイルス対策ソフトウェアの情報を確認します。すべての構成項目が正常であれば、「次へ」をクリックします。それ以外の場合は、「完全なログ」をクリックして、主要な項目に基づいた解決策を確認できます。
図4.6. 「インストール前のシステムチェック」インターフェースのヒント
ヘルプが必要な場合は、https://github.com/espressif/idf-installer/issuesにログを送信してください。(4) ESP-IDFのインストールディレクトリを選択します。ここでは、D:/.espressifを選択します。
図4.7で「次へ」をクリックします。.espressifは隠しディレクトリであることに注意してください。インストールが完了したら、 view このディレクトリの具体的な内容は、 file マネージャーと非表示のアイテムを表示します。
図4.7 ESP-IDFのインストールディレクトリを選択する 42 ESP32-C3ワイヤレスアドベンチャー：IoTの包括的なガイド

（5）図4.8に示すように、インストールする必要があるコンポーネントを確認します。デフォルトのオプション、つまりインストールを完了し、「次へ」をクリックすることをお勧めします。
図4.8. インストールするコンポーネントの選択 (6) インストールするコンポーネントを確認し、「インストール」をクリックして自動インストールを開始します。
図 4.9 に示すように、インストール プロセスは数十分かかる場合があります。インストール プロセスの進行状況バーは図 4.10 に示されています。しばらくお待ちください。
図4.9. インストールの準備 (7) インストールが完了したら、「ESP-IDFを登録する」をチェックすることをお勧めします。
ツールの実行ファイルをWindows Defenderの除外リストに追加して、ウイルス対策ソフトウェアによる削除を防止します。 file除外項目を追加すると、ウイルス対策による頻繁なスキャンをスキップすることもできます。
第4章 開発環境の設定 43

図 4.10。インストール進捗状況バー ソフトウェア。Windows システムのコード コンパイル効率が大幅に向上します。図 4.11 に示すように、「完了」をクリックして開発環境のインストールを完了します。「ESP-IDF PowerShell 環境を実行する」または「ESP-IDF コマンド プロンプトを実行する」をチェックすることを選択できます。インストール後すぐにコンパイル ウィンドウを実行して、開発環境が正常に機能することを確認します。
図4.11. インストール完了 (8) プログラムリストでインストールされた開発環境を開きます（ESP-IDF 4.3
4.3 に示すように、ESP-IDF 4.12 PowerShell ターミナルで ESP-IDF 環境変数が自動で追加されます。その後は、idf.py コマンドを使用して操作できます。開いた ESP-IDF 4.3 CMD を図 4.13 に示します。 44 ESP32-C3 ワイヤレス アドベンチャー: IoT の包括的なガイド

図4.12. 開発環境がインストールされました
図4.13. ESP-IDF 4.3 CMD
4.2.3 MacでのESP-IDF開発環境の設定
Mac システムに ESP-IDF 開発環境をインストールするプロセスは、Linux システムの場合と同じです。リポジトリ コードをダウンロードしてツール チェーンをインストールするためのコマンドはまったく同じです。依存パッケージをインストールするためのコマンドのみが少し異なります。 1. 依存パッケージをインストールする ターミナルを開き、次のコマンドを実行して、Python パッケージ管理ツールである pip をインストールします。
% sudo 簡単インストール pip
次のコマンドを実行して、macOS 用のパッケージ管理ツールである Homebrew をインストールします。
% /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/ HEAD/install.sh)”
次のコマンドを実行して、必要な依存パッケージをインストールします。
% brew python3 をインストール cmake ninja ccache dfu-util
2. ESP-IDF リポジトリ コードをダウンロードする セクション 4.2.1 の指示に従って、ESP-IDF リポジトリ コードをダウンロードします。手順は、Linux システムでのダウンロードの場合と同じです。
第4章 開発環境の設定 45

3. ESP-IDF開発ツールチェーンをインストールする
ESP-IDF 開発ツール チェーンをインストールするには、セクション 4.2.1 の手順に従ってください。手順は Linux システムへのインストールの場合と同じです。
4.2.4 VSコードのインストール
デフォルトでは、ESP-IDF SDK にはコード編集ツールは含まれていません (ただし、Windows 用の最新の ESP-IDF インストーラーには、ESP-IDF Eclipse をインストールするオプションが用意されています)。任意のテキスト編集ツールを使用してコードを編集し、ターミナル コマンドを使用してコンパイルすることができます。
人気のコード編集ツールの1つにVS Code（Visual Studio Code）があります。これは、ユーザーフレンドリーなインターフェースを備えた、無料で機能豊富なコードエディタです。さまざまな plugins コードナビゲーション、構文の強調表示、Git バージョン管理、ターミナル統合などの機能を提供します。さらに、Espressif は、プロジェクトの構成とデバッグを簡素化する Espressif IDF for VS Code という専用プラグインを開発しました。
ターミナルで code コマンドを使用すると、VS Code で現在のフォルダーをすばやく開くことができます。または、ショートカット Ctrl+ を使用して、VS Code 内でシステムのデフォルトのターミナル コンソールを開くこともできます。
ヒント ESP32-C3 コード開発には VS Code を使用することをお勧めします。https://code.visualstudio.com/ から最新バージョンの VS Code をダウンロードしてインストールしてください。
4.2.5 サードパーティ開発環境の紹介
ESP32-C3 は、主に C 言語を使用する公式の ESP-IDF 開発環境に加えて、他の主流のプログラミング言語や幅広いサードパーティ開発環境もサポートしています。注目すべきオプションには次のようなものがあります。
Arduino: ESP32-C3 を含むさまざまなマイクロコントローラをサポートする、ハードウェアとソフトウェアの両方に対応したオープンソース プラットフォームです。
C++ 言語を使用し、一般的に Arduino 言語と呼ばれる簡素化された標準化された API を提供します。Arduino はプロトタイプ開発や教育の分野で広く使用されています。拡張可能なソフトウェア パッケージと、コンパイルとフラッシュが簡単にできる IDE を提供します。
MicroPython: 組み込みマイクロコントローラ プラットフォーム上で実行するように設計された Python 3 言語インタープリター。
シンプルなスクリプト言語で、ESP32-C3 の周辺リソース (UART、SPI、I2C など) や通信機能 (Wi-Fi、Bluetooth LE など) に直接アクセスできます。
46 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

これにより、ハードウェアの相互作用が簡素化されます。 MicroPython は、Python の広範な数学演算ライブラリと組み合わせることで、ESP32-C3 上で複雑なアルゴリズムを実装できるようになり、AI 関連アプリケーションの開発が容易になります。 スクリプト言語であるため、繰り返しコンパイルする必要がなく、変更を加えてスクリプトを直接実行できます。
NodeMCU: ESP シリーズ チップ用に開発された LUA 言語インタープリター。
ESP チップのほぼすべての周辺機能をサポートし、MicroPython よりも軽量です。MicroPython と同様に、NodeMCU はスクリプト言語を使用するため、繰り返しコンパイルする必要がありません。
さらに、ESP32-C3 は NuttX および Zephyr オペレーティングシステムもサポートしています。NuttX は、POSIX 互換のインターフェースを提供し、アプリケーションの移植性を高めるリアルタイムオペレーティングシステムです。Zephyr は、IoT アプリケーション向けに特別に設計された小型のリアルタイムオペレーティングシステムです。IoT 開発に必要な多数のソフトウェアライブラリが含まれており、徐々に包括的なソフトウェアエコシステムへと進化しています。
本書では、前述の開発環境の詳細なインストール手順については説明していません。それぞれのドキュメントと手順に従って、要件に基づいて開発環境をインストールできます。
4.3 ESP-IDFコンパイルシステム
4.3.1 コンパイルシステムの基本概念
ESP-IDFプロジェクトは、エントリ関数と複数の独立した機能コンポーネントを備えたメインプログラムのコレクションです。たとえば、ample、LEDスイッチを制御するプロジェクトは、主にエントリプログラムメインとGPIOを制御するドライバーコンポーネントで構成されています。LEDリモートコントロールを実現する場合は、Wi-Fi、TCP / IPプロトコルスタックなども追加する必要があります。
コンパイルシステムは、コンパイル、リンク、実行可能ファイルの生成ができます。 file一連のビルド ルールを通じて、コードの .bin ファイルを作成します。ESP-IDF v4.0 以降のバージョンのコンパイル システムは、デフォルトで CMake に基づいており、コンパイル スクリプト CMakeLists.txt を使用してコードのコンパイル動作を制御できます。ESP-IDF コンパイル システムでは、CMake の基本構文をサポートするだけでなく、一連のデフォルトのコンパイル ルールと CMake 関数も定義されており、簡単なステートメントでコンパイル スクリプトを記述できます。
4.3.2 プロジェクト File 構造
プロジェクトは、エントリプログラムメイン、ユーザー定義コンポーネント、および fileコンパイルスクリプト、構成スクリプトなどの実行可能アプリケーションを構築するために必要なもの
第4章 開発環境の設定 47

files、パーティションテーブルなど。プロジェクトはコピーして渡すことができ、同じ実行可能ファイル file 同じバージョンのESP-IDF開発環境を持つマシンでコンパイルおよび生成できます。典型的なESP-IDFプロジェクト file 構造を図4.14に示します。
図4.14. 典型的なESP-IDFプロジェクト file 構造 ESP-IDFは、ESP32、ESP32-Sシリーズ、ESP32-Cシリーズ、ESP32-Hシリーズなど、Espressifの複数のIoTチップをサポートしているため、コードをコンパイルする前にターゲットを決定する必要があります。ターゲットは、アプリケーションプログラムを実行するハードウェアデバイスと、コンパイルシステムのビルドターゲットの両方です。必要に応じて、プロジェクトにXNUMXつ以上のターゲットを指定できます。例：ampたとえば、コマンド idf.py set-target esp32c3 を使用すると、コンパイル ターゲットを ESP32-C3 に設定できます。このとき、ESP32C3 のデフォルト パラメータとコンパイル ツール チェーン パスがロードされます。コンパイル後、ESP32C3 の実行可能プログラムを生成できます。コマンド set-target を再度実行して別のターゲットを設定することもできます。その場合、コンパイル システムが自動的にクリーンアップして再構成されます。コンポーネント
ESP-IDFのコンポーネントは、コンパイルシステム内で管理されるモジュール式で独立したコードユニットです。これらはフォルダーとして整理されており、フォルダー名はデフォルトでコンポーネント名を表します。各コンポーネントには独自のコンパイルスクリプトがあり、

コンパイルパラメータと依存関係を指定します。コンパイルプロセス中に、コンポーネントは個別の静的ライブラリ（.a）にコンパイルされます。 file最終的に他のコンポーネントと組み合わせてアプリケーション プログラムを形成します。
ESP-IDF は、オペレーティング システム、周辺機器ドライバ、ネットワーク プロトコル スタックなどの重要な機能をコンポーネントの形で提供します。これらのコンポーネントは、ESP-IDF ルート ディレクトリ内のコンポーネント ディレクトリに保存されます。開発者は、これらのコンポーネントを myProject のコンポーネント ディレクトリにコピーする必要はありません。代わりに、プロジェクトの CMakeLists.txt でこれらのコンポーネントの依存関係を指定するだけで済みます。 file REQUIRES または PRIV_REQUIRES ディレクティブを使用します。コンパイル システムは必要なコンポーネントを自動的に検索してコンパイルします。
したがって、myProject の下の components ディレクトリは必要ありません。これは、プロジェクトのカスタム コンポーネント (サードパーティ ライブラリまたはユーザー定義コード) を含めるためにのみ使用されます。さらに、コンポーネントは、別のディレクトリに保存されているオープン ソース プロジェクトなど、ESP-IDF または現在のプロジェクト以外の任意のディレクトリから取得できます。この場合、ルート ディレクトリの下の CMakeLists.txt で EXTRA_COMPONENT_DIRS 変数を設定して、コンポーネントのパスを追加するだけで済みます。このディレクトリは、同じ名前の ESP-IDF コンポーネントを上書きし、正しいコンポーネントが使用されるようにします。
エントリープログラムメインプロジェクト内のメインディレクトリは同じ file メイン ディレクトリは、他のコンポーネント (例: component1) と同じ構造です。ただし、すべてのプロジェクトに必須のコンポーネントであるため、特別な意味を持ちます。メイン ディレクトリには、プロジェクトのソース コードと、通常 app_main という名前のユーザー プログラムのエントリ ポイントが含まれます。デフォルトでは、ユーザー プログラムの実行はこのエントリ ポイントから開始されます。メイン コンポーネントは、検索パス内のすべてのコンポーネントに自動的に依存するという点でも異なります。したがって、CMakeLists.txt で REQUIRES または PRIV_REQUIRES ディレクティブを使用して依存関係を明示的に示す必要はありません。 file.
構成 file プロジェクトのルートディレクトリには設定が含まれています file sdkconfigと呼ばれるもので、プロジェクト内のすべてのコンポーネントの設定パラメータが含まれています。sdkconfigは file コンパイル システムによって自動的に生成され、コマンド idf.py menuconfig によって変更および再生成できます。menuconfig オプションは、主にプロジェクトの Kconfig.projbuild とコンポーネントの Kconfig から生成されます。コンポーネント開発者は通常、Kconfig に構成項目を追加して、コンポーネントを柔軟かつ構成可能にします。
ビルドディレクトリ デフォルトでは、プロジェクト内のビルドディレクトリには中間ファイルが保存されます。 fileとfi-
第4章 開発環境の設定 49

idf.pyビルドコマンドによって生成された実行可能プログラム。通常、ビルドディレクトリの内容に直接アクセスする必要はありません。ESP-IDFは、コンパイルされたバイナリを自動的に見つけるためにidf.pyフラッシュコマンドを使用するなど、ディレクトリと対話するための定義済みコマンドを提供します。 file 指定されたフラッシュ アドレスにフラッシュするか、idf.py fullclean コマンドを使用してビルド ディレクトリ全体をクリーンアップします。
パーティション テーブル (partitions.csv) 各プロジェクトには、フラッシュのスペースを分割し、実行可能プログラムとユーザー データ スペースのサイズと開始アドレスを指定するためのパーティション テーブルが必要です。コマンド idf.py flash または OTA アップグレード プログラムは、このテーブルに従って、ファームウェアを対応するアドレスにフラッシュします。ESP-IDF は、partitions_singleapp.csv や partitions_two_ ota.csv など、components/partition_table にいくつかのデフォルトのパーティション テーブルを提供しており、これらは menuconfig で選択できます。
システムのデフォルトのパーティション テーブルがプロジェクトの要件を満たせない場合は、カスタムのpartitions.csvをプロジェクト ディレクトリに追加し、menuconfig で選択できます。
4.3.3 コンパイルシステムのデフォルトのビルドルール
同じ名前のコンポーネントをオーバーライドするためのルール コンポーネントの検索プロセス中、コンパイル システムは特定の順序に従います。最初に ESP-IDF の内部コンポーネントを検索し、次にユーザー プロジェクトのコンポーネントを検索し、最後に EXTRA_COMPONENT_DIRS 内のコンポーネントを検索します。複数のディレクトリに同じ名前のコンポーネントが含まれている場合、最後のディレクトリで見つかったコンポーネントは、同じ名前の以前のコンポーネントをオーバーライドします。このルールにより、元の ESP-IDF コードをそのまま維持しながら、ユーザー プロジェクト内で ESP-IDF コンポーネントをカスタマイズできます。
共通コンポーネントをデフォルトで含めるルール セクション 4.3.2 で述べたように、コンポーネントは CMakeLists.txt で他のコンポーネントへの依存関係を明示的に指定する必要があります。ただし、freertos などの共通コンポーネントは、依存関係がコンパイル スクリプトで明示的に定義されていない場合でも、デフォルトでビルド システムに自動的に含められます。ESP-IDF 共通コンポーネントには、freertos、Newlib、heap、log、soc、esp_rom、esp_common、xtensa/riscv、cxx などがあります。これらの共通コンポーネントを使用すると、CMakeLists.txt の作成時に繰り返し作業が回避され、より簡潔になります。
設定項目を上書きするためのルール開発者は、デフォルト設定を追加することで、デフォルト設定パラメータを追加できる。 file sdkconfig.defaultsという名前のファイルをプロジェクトに追加します。例:ample、CONFIG_LOG_を追加
50 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

DEFAULT_LEVEL_NONE = y は、UARTインターフェースがデフォルトでログデータを印刷しないように設定できます。さらに、特定のターゲットに特定のパラメータを設定する必要がある場合は、構成 file sdkconfig.defaults.TARGET_NAMEという名前を追加できます。TARGET_NAMEはesp32s2、esp32c3などです。これらの設定 fileコンパイル時にsdkconfigにインポートされ、一般的なデフォルト設定が使用される。 file 最初に sdkconfig.defaults がインポートされ、その後にターゲット固有の構成がインポートされます。 file、例えばsdkconfig.defaults.esp32c3。同じ名前の設定項目がある場合、後者の設定 file 前者を上書きします。
4.3.4 コンパイルスクリプトの紹介
ESP-IDFを使用してプロジェクトを開発する場合、開発者はソースコードを書くだけでなく、プロジェクトとコンポーネントのCMakeLists.txtも書く必要があります。CMakeLists.txtはテキストファイルです。 fileは、コンパイル スクリプトとも呼ばれ、一連のコンパイル オブジェクト、コンパイル構成項目、およびソース コードのコンパイル プロセスをガイドするコマンドを定義します。ESP-IDF v4.3.2 のコンパイル システムは CMake に基づいています。ネイティブの CMake 関数とコマンドをサポートするだけでなく、一連のカスタム関数も定義しているため、コンパイル スクリプトの作成がはるかに簡単になります。
ESP-IDF のコンパイル スクリプトには、主にプロジェクト コンパイル スクリプトとコンポーネント コンパイル スクリプトが含まれます。プロジェクトのルート ディレクトリにある CMakeLists.txt はプロジェクト コンパイル スクリプトと呼ばれ、プロジェクト全体のコンパイル プロセスをガイドします。基本的なプロジェクト コンパイル スクリプトには通常、次の 3 行が含まれます。
1. cmake_minimum_required(バージョン 3.5) 2. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 3. project(myProject)
このうち、cmake_minimum_required (VERSION 3.5) は最初の行に配置する必要があります。これは、プロジェクトに必要な CMake の最小バージョン番号を示すために使用されます。新しいバージョンの CMake は通常、古いバージョンと下位互換性があるため、新しい CMake コマンドを使用するときは、互換性を確保するためにバージョン番号を適宜調整してください。
include($ENV {IDF_PATH}/tools/cmake/project.cmake) は、セクション 4.3.3 で説明されているコンパイル システムのデフォルトのビルド ルールを含む、ESP-IDF コンパイル システムの定義済み構成項目とコマンドをインポートします。project(myProject) はプロジェクト自体を作成し、その名前を指定します。この名前は、最終的な出力バイナリとして使用されます。 file 名前、つまり、myProject.elf と myProject.bin。
プロジェクトには、メインコンポーネントを含む複数のコンポーネントを含めることができます。各コンポーネントの最上位ディレクトリには、CMakeLists.txtが含まれています。 fileコンポーネントコンパイルスクリプトと呼ばれるものです。コンポーネントコンパイルスクリプトは主にコンポーネントの依存関係、構成パラメータ、ソースコードを指定するために使用されます。 files、および含まれているヘッダー filesは
第4章 開発環境の設定 51

コンパイル。ESP-IDF のカスタム関数 idf_component_register を使用すると、コンポーネント コンパイル スクリプトに必要な最小限のコードは次のようになります。

1. idf_component_register(SRCS “src1.c”

2.

INCLUDE_DIRS “含める”

3.

コンポーネント1が必要です)

SRCSパラメータはソースのリストを提供します fileコンポーネント内の複数の場合はスペースで区切って指定します。 fileINCLUDE_DIRSパラメータは、パブリックヘッダーのリストを提供します。 file コンポーネントのディレクトリ。これは、現在のコンポーネントに依存する他のコンポーネントのインクルード検索パスに追加されます。REQUIRES パラメータは、現在のコンポーネントのパブリック コンポーネント依存関係を識別します。コンポーネントは、component2 が component1 に依存するなど、どのコンポーネントに依存するかを明示的に指定する必要があります。ただし、デフォルトですべてのコンポーネントに依存するメイン コンポーネントの場合は、REQUIRES パラメータを省略できます。

さらに、ネイティブのCMakeコマンドもコンパイルスクリプトで使用できます。例：ample では、set(VARIABLE “VALUE”) などの set コマンドを使用して変数を設定します。

4.3.5 一般的なコマンドの紹介
ESP-IDF は、コード コンパイルのプロセスで CMake (プロジェクト構成ツール)、Ninja (プロジェクト ビルド ツール)、esptool (フラッシュ ツール) を使用します。各ツールは、コンパイル、ビルド、フラッシュ プロセスで異なる役割を果たし、異なる操作コマンドもサポートします。ユーザーの操作を容易にするために、ESP-IDF は、上記のコマンドをすばやく呼び出すことができる統合フロントエンド idf.py を追加します。
idf.py を使用する前に、次の点を確認してください。
· ESP-IDFの環境変数IDF_PATHが現在のターミナルに追加されました。 · コマンド実行ディレクトリはプロジェクトのルートディレクトリで、
プロジェクトコンパイルスクリプト CMakeLists.txt。
idf.py の一般的なコマンドは次のとおりです。
· idf.py –help: コマンドの一覧とその使用方法を表示します。 · idf.py set-target : コンパイルtaidf.py fullcleanrgetの設定、など
置き換えとしてesp32c3 を使用。 · idf.py menuconfig: ターミナルのグラフィカル設定である menuconfig を起動します。
設定オプションを選択または変更できるツールで、設定結果はsdkconfigに保存されます。 file. · idf.py build: コードのコンパイルを開始します。中間 fileコンパイルによって生成された最終的な実行可能プログラムは、デフォルトでプロジェクトのビルドディレクトリに保存されます。コンパイルプロセスは増分的であるため、1つのソースコードのみをコンパイルした場合、 file 変更された場合、変更された部分のみが file 次回コンパイルされます。

52 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

· idf.py clean: 中間ファイルのクリーンアップ fileプロジェクトのコンパイルによって生成されたファイル。次のコンパイルではプロジェクト全体が強制的にコンパイルされます。クリーンアップ中に CMake 構成と menuconfig による構成変更は削除されないことに注意してください。
· idf.py fullclean: CMake 構成出力を含むビルドディレクトリ全体を削除します fileプロジェクトを再度ビルドすると、CMakeはプロジェクトを最初から構成します。このコマンドは、すべての fileビルドディレクトリに含まれていないので注意して使用してください。プロジェクト構成 file 削除されません。
· idf.py flash: 実行可能プログラムバイナリのフラッシュ file ビルドによってターゲットESP32-C3に生成されます。オプション-pおよび -bは、それぞれシリアル ポートのデバイス名とフラッシュのボー レートを設定するために使用されます。これらの XNUMX つのオプションが指定されていない場合は、シリアル ポートが自動的に検出され、デフォルトのボー レートが使用されます。
· idf.py モニター: ターゲット ESP32-C3 のシリアル ポート出力を表示します。オプション -p を使用して、ホスト側のシリアル ポートのデバイス名を指定できます。シリアル ポート出力中に、Ctrl+] キーの組み合わせを押すと、モニターを終了します。
上記のコマンドは必要に応じて組み合わせることもできます。例:ample では、コマンド idf.py build flash monitor は、コードのコンパイル、フラッシュ、シリアル ポート モニターのオープンを順番に実行します。
ESP-IDF コンパイル システムの詳細については、https://bookc3.espressif.com/build-system をご覧ください。
4.4 練習: コンパイル例ampプログラム「Blink」
4.4.1例ampファイル分析
このセクションでは、Blinkプログラムを例に挙げます。amp分析する file 実際のプロジェクトの構造とコーディングルールを詳細に説明します。BlinkプログラムはLEDの点滅効果を実装しており、プロジェクトはディレクトリexにあります。amples/get-started/blinkにはソースが含まれています file、 構成 fileおよびいくつかのコンパイル スクリプト。
この本で紹介されているスマートライトプロジェクトは、この例に基づいていますample プログラム。後の章で徐々に機能が追加され、最終的に完成します。
ソース コード 開発プロセス全体をデモンストレーションするために、Blink プログラムは esp32c3-iot-projects/devicefirmware/1 blink にコピーされています。
Blinkプロジェクトのディレクトリ構造 filesを図4.15に示します。
blinkプロジェクトには、特別なコンポーネントであるメインディレクトリが1つだけ含まれています。
第4章 開発環境の設定 53

図4.15. File Blinkプロジェクトのディレクトリ構造

セクション4.3.2で説明されているように、メインディレクトリはapp_main()関数の実装を格納するために主に使用されます。これはユーザープログラムのエントリポイントです。blinkプロジェクトにはコンポーネントディレクトリが含まれていません。ampleはESP-IDFに付属するコンポーネントのみを使用する必要があり、追加のコンポーネントは必要ありません。blinkプロジェクトに含まれるCMakeLists.txtはコンパイルプロセスをガイドするために使用され、Kconfig.projbuildはこの例の設定項目を追加するために使用されます。ampmenuconfigのleプログラム。その他の不要な fileはコードのコンパイルには影響しないので、ここでは説明しません。Blinkプロジェクトの詳細な紹介 filesは以下の通りです。

1. /*blink.c には次のヘッダーが含まれています files*/

2. #include

//標準Cライブラリヘッダー file

3. #include “freertos/freeRTOS.h” //FreeRTOSメインヘッダー file

4. #include “freertos/task.h”

//FreeRTOS タスク ヘッダー file

5. #include “sdkconfig.h”

//構成ヘッダー file kconfig によって生成されました

6. #include “driver/gpio.h”

//GPIO ドライバー ヘッダー file

情報源 file blink.cには一連のヘッダーが含まれています file関数宣言に対応する

ESP-IDFは、一般的に標準ライブラリヘッダーをインクルードする順序に従います。 files、FreeR-

TOSヘッダー files、ドライバーヘッダー files、その他のコンポーネントヘッダー fileおよびプロジェクトヘッダー files.

ヘッダーの順序 fileが含まれていると最終的なコンパイル結果に影響する可能性があるため、

デフォルトのルールに従ってください。sdkconfig.hは自動的に生成されることに注意してください。

kconfig によって実行され、コマンド idf.py menuconfig を通じてのみ構成できます。

このヘッダーを直接変更する file 上書きされます。

1. /* idf.py menuconfigでLEDに対応するGPIOを選択でき、menuconfigの変更結果はCONFIG_BLINKの値です

_GPIOが変更されます。マクロ定義を直接変更することもできます

ここで、CONFIG_BLINK_GPIO を固定値に変更します。*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO

3. void app_main(void)

4. {

5.

/*IOをGPIOのデフォルト機能として設定し、プルアップモードを有効にし、

6.

入力モードと出力モードを無効にする*/

7.

gpio_reset_pin(BLINK_GPIO);

54 ESP32-C3 ワイヤレスアドベンチャー: IoT の総合ガイド

8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. }

/*GPIOを出力モードに設定する*/ gpio_set_direction(BLINK_GPIO, GPIO_MODE_OUTPUT); while(1) {
/*ログを印刷*/ printf(“LEDn をオフにします”); /*LED をオフにします (出力低レベル)*/ gpio_set_level(BLINK_GPIO, 0); /*遅延 (1000 ms)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf(“LEDn をオンにします”); /*LED をオンにします (出力高レベル)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay(1000 / portTICK_PERIOD_MS); }

Blink exのapp_main()関数ample プログラムは、ユーザー プログラムのエントリ ポイントとして機能します。これは、パラメーターも戻り値もない単純な関数です。この関数は、ログ シリアル ポートの初期化、シングル/デュアル コアの構成、ウォッチドッグの構成などのタスクを含むシステムの初期化が完了した後に呼び出されます。

app_main() 関数は、main という名前のタスクのコンテキストで実行されます。このタスクのスタック サイズと優先度は、menuconfig Componentconfig Common ESP 関連で調整できます。

LED を点滅させるような単純なタスクの場合、必要なコードはすべて app_main() 関数に直接実装できます。通常、これには LED に対応する GPIO の初期化と、while(1) ループを使用した LED のオン/オフの切り替えが含まれます。または、FreeRTOS API を使用して、LED の点滅を処理する新しいタスクを作成することもできます。新しいタスクが正常に作成されたら、app_main() 関数を終了できます。

main/CMakeLists.txtの内容 fileメインコンポーネントのコンパイルプロセスをガイドする は次のとおりです。

1. idf_component_register(SRCS “blink.c” INCLUDE_DIRS “.”)

その中で、main/CMakeLists.txtはidf_component_registerという1つのコンパイルシステム関数のみを呼び出します。他のほとんどのコンポーネントのCMakeLists.txtと同様に、blink.cがSRCSに追加され、ソース fileSRCSに追加されたファイルはコンパイルされます。同時に、CMakeLists.txtがあるパスを表す「.」をINCLUDE_DIRSにヘッダーの検索ディレクトリとして追加する必要があります。 fileCMakeLists.txt の内容は次のとおりです。
1. #現在のプロジェクトでサポートされている最も古い CMake バージョンとして v3.5 を指定します 2. #コンパイルを続行する前に、v3.5 より前のバージョンをアップグレードする必要があります 3. cmake_minimum_required(VERSION 3.5) 4. #ESP-IDF コンパイル システムのデフォルトの CMake 構成を含めます

第4章 開発環境の設定 55

5. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 6. #「blink」という名前のプロジェクトを作成します 7. project(myProject)
その中で、ルートディレクトリのCMakeLists.txtには主に$ENV{IDF_PATH}/tools/cmake/project.cmakeが含まれており、これがメインのCMake構成です。 file ESP-IDFによって提供される。

ドキュメント / リソース

Espressif Systems ESP32-C3 ワイヤレスアドベンチャー [pdf] ユーザーガイド ESP32-C3 ワイヤレス アドベンチャー、ESP32-C3、ワイヤレス アドベンチャー、アドベンチャー

参考文献

• ユーザーマニュアル