Посібник користувача Espressif Systems ESP32-C3 Wireless Adventure

Перш ніж використовувати ESP32-C3 Wireless Adventure, переконайтеся, що ви є
знайомі з концепціями та архітектурою IoT. Це допоможе
ви розумієте, як пристрій вписується в більшу екосистему IoT
і його потенційне застосування в розумних будинках.

Впровадження та практика проектів IoT

У цьому розділі ви дізнаєтесь про типові проекти IoT,
включаючи основні модулі для звичайних пристроїв IoT, базові модулі
клієнтських програм і звичайних хмарних платформ IoT. Це буде
забезпечить вам основу для розуміння та створення ваших
власні проекти IoT.

Практика: Smart Light Project

У цьому практичному проекті ви навчитеся створювати смарт
світло за допомогою ESP32-C3 Wireless Adventure. Структура проекту,
функції, підготовка апаратного забезпечення та процес розробки
детально пояснено.

Структура проекту

Проект складається з кількох компонентів, у тому числі
ESP32-C3 Wireless Adventure, світлодіоди, датчики та хмара
бекенд.

Функції проекту

Проект розумного світла дозволяє контролювати яскравість і
колір світлодіодів віддалено через мобільний додаток або web
інтерфейс.

Підготовка обладнання

Щоб підготуватися до проекту, вам потрібно буде зібрати
необхідні апаратні компоненти, наприклад ESP32-C3 Wireless
Дошка пригод, світлодіоди, резистори та блок живлення.

Процес розробки

Процес розробки передбачає налаштування розробки
середовища, написання коду для керування світлодіодами, підключення до
хмарний бекенд і тестування функціональності smart
світло.

Знайомство з ESP RainMaker

ESP RainMaker — потужний фреймворк для розробки IoT
пристроїв. У цьому розділі ви дізнаєтеся, що таке ESP RainMaker і
як це можна реалізувати у своїх проектах.

Що таке ESP RainMaker?

ESP RainMaker — це хмарна платформа, яка надає набір
інструменти та сервіси для створення та керування пристроями IoT.

Впровадження ESP RainMaker

У цьому розділі пояснюються різні компоненти, задіяні в
впровадження ESP RainMaker, включаючи службу подання претензій,
RainMaker Agent, хмарний сервер і клієнт RainMaker.

Практика: ключові моменти для розробки з ESP RainMaker

У цьому розділі практики ви дізнаєтесь про ключові моменти
враховувати під час розробки за допомогою ESP RainMaker. Це включає пристрій
подання претензій, синхронізація даних і керування користувачами.

Особливості ESP RainMaker

ESP RainMaker пропонує різні функції для керування користувачами
користувачів і адміністраторів. Ці особливості дозволяють легко пристрій
налаштування, дистанційне керування та моніторинг.

Налаштування середовища розробки

Цей розділ забезпечує оверview ESP-IDF (Espressif IoT
Development Framework), яка є офіційною структурою розробки
для пристроїв на основі ESP32. Це пояснює різні версії
ESP-IDF і як налаштувати середовище розробки.

Розробка обладнання та драйверів

Розробка апаратного забезпечення інтелектуальних світлових продуктів на основі ESP32-C3

У цьому розділі розглядається апаратне забезпечення інтелектуального освітлення
продукти на базі ESP32-C3 Wireless Adventure. Він охоплює
особливості та склад розумних світлових виробів, а також
дизайн апаратного забезпечення основної системи ESP32-C3.

Особливості та склад продуктів Smart Light

У цьому підрозділі пояснюються функції та компоненти, які роблять
інтелектуальні світлові продукти. У ньому обговорюються різні функціональні можливості
та конструктивні міркування для створення розумних світильників.

Дизайн апаратного забезпечення базової системи ESP32-C3

Конструкція апаратного забезпечення основної системи ESP32-C3 включає живлення
живлення, послідовність увімкнення живлення, скидання системи, спалах SPI, джерело синхронізації,
і міркування щодо радіочастот і антени. Цей підрозділ передбачає
детальну інформацію про ці аспекти.

FAQ

З: Що таке ESP RainMaker?

A: ESP RainMaker – це хмарна платформа, яка надає інструменти
і послуги для створення та керування пристроями IoT. Це спрощує
процес розробки та дозволяє легко налаштувати пристрій, дистанційно
контроль і моніторинг.

Q: Як я можу налаштувати середовище розробки для
ESP32-C3?

A: Щоб налаштувати середовище розробки для ESP32-C3, вам потрібно
встановити ESP-IDF (Espressif IoT Development Framework) і
налаштуйте його відповідно до наданих інструкцій. ESP-IDF - це
офіційна структура розробки для пристроїв на основі ESP32.

З: Які функції ESP RainMaker?

A: ESP RainMaker пропонує різні функції, включно з користувацькими
керування, функції кінцевого користувача та функції адміністратора. Керування користувачами
дозволяє легко вимагати пристрою та синхронізувати дані. Кінцевий користувач
функції дозволяють дистанційно керувати пристроями через мобільний додаток або
web інтерфейс. Функції адміністратора надають інструменти для моніторингу пристрою
і управління.

View Fullscreen

ESP32-C3 Wireless Adventure
Вичерпний посібник з IoT
Espressif Systems 12 червня 2023 р

Зміст

I Підготовка

1 Вступ до IoT

1.1 Архітектура IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Застосування IoT у розумних будинках . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Введення та практика проектів IoT

2.1 Вступ до типових проектів IoT . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Базові модулі для звичайних пристроїв IoT . . . . . . . . . . . . . . . . . 9

2.1.2 Базові модулі клієнтських програм . . . . . . . . . . . . . . . . . . . 10

2.1.3 Вступ до поширених хмарних платформ IoT . . . . . . . . . . . . . . 11

2.2 Практика: проект Smart Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Структура проекту . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Функції проекту . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Підготовка обладнання . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Процес розробки . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Знайомство з ESP RainMaker

3.1 Що таке ESP RainMaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Впровадження ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Служба подання претензій . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 Агент RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 Cloud Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Налаштування середовища розробки

4.1 ESP-IDF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Версії ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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 Налаштування середовища розробки ESP-IDF у Linux . . . . . . . . 38 4.2.2 Налаштування середовища розробки ESP-IDF у Windows . . . . . . 40 4.2.3 Налаштування середовища розробки ESP-IDF на Mac . . . . . . . . . 45 4.2.4 Встановлення коду VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 Вступ до сторонніх середовищ розробки . . . . . . . . 46 4.3 Система компіляції ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 Основні поняття системи компіляції . . . . . . . . . . . . . . . . . . 47 4.3.2 Проект File Структура . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 Типові правила збирання системи компіляції . . . . . . . . . . . . . 50 4.3.4 Вступ до сценарію компіляції . . . . . . . . . . . . . . . . . . 51 4.3.5 Вступ до загальних команд . . . . . . . . . . . . . . . . . . . 52 4.4 Практика: складання впрampПрограма «Blink» . . . . . . . . . . . . . . . . . . 53 4.4.1 Прample Аналіз. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2 Компіляція програми Blink . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 Прошивка програми Blink . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Аналіз журналу послідовного порту програми Blink . . . . . . . . . . . . . . 60 4.5 Підсумок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

II Розробка обладнання та драйверів

5 Розробка апаратного забезпечення інтелектуальних світлових продуктів на основі ESP32-C3

5.1 Характеристики та склад продуктів Smart Light . . . . . . . . . . . . . . . 67

5.2 Конструкція апаратного забезпечення базової системи ESP32-C3 . . . . . . . . . . . . . . . . . . . 70

5.2.1 Джерело живлення . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2 Послідовність увімкнення та скидання системи . . . . . . . . . . . . . . . . . . 74

5.2.3 SPI Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.4 Джерело годинника . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.5 РЧ і антена . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.6 Стяжні шпильки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2.7 Контролер GPIO та ШІМ . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Практика: створення системи розумного освітлення за допомогою ESP32-C3. . . . . . . . . . . . . 80

5.3.1 Вибір модулів . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3.2 Налаштування GPIO для сигналів ШІМ . . . . . . . . . . . . . . . . . . . . 82

5.3.3 Завантаження мікропрограми та інтерфейс налагодження . . . . . . . . . . . . 82

5.3.4 Вказівки щодо розробки радіочастот . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 Рекомендації щодо проектування блоку живлення . . . . . . . . . . . . . . . . . . . 86 5.4 Підсумок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Розробка драйверів

6.1 Процес розробки драйвера . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 Периферійні програми ESP32-C3 . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Основи світлодіодного драйвера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.1 Кольорові простори . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2 Світлодіодний драйвер . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.3 Світлодіодне затемнення . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.4 Вступ до ШІМ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.4 Розробка драйвера світлодіодного затемнення . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 Енергонезалежне сховище (NVS) . . . . . . . . . . . . . . . . . . . . . . . . 97

6.4.2 Світлодіодний ШІМ-контролер (LEDC) . . . . . . . . . . . . . . . . . . . . . . . 98

6.4.3 ШІМ-програмування світлодіодів . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 Практика: додавання драйверів до проекту Smart Light . . . . . . . . . . . . . . . . . 103

6.5.1 Драйвер кнопки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5.2 Драйвер світлодіодного затемнення . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 SoftAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

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

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

7.3.5 Інші методи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.4 Програмування Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 Компоненти Wi-Fi в ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 Вправа: підключення Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 Вправа: інтелектуальне підключення Wi-Fi . . . . . . . . . . . . . . . . . . . . . 145
7.5 Практика: конфігурація Wi-Fi у проекті Smart Light . . . . . . . . . . . . . . . 156 7.5.1 Підключення Wi-Fi у проекті Smart Light . . . . . . . . . . . . . . . . . 156 7.5.2 Розумна конфігурація Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8 Місцевий контроль

159

8.1 Вступ до місцевого керування . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1.1 Застосування місцевого контролю . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.2 Додатковаtagмісцевого управління. . . . . . . . . . . . . . . . . . . . . . . . 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 Користувач Datagпротокол ram (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 Вступ до Datagram Безпека транспортного рівня (DTLS) . . . . . . . 213

8.5 Практика: локальне керування в проекті Smart Light . . . . . . . . . . . . . . . . . . 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 9.2.5 Налаштування посередника MQTT у Linux і Windows . . . . . . . . . . . . 233 9.2.6 Налаштування клієнта MQTT на основі ESP-IDF . . . . . . . . . . . . . . . . 235 9.3 Забезпечення безпеки даних MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.1 Значення та функції сертифікатів . . . . . . . . . . . . . . . . . . . 237 9.3.2 Створення сертифікатів локально . . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 Налаштування посередника MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 Налаштування клієнта MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.4 Практика: дистанційне керування через ESP RainMaker . . . . . . . . . . . . . . . . 243 9.4.1 Основи ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.2 Протокол зв’язку Node and Cloud Backend . . . . . . . . . . . 244 9.4.3 Зв’язок між клієнтом і хмарним сервером . . . . . . . . . . . 249 9.4.4 Ролі користувача . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 Основні служби . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.4.6 Smart Light Прample . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.7 Програма RainMaker і інтеграція сторонніх розробників . . . . . . . . . . . . . . . 262 9.5 Підсумок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

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 Вступ до API RainMaker . . . . . . . . . . . . . . . . . . . . . . 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 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 10.7.3 Більше хмарних API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.8 Підсумок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

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) Прample . . . . . . . . . . . . . . . . . . . . . . . 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 Практика: керування живленням у проекті Smart Light . . . . . . . . . . . . . . . 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 Прикладample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3 Захист конфіденційності даних . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.1 Вступ до шифрування даних . . . . . . . . . . . . . . . . . . . . . . 374

13.3.2 Вступ до схеми шифрування Flash . . . . . . . . . . . . . . . . . 376

13.3.3 Зберігання ключів шифрування Flash . . . . . . . . . . . . . . . . . . . . . . . 379

13.3.4 Робочий режим Flash Encryption . . . . . . . . . . . . . . . . . . . . 380

13.3.5 Процес шифрування Flash . . . . . . . . . . . . . . . . . . . . . . . . . . 381

13.3.6 Вступ до шифрування NVS . . . . . . . . . . . . . . . . . . . . . . 383

13.3.7 Прикладampфайли Flash Encryption і NVS Encryption. . . . . . . . . . . 384

13.4 Захист законності даних . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.1 Введення в цифровий підпис . . . . . . . . . . . . . . . . . . . . . 386

13.4.2 Завершеноview схеми безпечного завантаження. . . . . . . . . . . . . . . . . . . . . 388

13.4.3 Введення в програмне забезпечення безпечного завантаження . . . . . . . . . . . . . . . . . . . 388 13.4.4 Вступ до апаратного безпечного завантаження . . . . . . . . . . . . . . . . . . 390 13.4.5 Прampлес . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 13.5 Практика: засоби безпеки в масовому виробництві . . . . . . . . . . . . . . . . . . 396 13.5.1 Флеш-шифрування та безпечне завантаження . . . . . . . . . . . . . . . . . . . . . 396 13.5.2 Увімкнення шифрування флеш-пам’яті та безпечного завантаження за допомогою інструментів пакетного флеш-пам’яті . . 397 13.5.3 Увімкнення флеш-шифрування та безпечного завантаження в проекті Smart Light . . . 398 13.6 Підсумок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

14 Запис мікропрограми та тестування для масового виробництва

399

14.1 Запис мікропрограм у масовому виробництві . . . . . . . . . . . . . . . . . . . . . . 399

14.1.1 Визначення розділів даних . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.2 Запис мікропрограми . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

14.2 Тестування масового виробництва . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

14.3 Практика: дані масового виробництва в проекті Smart Light . . . . . . . . . . . . . 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 Запуск Exampу проекті esp-insights. . . . . . . . . . . . . . . 411

15.2.3 Повідомлення інформації Coredump . . . . . . . . . . . . . . . . . . . . . 411

15.2.4 Налаштування цікавих журналів . . . . . . . . . . . . . . . . . . . . . . . . 412

15.2.5 Повідомлення про причину перезавантаження . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.2.6 Звітування про спеціальні показники . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.3 Практика: використання ESP Insights у проекті Smart Light . . . . . . . . . . . . . . . 416

15.4 Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

вступ
ESP32-C3 — це одноядерна мікроконтролерна SoC Wi-Fi і Bluetooth 5 (LE), заснована на архітектурі RISC-V з відкритим кодом. Він забезпечує правильний баланс потужності, можливостей введення/виведення та безпеки, пропонуючи таким чином оптимальне економічно ефективне рішення для підключених пристроїв. Щоб показати різні додатки сімейства ESP32-C3, ця книга від Espressif проведе вас у цікавій подорожі AIoT, починаючи від основ розробки проектів IoT і налаштування середовища до практичнихampлес. Перші чотири розділи розповідають про IoT, ESP RainMaker і ESP-IDF. Розділи 5 і 6 коротко описують апаратне забезпечення та розробку драйверів. У міру просування ви дізнаєтеся, як налаштувати свій проект через мережі Wi-Fi і мобільні програми. Нарешті, ви навчитеся оптимізувати свій проект і запустити його в масове виробництво.
Якщо ви інженер у суміжних галузях, архітектор програмного забезпечення, викладач, студент або хтось, хто цікавиться IoT, ця книга для вас.
Ви можете завантажити код напрample, використаний у цій книзі, із сайту Espressif на GitHub. Для отримання найновішої інформації про розвиток IoT, будь ласка, стежте за нашим офіційним обліковим записом.

Передмова
Інформатизований світ
На хвилі Інтернету відбувся грандіозний дебют Інтернету речей (IoT), який став новим типом інфраструктури в цифровій економіці. Щоб зробити технологію ближчою до громадськості, Espressif Systems працює над баченням того, що розробники з усіх верств суспільства можуть використовувати IoT для вирішення деяких із найактуальніших проблем нашого часу. Світ «розумної мережі всього» — це те, чого ми очікуємо від майбутнього.
Розробка власних чіпів є критично важливим компонентом цього бачення. Це буде марафон, який вимагатиме постійних проривів через технологічні межі. Від «Game Changer» ESP8266 до серії ESP32 із підключенням Wi-Fi та Bluetoothr (LE), а потім ESP32-S3 із прискоренням штучного інтелекту, Espressif не припиняє досліджувати та розробляти продукти для рішень AIoT. За допомогою нашого програмного забезпечення з відкритим кодом, такого як IoT Development Framework ESP-IDF, Mesh Development Framework ESP-MDF і Device Connectivity Platform ESP RainMaker, ми створили незалежну структуру для створення програм AIoT.
Станом на липень 2022 року сукупні поставки чіпсетів IoT від Espressif перевищили 800 мільйонів, що є лідером на ринку Wi-Fi MCU та забезпечує живлення величезної кількості підключених пристроїв у всьому світі. Прагнення до досконалості робить кожен продукт Espressif великим успіхом завдяки високому рівню інтеграції та економічній ефективності. Випуск ESP32-C3 знаменує собою важливу віху в технології власної розробки Espressif. Це одноядерний 32-розрядний MCU на основі RISC-V з 400 КБ SRAM, який може працювати на частоті 160 МГц. Він має інтегрований Wi-Fi 2.4 ГГц і Bluetooth 5 (LE) з підтримкою дальнього радіусу дії. Він забезпечує чудовий баланс потужності, можливостей введення/виведення та безпеки, пропонуючи таким чином оптимальне економічно ефективне рішення для підключених пристроїв. Заснована на такому потужному ESP32-C3, ця книга має на меті допомогти читачам зрозуміти знання, пов’язані з IoT, за допомогою докладних ілюстрацій і практичних прикладів.ampлес.
Чому ми написали цю книгу?
Espressif Systems — це більше, ніж напівпровідникова компанія. Це також компанія-платформа IoT, яка завжди прагне до проривів та інновацій у сфері технологій. У той же час Espressif відкрив вихідний код і надав спільноті свою власно розроблену операційну систему та програмне забезпечення, сформувавши унікальну екосистему. Інженери, виробники та ентузіасти технологій активно розробляють нові програмні додатки на основі продуктів Espressif, вільно спілкуються та діляться досвідом. Ви можете постійно бачити захоплюючі ідеї розробників на різних платформах, таких як YouTube і GitHub. Популярність продуктів Espressif стимулювала зростання кількості авторів, які написали понад 100 книг на основі чіпсетів Espressif більш ніж десятьма мовами, включаючи англійську, китайську, німецьку, французьку та японську.

Саме підтримка та довіра партнерів спільноти заохочують Espressif до постійних інновацій. «Ми прагнемо зробити наші чіпи, операційні системи, фреймворки, рішення, хмару, бізнес-практики, інструменти, документацію, тексти, ідеї тощо все більш актуальними для відповідей, які потрібні людям для найактуальніших проблем сучасного життя. Це найвища амбіція та моральний компас Espressif». сказав пан Тео Сві Енн, засновник і генеральний директор Espressif.
Espressif цінує читання та ідеї. Оскільки постійна модернізація технології Інтернету речей висуває все більші вимоги до інженерів, як ми можемо допомогти більшій кількості людей швидко освоїти мікросхеми Інтернету речей, операційні системи, програмні інфраструктури, схеми додатків і продукти хмарних сервісів? Як кажуть, краще навчити людину ловити рибу, ніж дати їй рибу. Під час мозкового штурму нам прийшло в голову, що ми могли б написати книгу, щоб систематично відсортувати ключові знання про розробку IoT. Ми дійшли згоди, швидко зібрали групу старших інженерів і об’єднали досвід технічної команди у сфері вбудованого програмування, розробки обладнання та програмного забезпечення IoT, усі вони сприяли публікації цієї книги. У процесі написання ми намагалися бути об’єктивними та справедливими, позбавившись коконів, і використовували стислі вирази, щоб розповісти про складність і чарівність Інтернету речей. Ми ретельно резюмували загальні запитання, посилаючись на відгуки та пропозиції спільноти, щоб чітко відповісти на запитання, що виникають у процесі розробки, і надати практичні вказівки щодо розробки IoT для відповідних технічних спеціалістів і осіб, які приймають рішення.
Структура книги
Ця книга розглядає інженерно-орієнтовану перспективу та крок за кроком викладає необхідні знання для розробки проекту IoT. Він складається з чотирьох частин, а саме:
· Підготовка (Розділ 1): у цій частині представлено архітектуру IoT, типову структуру проекту IoT, хмарну платформу ESP RainMakerr і середовище розробки ESP-IDF, щоб закласти міцну основу для розробки проекту IoT.
· Розробка апаратного забезпечення та драйвера (розділ 5): у цій частині, заснованій на чіпсеті ESP6-C32, докладно розглядається мінімальна апаратна система та розробка драйвера, а також реалізовано керування затемненням, градацією кольору та бездротовим зв’язком.
· Бездротовий зв’язок і керування (Розділ 7): у цій частині пояснюється інтелектуальна схема конфігурації Wi-Fi на основі мікросхеми ESP11-C32, локальних і хмарних протоколів керування, а також локального й дистанційного керування пристроями. Він також надає схеми для розробки програм для смартфонів, оновлення мікропрограми та керування версіями.
· Оптимізація та масове виробництво (розділи 12-15): ця частина призначена для розширених додатків IoT, зосереджена на оптимізації продуктів у сфері керування живленням, оптимізації низького споживання та підвищеної безпеки. Він також знайомить із записом і тестуванням мікропрограм у масовому виробництві, а також про те, як діагностувати поточний стан і журнали мікропрограми пристрою за допомогою платформи віддаленого моніторингу ESP Insights.

Про вихідний код
Читачі можуть запустити ексampпрограми в цій книзі, ввівши код вручну або використовуючи вихідний код, який супроводжує книгу. Ми наголошуємо на поєднанні теорії та практики, тому майже в кожному розділі встановлюємо практичний розділ на основі проекту Smart Light. Усі коди є відкритими. Читачі можуть завантажити вихідний код і обговорити його в розділах, пов’язаних із цією книгою, на GitHub і на нашому офіційному форумі esp32.com. Код цієї книги з відкритим вихідним кодом регулюється умовами ліцензії Apache 2.0.
Примітка автора
Ця книга офіційно виготовлена компанією Espressif Systems і написана старшими інженерами компанії. Він підходить для керівників і дослідницького персоналу в галузях, пов’язаних з Інтернетом речей, викладачів і студентів суміжних спеціальностей, а також для ентузіастів у сфері Інтернету речей. Сподіваємося, що ця книжка може слугувати і посібником для роботи, і довідником, і приліжковою книжкою, бути хорошим вихователем і другом.
Під час укладання цієї книги ми посилалися на деякі відповідні результати досліджень експертів, учених і техніків у країні та за кордоном, і ми зробили все можливе, щоб цитувати їх відповідно до академічних норм. Однак неминуче буде деяких пропусків, тому тут ми хотіли б висловити нашу глибоку повагу та вдячність усім відповідним авторам. Крім того, ми процитували інформацію з Інтернету, тому ми хотіли б подякувати оригінальним авторам і видавцям і принести вибачення, що ми не можемо вказати джерело кожної інформації.
Щоб випустити книгу високої якості, ми організували раунди внутрішніх обговорень і вчилися з пропозицій і відгуків пробних читачів і редакторів видавництва. Тут ми хотіли б ще раз подякувати вам за вашу допомогу, яка сприяла цій успішній роботі.
Нарешті, але найголовніше, подяка всім в Espressif, хто так багато працював для народження та популяризації наших продуктів.
Розробка IoT-проектів передбачає широкий спектр знань. Обмежуючись довжиною книги, а також рівнем і досвідом автора, пропусків не уникнути. Тому просимо експертів і читачів критикувати та виправляти наші помилки. Якщо у вас є пропозиції щодо цієї книги, зв’яжіться з нами за адресою book@espressif.com. Ми з нетерпінням чекаємо ваших відгуків.

Як користуватися цією книгою?
Код проектів у цій книзі є відкритим. Ви можете завантажити його з нашого репозиторію GitHub і поділитися своїми думками та запитаннями на нашому офіційному форумі. GitHub: https://github.com/espressif/book-esp32c3-iot-projects Форум: https://www.esp32.com/bookc3 У книзі будуть виділені частини, як показано нижче.
Вихідний код У цій книзі ми наголошуємо на поєднанні теорії та практики, тому майже в кожній главі міститься практичний розділ про проект Smart Light. Відповідні кроки та вихідна сторінка будуть позначені між двома рядками, що починаються з tag Вихідний код.
ПРИМІТКИ/ПОРАДИ Тут ви можете знайти важливу інформацію та нагадування для успішного налагодження вашої програми. Вони будуть позначені між двома товстими лініями, що починаються з tag ПРИМІТКА або ПОРАДИ.
Більшість команд у цій книзі виконуються в Linux, підказуючи символом «$». Якщо для виконання команди потрібні права суперкористувача, запит буде замінено на «#». Командний рядок на системах Mac — «%», як використовується в Розділі 4.2.3 Встановлення ESP-IDF на Mac.
Основний текст у цій книзі буде надруковано в Хартії, тоді як код exampфайли, компоненти, функції, змінні, код file імена, каталоги кодів і рядки будуть у Courier New.
Команди або тексти, які має ввести користувач, а також команди, які можна ввести, натиснувши клавішу «Enter», будуть надруковані Courier New жирним шрифтом. Журнали та кодові блоки будуть представлені в світло-блакитних коробках.
Exampле:
По-друге, використовуйте esp-idf/components/nvs flash/nvs partition generator/nvs partition gen.py, щоб створити двійковий файл розділу NVS file на хості розробки за допомогою такої команди:
$ python $IDF PATH/components/nvs flash/nvs partition generator/nvs partition gen.py – вхідна маса prod.csv – вихідна маса prod.bin – розмір РОЗМІР РОЗДІЛУ NVS

Глава 1

вступ

до

IoT

Наприкінці 20 століття, з розвитком комп’ютерних мереж і комунікаційних технологій, Інтернет швидко інтегрувався в життя людей. Оскільки Інтернет-технології продовжують розвиватися, народилася ідея Інтернету речей (IoT). Буквально IoT означає Інтернет, де речі підключені. У той час як оригінальний Інтернет розриває межі простору та часу та звужує відстань між «особою та людиною», IoT робить «речі» важливим учасником, зближуючи «людей» і «речі». У найближчому майбутньому IoT стане рушійною силою інформаційної індустрії.
Отже, що таке Інтернет речей?
Важко дати точне визначення Інтернету речей, оскільки його значення та масштаби постійно змінюються. У 1995 році Білл Гейтс вперше висловив ідею IoT у своїй книзі «Дорога вперед». Простіше кажучи, IoT дозволяє об'єктам обмінюватися інформацією один з одним через Інтернет. Його кінцевою метою є створення «Інтернету всього». Це рання інтерпретація IoT, а також фантазія технологій майбутнього. Тридцять років потому, зі стрімким розвитком економіки та технологій, фантазія втілюється в реальність. Від розумних пристроїв, розумних будинків, розумних міст, Інтернету транспортних засобів і переносних пристроїв до «метавсесвіту», що підтримується технологіями IoT, постійно з’являються нові концепції. У цьому розділі ми почнемо з пояснення архітектури Інтернету речей, а потім представимо найпоширенішу програму IoT, розумний дім, щоб допомогти вам отримати чітке розуміння IoT.
1.1 Архітектура IoT
Інтернет речей передбачає численні технології, які мають різні потреби та форми застосування в різних галузях. Щоб розібратися в структурі, ключових технологіях і прикладних характеристиках IoT, необхідно створити уніфіковану архітектуру і стандартну технічну систему. У цій книзі архітектура IoT просто розділена на чотири рівні: рівень сприйняття та контролю, рівень мережі, рівень платформи та рівень додатків.
Рівень сприйняття та контролю Як найпростіший елемент архітектури IoT, рівень сприйняття та контролю є ядром для реалізації комплексного визначення IoT. Його основна функція — збір, ідентифікація та контроль інформації. Він складається з різноманітних пристроїв зі здатністю сприйняття,
3

ідентифікація, контроль і виконання, а також відповідає за отримання та аналіз даних, таких як властивості матеріалів, тенденції поведінки та стан пристрою. Таким чином IoT розпізнає реальний фізичний світ. Крім того, рівень також може контролювати стан пристрою.
Найпоширенішими пристроями цього шару є різні датчики, які відіграють важливу роль у зборі та ідентифікації інформації. Датчики схожі на органи чуття людини, наприклад світлочутливі сенсори, що відповідають зору, акустичні датчики – слуху, газові датчики – нюху, а датчики, чутливі до тиску та температури – дотику. З усіма цими «органами чуття» об’єкти стають «живими» і здатними до розумного сприйняття, розпізнавання та маніпулювання фізичним світом.
Мережевий рівень Основною функцією мережевого рівня є передача інформації, включно з даними, отриманими від рівня сприйняття та контролю, до визначеної цілі, а також команд, виданих із прикладного рівня, назад до рівня сприйняття та контролю. Він служить важливим комунікаційним мостом, що з’єднує різні рівні системи IoT. Щоб налаштувати базову модель Інтернету речей, потрібно виконати два кроки для інтеграції об’єктів у мережу: доступ до Інтернету та передача через Інтернет.
Доступ до Інтернету Інтернет забезпечує взаємозв'язок між людьми, але не може включити речі у велику родину. До появи IoT більшість речей не були «мережевими». Завдяки постійному розвитку технологій IoT вдається підключати речі до Інтернету, таким чином реалізуючи взаємозв’язок між «людьми та речами» та «речами та речами». Існує два поширених способи реалізації підключення до Інтернету: дротовий доступ до мережі та бездротовий доступ до мережі.
Методи доступу до дротової мережі включають Ethernet, послідовний зв’язок (наприклад, RS-232, RS-485) і USB, тоді як доступ до бездротової мережі залежить від бездротового зв’язку, який можна далі розділити на бездротовий зв’язок малого радіусу дії та бездротовий зв’язок великої дальності.
Бездротовий зв’язок малого радіусу дії включає ZigBee, Bluetoothr, Wi-Fi, зв’язок ближнього поля (NFC) і радіочастотну ідентифікацію (RFID). Бездротовий зв’язок великої відстані включає розширений зв’язок машинного типу (eMTC), LoRa, вузькосмуговий Інтернет речей (NB-IoT), 2G, 3G, 4G, 5G тощо.
Передача через Інтернет Різні методи доступу до Інтернету призводять до відповідного фізичного каналу передачі даних. Наступне – вирішити, який протокол зв’язку використовувати для передачі даних. У порівнянні з Інтернет-терміналами більшість терміналів IoT наразі мають менше
4 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

доступні ресурси, такі як продуктивність обробки, ємність зберігання, швидкість мережі тощо, тому необхідно вибрати протокол зв’язку, який займає менше ресурсів у додатках IoT. Існує два протоколи зв’язку, які широко використовуються сьогодні: Message Queuing Telemetry Transport (MQTT) і Constrained Application Protocol (CoAP).
Рівень платформи Рівень платформи в основному відноситься до хмарних платформ IoT. Коли всі термінали IoT об’єднані в мережу, їхні дані потрібно агрегувати на хмарній платформі IoT, щоб обчислювати та зберігати. Рівень платформи в основному підтримує програми IoT для полегшення доступу та керування масивними пристроями. Він підключає термінали IoT до хмарної платформи, збирає дані терміналів і видає команди терміналам, щоб реалізувати віддалене керування. Як проміжний сервіс для призначення обладнання галузевим додаткам, рівень платформи відіграє сполучну роль у всій архітектурі IoT, несучи абстрактну бізнес-логіку та стандартизовану основну модель даних, яка може не тільки реалізувати швидкий доступ до пристроїв, але й надати потужні модульні можливості. для задоволення різноманітних потреб у галузевих сценаріях застосування. Рівень платформи в основному включає такі функціональні модулі, як доступ до пристрою, керування пристроєм, керування безпекою, передача повідомлень, моніторинг роботи та обслуговування, а також програми даних.
· Доступ до пристрою, реалізуючи зв'язок і зв'язок між терміналами та хмарними платформами IoT.
· Керування пристроєм, включаючи такі функції, як створення пристрою, обслуговування пристрою, перетворення даних, синхронізація даних і розподіл пристроїв.
· Управління безпекою, забезпечення безпеки передачі даних IoT з точки зору аутентифікації безпеки та безпеки зв’язку.
· Передача повідомлень, включаючи три напрямки передачі, тобто термінал надсилає дані на хмарну платформу IoT, хмарна платформа IoT надсилає дані на сторону сервера або інші хмарні платформи IoT, а сторона сервера віддалено керує пристроями IoT.
· Моніторинг експлуатації та технічного обслуговування, включаючи моніторинг і діагностику, оновлення мікропрограми, онлайн-налагодження, служби журналу тощо.
· Застосування даних, що включає зберігання, аналіз і застосування даних.
Рівень програми Рівень програми використовує дані з рівня платформи для керування програмою, фільтруючи та обробляючи їх за допомогою таких інструментів, як бази даних і програмне забезпечення для аналізу. Отримані дані можна використовувати для реальних додатків Інтернету речей, таких як розумна охорона здоров’я, розумне сільське господарство, розумні будинки та розумні міста.
Звичайно, архітектуру IoT можна розділити на кілька рівнів, але незалежно від кількості рівнів, з яких вона складається, основний принцип залишається незмінним. навчання
Розділ 1. Введення в IoT 5

про архітектуру IoT допомагає поглибити наше розуміння технологій IoT і створювати повнофункціональні проекти IoT.
1.2 Застосування Інтернету речей у розумних будинках
IoT проник у всі сфери життя, і найбільш тісно пов’язаною з IoT програмою для нас є розумний дім. Багато традиційних пристроїв тепер оснащені одним або декількома пристроями Інтернету речей, а багато новозбудованих будинків проектуються з використанням технологій Інтернету речей із самого початку. На малюнку 1.1 показано деякі поширені пристрої розумного дому.
Малюнок 1.1. Поширені пристрої розумного будинку Розробку розумного будинку можна просто розділити на розумні продуктиtage, взаємозв'язок сцен stage та інтелектуальний stage, як показано на малюнку 1.2.
Малюнок 1.2. Розвиток сtagРозумний дім 6 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Перший сtage про розумні продукти. На відміну від традиційних будинків, у розумних будинках пристрої IoT отримують сигнали за допомогою датчиків і підключаються до мережі за допомогою технологій бездротового зв’язку, таких як Wi-Fi, Bluetooth LE і ZigBee. Користувачі можуть керувати інтелектуальними продуктами різними способами, такими як програми для смартфонів, голосові помічники, розумні динаміки тощо.tage фокусується на взаємозв’язку сцен. У цьому сtage, розробники більше не розглядають можливість керування одним розумним продуктом, а об’єднують два або більше розумних продуктів, до певної міри автоматизують і, нарешті, формують спеціальний режим сцени. наприкладample, коли користувач натискає будь-яку кнопку сюжетного режиму, освітлення, штори та кондиціонери автоматично адаптуються до попередніх налаштувань. Звичайно, існує передумова, щоб логіка зв’язку була легко налаштована, включаючи умови запуску та дії виконання. Уявіть, що режим обігріву кондиціонера спрацьовує, коли температура в приміщенні опускається нижче 10°C; що о сьомій ранку грає музика, щоб розбудити користувача, відкриваються розумні штори, а рисоварка чи тостер запускаються через розумну розетку; коли користувач встає і закінчує прання, сніданок уже подається, тому не буде затримки з виходом на роботу. Яким зручним стало наше життя! Третя сtage переходить до розвідки stagд. З більшою кількістю доступу до розумних домашніх пристроїв змінюватимуться й типи даних, що генеруються. Завдяки хмарним обчисленням, великим даним і штучному інтелекту в розумні будинки, які більше не потребують частих команд від користувача, впровадили «розумніший мозок». Вони збирають дані з попередніх взаємодій і вивчають моделі поведінки та вподобання користувача, щоб автоматизувати дії, включаючи надання рекомендацій для прийняття рішень. Наразі більшість розумних будинків знаходяться на сцені взаємозв’язкуtagд. У міру зростання рівня проникнення та інтелектуальних можливостей розумних продуктів усуваються бар’єри між протоколами зв’язку. У майбутньому розумні будинки неодмінно стануть дійсно «розумними», як система штучного інтелекту Джарвіса в «Залізній людині», яка може не тільки допомагати користувачеві керувати різними пристроями, вирішувати повсякденні справи, а й мати надвисоку обчислювальну потужність і здатність до мислення. У інтелігентному сtagд, люди отримають кращі послуги як за кількістю, так і за якістю.
Розділ 1. Введення в IoT 7

8 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Розділ Введення та практика 2 проектів IoT
У розділі 1 ми представили архітектуру IoT, ролі та взаємозв’язки рівня сприйняття та контролю, мережевого рівня, рівня платформи та рівня додатків, а також розробку розумного дому. Однак, як і коли ми вчимося малювати, теоретичних знань далеко недостатньо. Нам потрібно «забруднити руки», щоб реалізувати проекти IoT на практиці, щоб по-справжньому оволодіти технологією. Крім того, коли проект переходить до масового виробництва stage, необхідно враховувати більше факторів, таких як підключення до мережі, конфігурація, взаємодія з хмарною платформою IoT, керування програмним забезпеченням та оновленнями, керування масовим виробництвом і конфігурація безпеки. Отже, на що нам потрібно звернути увагу при розробці повного проекту IoT? У розділі 1 ми згадували, що розумний дім є одним із найпоширеніших сценаріїв застосування IoT, а розумні світильники є одним із найпростіших і практичних приладів, які можна використовувати в будинках, готелях, спортзалах, лікарнях тощо. У цій книзі ми візьмемо за відправну точку створення проекту інтелектуального освітлення, пояснимо його компоненти та особливості та надамо вказівки щодо розробки проекту. Ми сподіваємося, що ви зможете зробити висновки з цього випадку, щоб створити більше додатків IoT.
2.1 Вступ до типових проектів IoT
З точки зору розробки, основні функціональні модулі проектів IoT можна класифікувати на розробку програмного та апаратного забезпечення пристроїв IoT, розробку клієнтських додатків і розробку хмарної платформи IoT. Важливо уточнити основні функціональні модулі, які будуть описані далі в цьому розділі.
2.1.1 Базові модулі для звичайних пристроїв IoT
Розробка програмного та апаратного забезпечення пристроїв IoT включає такі основні модулі: Збір даних
Будучи нижнім рівнем архітектури IoT, пристрої IoT рівня сприйняття та контролю з’єднують датчики та пристрої через їхні чіпи та периферійні пристрої для досягнення збору даних і керування роботою.
9

Прив’язка облікового запису та початкова конфігурація Для більшості пристроїв IoT прив’язка облікового запису та початкова конфігурація завершуються в одному робочому процесі, напр.ample, підключення пристроїв до користувачів шляхом налаштування мережі Wi-Fi.
Взаємодія з хмарними платформами IoT Для моніторингу та керування пристроями IoT також необхідно підключити їх до хмарних платформ IoT, щоб передавати команди та повідомляти про статус через взаємодію один з одним.
Управління пристроєм При підключенні до хмарних платформ IoT пристрої можуть обмінюватися даними з хмарою та реєструватися, прив’язуватися або керуватися. Користувачі можуть запитувати статус продукту та виконувати інші операції в додатку для смартфона через хмарні платформи IoT або локальні протоколи зв’язку.
Оновлення мікропрограми Пристрої IoT також можуть оновлювати мікропрограму відповідно до потреб виробників. За допомогою отримання команд, надісланих хмарою, буде реалізовано оновлення прошивки та керування версіями. За допомогою цієї функції оновлення мікропрограми ви можете постійно вдосконалювати функції пристроїв IoT, виправляти дефекти та покращувати взаємодію з користувачем.
2.1.2 Базові модулі клієнтських програм
Клієнтські програми (наприклад, програми для смартфонів) включають в основному такі базові модулі:
Система облікових записів і авторизація Підтримує облікові записи та авторизацію пристроїв.
Керування пристроєм Програми для смартфонів зазвичай оснащені функціями керування. Користувачі можуть легко підключатися до пристроїв IoT і керувати ними в будь-який час і в будь-якому місці за допомогою програм для смартфонів. У реальному розумному домі пристроями здебільшого керують за допомогою додатків для смартфонів, що не тільки дозволяє інтелектуально керувати пристроями, але й економить витрати на робочу силу. Таким чином, керування пристроєм є обов’язковим для клієнтських програм, таких як керування атрибутами функцій пристрою, керування сценою, планування, дистанційне керування, підключення пристроїв тощо. Користувачі розумного дому також можуть налаштовувати сцени відповідно до особистих потреб, керуючи освітленням, побутовою технікою, входом , тощо, щоб зробити домашнє життя комфортнішим і зручнішим. Вони можуть запрограмувати час роботи кондиціонера, вимкнути його дистанційно, автоматично ввімкнути світло в коридорі, коли двері відчинено, або перемкнути в режим «театр» однією кнопкою.
Клієнтські програми сповіщень оновлюють статус пристроїв IoT у режимі реального часу та надсилають сповіщення, коли пристрої виходять з ладу.
10 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Післяпродажне обслуговування клієнтів Додатки для смартфонів можуть надавати післяпродажне обслуговування продуктів, щоб своєчасно вирішувати проблеми, пов’язані зі збоями пристроїв Інтернету речей і технічними операціями.
Рекомендовані функції Щоб задовольнити потреби різних користувачів, можна додати інші функції, такі як струшування, NFC, GPS тощо. GPS може допомогти встановити точність операцій зі сценою відповідно до розташування та відстані, тоді як функція струшування дозволяє користувачам установлювати команди, які слід виконувати для певного пристрою або сцени струшуванням.
2.1.3 Вступ до поширених хмарних платформ IoT
Хмарна платформа IoT — це комплексна платформа, яка об’єднує такі функції, як керування пристроями, зв’язок безпеки даних і керування сповіщеннями. За цільовою групою та доступністю хмарні платформи IoT можна розділити на публічні хмарні платформи IoT (далі – «публічна хмара») та приватні хмарні платформи IoT (далі – «приватна хмара»).
Загальнодоступна хмара зазвичай вказує на спільні хмарні платформи IoT для підприємств або окремих осіб, якими керують і обслуговують постачальники платформ, а також спільно використовують через Інтернет. Він може бути безкоштовним або недорогим і надавати послуги у відкритій загальнодоступній мережі, як-от Alibaba Cloud, Tencent Cloud, Baidu Cloud, AWS IoT, Google IoT тощо. Як допоміжна платформа, публічна хмара може інтегрувати постачальників вищих послуг і нижчі кінцеві користувачі для створення нового ланцюга створення вартості та екосистеми.
Приватна хмара створена лише для корпоративного використання, що гарантує найкращий контроль над даними, безпекою та якістю обслуговування. Його служби та інфраструктура обслуговуються окремо підприємствами, а допоміжне обладнання та програмне забезпечення також призначені для конкретних користувачів. Підприємства можуть налаштувати хмарні сервіси відповідно до потреб свого бізнесу. На даний момент деякі виробники розумного будинку вже отримали приватні хмарні платформи IoT і розробили на їх основі додатки для розумного будинку.
Публічна та приватна хмара мають свої перевагиtages, що буде пояснено пізніше.
Щоб досягти комунікаційного зв’язку, необхідно завершити принаймні вбудовану розробку на стороні пристрою, а також бізнес-сервери, хмарні платформи IoT і програми для смартфонів. Зустрічаючись із таким величезним проектом, публічна хмара зазвичай надає набори для розробки програмного забезпечення для додатків на пристрої та смартфонах, щоб пришвидшити процес. Як публічна, так і приватна хмара надають послуги, включаючи доступ до пристроїв, керування пристроями, тіньовий доступ до пристроїв, а також експлуатацію та обслуговування.
Доступ до пристроїв Хмарні платформи IoT повинні надавати не лише інтерфейси для доступу до пристроїв за допомогою протоколів
Розділ 2. Введення та практика проектів IoT 11

такі як MQTT, CoAP, HTTPS і WebРозетка, а також функція автентифікації безпеки пристрою для блокування підроблених і нелегальних пристроїв, ефективно знижуючи ризик зламу. Така автентифікація зазвичай підтримує різні механізми, тому, коли пристрої масово виробляються, необхідно попередньо призначити сертифікат пристрою відповідно до вибраного механізму автентифікації та записати його в пристрої.
Управління пристроєм Функція керування пристроєм, яка надається хмарними платформами IoT, може не тільки допомогти виробникам відстежувати стан активації та онлайн-статус їхніх пристроїв у режимі реального часу, але й дозволяє такі опції, як додавання/видалення пристроїв, отримання, додавання/видалення груп, оновлення мікропрограми і керування версіями.
Тінь пристрою Хмарні платформи IoT можуть створювати постійну віртуальну версію (тінь пристрою) для кожного пристрою, а стан тіні пристрою можна синхронізувати та отримувати програмою для смартфона або іншими пристроями через протоколи передачі Інтернету. Device shadow зберігає останній повідомлений статус і очікуваний статус кожного пристрою, і навіть якщо пристрій офлайн, він все одно може отримати статус, викликавши API. Device shadow забезпечує постійні API, що полегшує створення програм для смартфонів, які взаємодіють із пристроями.
Експлуатація та технічне обслуговування Функція O&M включає три аспекти: · Демонстрація статистичної інформації про пристрої та сповіщення IoT. · Керування журналами дозволяє отримувати інформацію про поведінку пристрою, потік повідомлень вгору/вниз і вміст повідомлень. · Налагодження пристрою підтримує доставку команд, оновлення конфігурації та перевірку взаємодії між хмарними платформами IoT і повідомленнями пристрою.
2.2 Практика: Проект Smart Light
Після теоретичного вступу в кожному розділі ви знайдете практичний розділ, пов’язаний із проектом Smart Light, який допоможе вам отримати практичний досвід. Проект базується на чіпі ESP32-C3 Espressif і хмарній платформі ESP RainMaker IoT і охоплює апаратне забезпечення бездротового модуля в продуктах розумного освітлення, вбудоване програмне забезпечення для розумних пристроїв на основі ESP32C3, програми для смартфонів і взаємодію з ESP RainMaker.
Вихідний код Для кращого навчання та розробки проект у цій книзі має відкритий код. Ви можете завантажити вихідний код із нашого репозиторію GitHub за адресою https://github. com/espressif/book-esp32c3-iot-projects.
12 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

2.2.1 Структура проекту
Проект Smart Light складається з трьох частин: i. Розумні освітлювальні пристрої на базі ESP32-C3, що відповідають за взаємодію з хмарними платформами IoT і контролюють перемикач, яскравість і колірну температуру світлодіода lamp намистини. ii. Програми для смартфонів (включно з програмами для планшетів, що працюють на Android та iOS), що відповідають за конфігурацію мережі інтелектуальних світильників, а також запитують і контролюють їхній статус.
iii. Хмарна платформа IoT на основі ESP RainMaker. Для спрощення в цій книзі ми розглядаємо хмарну платформу IoT і бізнес-сервер як єдине ціле. Докладні відомості про ESP RainMaker будуть надані в розділі 3.
Відповідність між структурою проекту Smart Light та архітектурою IoT показано на рисунку 2.1.
Малюнок 2.1. Структура проекту розумного світла
2.2.2 Функції проекту
Розділені відповідно до структури, функції кожної частини наступні. Розумні світлові прилади
· Конфігурація мережі та підключення. · Світлодіодне керування ШІМ, наприклад, перемикач, яскравість, колірна температура тощо. · Автоматизація або керування сценою, наприклад, таймер. · Шифрування та безпечне завантаження Flash. · Оновлення прошивки та керування версіями.
Розділ 2. Введення та практика проектів IoT 13

Програми для смартфонів · Конфігурація мережі та прив’язка пристрою. · Інтелектуальне керування світловим продуктом, наприклад перемикач, яскравість, колірна температура тощо. · Автоматизація або налаштування сцени, наприклад, таймер. · Місцеве/дистанційне керування. · Реєстрація користувача, вхід і т.д.
Хмарна платформа ESP RainMaker IoT · Увімкнення доступу до пристроїв IoT. · Надання API роботи пристрою, доступних для програм смартфона. · Оновлення прошивки та керування версіями.
2.2.3 Підготовка обладнання
Якщо ви зацікавлені в реалізації проекту, вам також знадобиться наступне обладнання: розумні світильники, смартфони, маршрутизатори Wi-Fi та комп’ютер, який відповідає вимогам до встановлення середовища розробки. Розумні світильники
Розумні світильники — це новий тип лампочок, форма яких така ж, як і звичайна лампочка розжарювання. Розумний світильник складається з конденсаторного понижувального регульованого джерела живлення, бездротового модуля (з вбудованим ESP32-C3), світлодіодного контролера та світлодіодної матриці RGB. При підключенні до джерела живлення 15 В постійного струму обtagВихід e після зниження конденсатора, діодного випрямлення та регулювання забезпечує енергією світлодіодний контролер і світлодіодну матрицю. Світлодіодний контролер може автоматично надсилати високі та низькі рівні з певними інтервалами, перемикаючи світлодіодну матрицю RGB між закритою (світить) і відкритою (світло вимкнено), щоб вона могла випромінювати блакитний, жовтий, зелений, фіолетовий, синій, червоний і біле світло. Бездротовий модуль відповідає за підключення до Wi-Fi роутера, отримання і звіт про стан розумних лампочок, а також відправку команд для управління світлодіодом.
Малюнок 2.2. Імітація розумного світла
На початку розвитку сtage, ви можете імітувати розумне світло за допомогою плати ESP32-C3DevKitM-1, підключеної до RGB LED lamp намистини (див. рис. 2.2). Але ви повинні
14 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

зауважте, що це не єдиний спосіб зібрати розумне світло. Апаратна конструкція проекту в цій книзі містить лише бездротовий модуль (із вбудованим ESP32-C3), але не повну інтелектуальну розробку апаратного забезпечення. Крім того, Espressif також виробляє плату розробки аудіосистеми ESP32C3-Lyra на основі ESP32-C3 для керування освітленням за допомогою звуку. Плата має інтерфейси для мікрофонів і динаміків і може керувати світлодіодними стрічками. Його можна використовувати для розробки наддешевих, високопродуктивних аудіомовників і ритмічних світлових смуг. На малюнку 2.3 показано плату ESP32-C3Lyra, з’єднану смугою з 40 світлодіодів.
Малюнок 2.3. ESP32-C3-Lyra, з’єднаний смугою з 40 світлодіодних ламп
Смартфони (Android/iOS) Проект Smart Light передбачає розробку додатка для смартфона для налаштування та керування приладами Smart Light.
Маршрутизатори Wi-Fi Маршрутизатори Wi-Fi перетворюють сигнали дротової мережі та сигнали мобільної мережі на сигнали бездротової мережі для підключення комп’ютерів, смартфонів, планшетів та інших бездротових пристроїв до мережі. наприкладampОтже, широкосмуговий зв’язок удома потрібно лише підключити до маршрутизатора Wi-Fi, щоб забезпечити бездротове з’єднання пристроїв Wi-Fi у мережу. Основним стандартом протоколу, який підтримується маршрутизаторами Wi-Fi, є IEEE 802.11n із середньою швидкістю TxRate 300 Мбіт/с або максимум 600 Мбіт/с. Вони зворотно сумісні з IEEE 802.11b і IEEE 802.11g. Мікросхема ESP32-C3 від Espressif підтримує IEEE 802.11b/g/n, тому ви можете вибрати однодіапазонний (2.4 ГГц) або дводіапазонний (2.4 ГГц і 5 ГГц) Wi-Fi маршрутизатор.
Комп’ютер (Linux/macOS/Windows) Середовище розробки буде представлено в Розділі 4. Розділ 2. Введення та практика проектів IoT 15

2.2.4 Процес розробки
Малюнок 2.4. Етапи розробки проекту Smart Light
Розробка апаратного забезпечення Розробка апаратного забезпечення пристроїв IoT має важливе значення для проекту IoT. Повний проект розумного освітлення призначений для виробництва іншихamp працює від електромережі. Різні виробники випускають лampмають різні стилі та типи драйверів, але їхні бездротові модулі зазвичай мають однакову функцію. Щоб спростити процес розробки проекту Smart Ligh, у цій книзі розглядається лише апаратне забезпечення та розробка програмного забезпечення бездротових модулів.
Конфігурація хмарної платформи IoT Щоб використовувати хмарні платформи IoT, вам потрібно налаштувати проекти на сервері, наприклад створювати продукти, створювати пристрої, налаштовувати властивості пристроїв тощо.
Розробка вбудованого програмного забезпечення для пристроїв IoT Реалізуйте очікувані функції за допомогою ESP-IDF, SDK від Espressif на стороні пристрою, включаючи підключення до хмарних платформ IoT, розробку світлодіодних драйверів та оновлення мікропрограми.
Розробка додатків для смартфонів Розробка додатків для смартфонів для систем Android та iOS для реалізації реєстрації та входу користувачів, керування пристроєм та інших функцій.
Оптимізація пристроїв IoT Після завершення базової розробки функцій пристроїв IoT ви можете перейти до завдань оптимізації, наприклад оптимізації живлення.
Тестування масового виробництва Проводьте випробування масового виробництва відповідно до відповідних стандартів, таких як перевірка функціонування обладнання, випробування на старіння, радіочастотне випробування тощо.
Незважаючи на перераховані вище кроки, проект Smart Light не обов’язково підлягає такій процедурі, оскільки різні завдання також можуть виконуватися одночасно. наприкладampLe, вбудоване програмне забезпечення та програми для смартфонів можна розробляти паралельно. Також може знадобитися повторити деякі кроки, наприклад оптимізацію пристрою IoT і тестування масового виробництва.
16 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

2.3 Підсумок
У цьому розділі ми спочатку розповіли про основні компоненти та функціональні модулі проекту IoT, а потім представили корпус Smart Light для практики, посилаючись на його структуру, функції, підготовку апаратного забезпечення та процес розробки. Читачі можуть зробити висновки з практики та стати впевненими у виконанні проектів IoT з мінімальними помилками в майбутньому.
Розділ 2. Введення та практика проектів IoT 17

18 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Глава 3

вступ

до

ESP

RainMaker

Інтернет речей (IoT) пропонує безмежні можливості змінити спосіб життя людей, але розробка технології IoT сповнена проблем. За допомогою загальнодоступних хмар виробники терміналів можуть реалізувати функціональність продукту за допомогою таких рішень:
На основі хмарних платформ постачальників рішень Таким чином, виробникам терміналів потрібно лише спроектувати апаратне забезпечення продукту, потім підключити апаратне забезпечення до хмари за допомогою наданого модуля зв’язку та налаштувати функції продукту відповідно до вказівок. Це ефективний підхід, оскільки він усуває потребу в розробці на стороні сервера та додатку, а також в експлуатації та обслуговуванні (O&M). Це дозволяє виробникам терміналів зосередитися на дизайні апаратного забезпечення без необхідності розглядати реалізацію хмари. Однак такі рішення (наприклад, прошивка пристрою та додаток) зазвичай не мають відкритого коду, тому функції продукту будуть обмежені хмарною платформою постачальника, яку неможливо налаштувати. Тим часом дані користувача та пристрою також належать до хмарної платформи.
На основі хмарних продуктів. У цьому рішенні після завершення розробки апаратного забезпечення виробникам терміналів потрібно не лише реалізувати хмарні функції за допомогою одного чи кількох хмарних продуктів, що надаються загальнодоступною хмарою, а й зв’язати апаратне забезпечення з хмарою. наприкладample, щоб підключитися до Amazon Web Сервіси (AWS), виробники терміналів повинні використовувати такі продукти AWS, як Amazon API Gateway, AWS IoT Core та AWS Lambda, щоб забезпечити доступ до пристрою, дистанційне керування, зберігання даних, керування користувачами та інші основні функції. Він не лише вимагає від виробників терміналів гнучко використовувати та налаштовувати хмарні продукти з глибоким розумінням і багатим досвідом, але також вимагає від них враховувати вартість будівництва та обслуговування для початкових і наступнихtages Це створює великі проблеми для енергії та ресурсів компанії.
На відміну від публічних хмар, приватні хмари зазвичай створюються для конкретних проектів і продуктів. Розробникам приватних хмар надається найвищий рівень свободи в проектуванні протоколів і реалізації бізнес-логіки. Виробники терміналів можуть створювати продукти та схеми дизайну за бажанням, а також легко інтегрувати та розширювати можливості користувачів. Поєднання високого рівня безпеки, масштабованості та надійності публічної хмари з перевагамиtagприватної хмари Espressif запустив ESP
19

RainMaker, глибоко інтегроване приватне хмарне рішення на основі хмари Amazon. Користувачі можуть розгортати ESP RainMaker і створювати приватну хмару просто за допомогою облікового запису AWS.
3.1 Що таке ESP RainMaker?
ESP RainMaker — це повна платформа AIoT, створена за допомогою кількох зрілих продуктів AWS. Він надає різні послуги, необхідні для масового виробництва, такі як доступ до хмари пристроїв, оновлення пристроїв, керування серверною частиною, сторонній вхід, голосова інтеграція та керування користувачами. Використовуючи безсерверне сховище додатків (SAR), надане AWS, виробники терміналів можуть швидко розгорнути ESP RainMaker у своїх облікових записах AWS, що є ефективним за часом і простим у використанні. Керований і підтримуваний Espressif, SAR, який використовується ESP RainMaker, допомагає розробникам зменшити витрати на технічне обслуговування хмари та прискорити розробку продуктів AIoT, таким чином створюючи безпечні, стабільні та настроювані рішення AIoT. На малюнку 3.1 показано архітектуру ESP RainMaker.
Малюнок 3.1. Архітектура ESP RainMaker
Загальнодоступний сервер ESP RainMaker від Espressif є безкоштовним для всіх ентузіастів, виробників і викладачів ESP для оцінки рішень. Розробники можуть увійти за допомогою облікових записів Apple, Google або GitHub і швидко створити власні прототипи додатків IoT. Загальнодоступний сервер інтегрує Alexa та Google Home і надає послуги голосового керування, які підтримуються Alexa Skill і Google Actions. Його функція семантичного розпізнавання також підтримується третіми сторонами. Пристрої RainMaker IoT реагують лише на певні дії. Щоб отримати вичерпний список підтримуваних голосових команд, перевірте сторонні платформи. Крім того, Espressif пропонує загальнодоступний додаток RainMaker, за допомогою якого користувачі можуть керувати продуктами за допомогою смартфонів. 20 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

3.2 Впровадження ESP RainMaker
Як показано на малюнку 3.2, ESP RainMaker складається з чотирьох частин: · Служба заявки, що дозволяє пристроям RainMaker динамічно отримувати сертифікати. · RainMaker Cloud (також відомий як хмарний сервер), що надає такі послуги, як фільтрація повідомлень, керування користувачами, зберігання даних та інтеграція сторонніх розробників. · RainMaker Agent, що дозволяє пристроям RainMaker підключатися до RainMaker Cloud. · Клієнт RainMaker (додаток RainMaker або сценарії CLI) для ініціалізації, створення користувачів, асоціації та керування пристроями тощо.
Малюнок 3.2. Структура ESP RainMaker
ESP RainMaker надає повний набір інструментів для розробки продуктів і масового виробництва, включаючи: RainMaker SDK
RainMaker SDK базується на ESP-IDF і надає вихідний код агента на стороні пристрою та відповідних API C для розробки мікропрограм. Розробникам потрібно лише написати логіку програми, а решту залишити фреймворку RainMaker. Для отримання додаткової інформації про C API відвідайте https://bookc3.espressif.com/rm/c-api-reference. Додаток RainMaker Загальнодоступна версія додатка RainMaker дозволяє розробникам завершити ініціалізацію пристроїв, а також контролювати та запитувати статус пристроїв (наприклад, розумних освітлювальних приладів). Він доступний як у магазинах програм для iOS, так і для Android. Для отримання додаткової інформації зверніться до розділу 10. API REST API REST допомагають користувачам створювати власні програми, подібні до програми RainMaker. Для отримання додаткової інформації відвідайте https://swaggerapis.rainmaker.espressif.com/.
Розділ 3. Знайомство з ESP RainMaker 21

API Python Інтерфейс командного рядка на основі Python, який постачається разом із RainMaker SDK, надається для реалізації всіх функцій, подібних до функцій смартфона. Щоб дізнатися більше про API Python, відвідайте https://bookc3.espressif.com/rm/python-api-reference.
Admin CLI Адміністратор CLI з вищим рівнем доступу надається для приватного розгортання ESP RainMaker для масової генерації сертифікатів пристрою.
3.2.1 Служба подання претензій
Весь зв’язок між пристроями RainMaker і хмарним сервером здійснюється через MQTT+TLS. У контексті ESP RainMaker «Претензії» — це процес, у якому пристрої отримують сертифікати від Claiming Service для підключення до хмарної серверної частини. Зауважте, що Claiming Service застосовний лише до загальнодоступної служби RainMaker, тоді як для приватного розгортання сертифікати пристрою потрібно згенерувати масово за допомогою Admin CLI. ESP RainMaker підтримує три типи послуги подання претензій: самозаявка
Пристрій сам отримує сертифікати через секретний ключ, попередньо запрограмований у eFuse після підключення до Інтернету. Заява, керована хостом. Сертифікати отримуються від хоста розробки з обліковим записом RainMaker. Допомога в поданні заявки Сертифікати отримуються через програми для смартфонів під час надання.
3.2.2 Агент RainMaker
Малюнок 3.3. Структура RainMaker SDK Основна функція RainMaker Agent полягає в забезпеченні підключення та допомозі прикладному рівню обробляти хмарні дані висхідної/низхідної лінії зв’язку. Він створений за допомогою RainMaker SDK 22 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT

і розроблено на основі перевіреної структури ESP-IDF з використанням компонентів ESP-IDF, таких як RTOS, NVS і MQTT. На малюнку 3.3 показано структуру RainMaker SDK.
RainMaker SDK містить дві основні функції.
Підключення
i. Співпраця з Claiming Service для отримання сертифікатів пристрою.
ii. Підключення до хмарного серверу за допомогою захищеного протоколу MQTT для забезпечення віддаленого підключення та реалізації дистанційного керування, звітування про повідомлення, керування користувачами, керування пристроями тощо. Він використовує компонент MQTT у ESP-IDF за замовчуванням і забезпечує рівень абстракції для взаємодії з іншими стеки протоколів.
iii. Надання компонента ініціалізації Wi-Fi для з’єднання та ініціалізації Wi-Fi, компонента esp https ota для оновлень OTA та компонента esp local ctrl для виявлення локального пристрою та підключення. Усіх цих цілей можна досягти за допомогою простого налаштування.
Обробка даних
i. Зберігання сертифікатів пристрою, виданих Claiming Service, і даних, необхідних під час запуску RainMaker, за замовчуванням з використанням інтерфейсу, наданого компонентом nvs flash, і надання API для розробників для прямого використання.
ii. Використання механізму зворотного виклику для обробки хмарних даних висхідної/низхідної лінії зв’язку та автоматичного розблокування даних на прикладному рівні для легкої обробки розробниками. наприкладampRainMaker SDK надає багаті інтерфейси для створення даних TSL (Thing Specification Language), які необхідні для визначення моделей TSL для опису пристроїв IoT і реалізації таких функцій, як час, зворотний відлік і голосове керування. Для основних інтерактивних функцій, таких як синхронізація, RainMaker SDK надає рішення без розробки, яке можна просто ввімкнути за потреби. Потім агент RainMaker безпосередньо оброблятиме дані, надсилатиме їх у хмару через пов’язану тему MQTT і надсилатиме зміни даних у серверній частині хмари через механізм зворотного виклику.
3.2.3 Cloud Backend
Хмарний бекенд побудований на базі безсерверних обчислень AWS і досягається через AWS Cognito (система керування ідентифікацією), Amazon API Gateway, AWS Lambda (безсерверний обчислювальний сервіс), Amazon DynamoDB (база даних NoSQL), AWS IoT Core (ядро доступу до IoT, яке забезпечує доступ MQTT). і фільтрування правил), 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, які використовуються хмарним сервером

Хмарний продукт AWS, який використовує RainMaker

функція

AWS Cognito

Управління обліковими даними користувача та підтримка авторизації сторонніх розробників

AWS Лямбда

Реалізація основної бізнес-логіки хмарного серверу

Amazon Timestream Зберігання даних часових рядів

Amazon DynamoDB Зберігання особистої інформації клієнтів

Ядро AWS IoT

Підтримка зв'язку MQTT

Amazon SES

Надання послуг розсилки електронною поштою

Amazon CloudFront Прискорення керування серверною частиною webдоступ до сайту

Amazon SQS

Пересилання повідомлень з AWS IoT Core

3.2.4 Клієнт RainMaker
Клієнти RainMaker, такі як App і CLI, спілкуються з хмарним сервером через REST API. Детальну інформацію та інструкції щодо REST API можна знайти в документації Swagger, наданій Espressif. Мобільний клієнт програми RainMaker доступний як для систем iOS, так і для Android. Це дозволяє ініціалізувати пристрій, контролювати та надавати спільний доступ, а також створювати та активувати завдання зворотного відліку та підключатися до сторонніх платформ. Він може автоматично завантажувати інтерфейс користувача та піктограми відповідно до конфігурації, повідомленої пристроями, і повністю відображати TSL пристрою.
наприкладample, якщо інтелектуальний світильник створено на основі RainMaker SDK, напрampфайли, піктограма та інтерфейс користувача лампочки будуть завантажені автоматично після завершення підготовки. Користувачі можуть змінювати колір і яскравість світла через інтерфейс і керувати сторонніми засобами, зв’язавши Alexa Smart Home Skill або Google Smart Home Actions зі своїми обліковими записами ESP RainMaker. На малюнку 3.4 показано піктограму та приклад інтерфейсу користувачаampлампочок відповідно на Alexa, Google Home і ESP RainMaker App.

24 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

(a) Прample – Алекса

(b) Прample – Google Home

(c) Прample – ESP RainMaker
Малюнок 3.4. Впрampфайли піктограми та інтерфейсу користувача лампочки в Alexa, Google Home і ESP RainMaker App
3.3 Практика: ключові моменти для розробки з ESP RainMaker
Після завершення рівня драйвера пристрою розробники можуть почати створювати моделі TSL і обробляти дані низхідної лінії зв’язку за допомогою API, наданих RainMaker SDK, і вмикати базові служби ESP RainMaker на основі визначення продукту та вимог.
Розділ 3. Знайомство з ESP RainMaker 25

Розділ 9.4 цієї книги пояснює впровадження інтелектуального світлодіодного освітлення в RainMaker. Під час налагодження розробники можуть використовувати інструменти CLI у RainMaker SDK для зв’язку з розумним світлом (або викликати REST API від Swagger).
Розділ 10 детально розповість про використання REST API у розробці додатків для смартфонів. Оновлення світлодіодних інтелектуальних ліхтарів через OTA буде розглянуто в розділі 11. Якщо розробники ввімкнули віддалений моніторинг ESP Insights, сервер керування ESP RainMaker відображатиме дані ESP Insights. Подробиці будуть представлені в розділі 15.
ESP RainMaker підтримує приватне розгортання, яке відрізняється від загальнодоступного сервера RainMaker такими способами:
Claiming Service Щоб створити сертифікати в приватних розгортаннях, потрібно використовувати RainMaker Admin CLI замість Claiming. На загальнодоступному сервері розробникам необхідно надати права адміністратора для впровадження оновлення мікропрограми, але це небажано в комерційних розгортаннях. Таким чином, ані окрема служба автентифікації не може бути надана для самостійного заявлення, ані права адміністратора для керованого або допоміжного заявлення.
Програми для телефону У приватних розгортаннях програми потрібно налаштовувати та скомпілювати окремо, щоб гарантувати, що системи облікових записів не сумісні.
Сторонні входи та голосова інтеграція. Розробники повинні налаштувати окремо через облікові записи розробників Google і Apple, щоб увімкнути сторонні входи, а також інтеграцію Alexa Skill і Google Voice Assistant.
ПОРАДИ Щоб дізнатися більше про розгортання хмари, відвідайте https://customer.rainmaker.espressif. ком. З точки зору вбудованого програмного забезпечення, міграція з публічного сервера на приватний вимагає лише заміни сертифікатів пристрою, що значно покращує ефективність міграції та зменшує вартість міграції та вторинного налагодження.
3.4 Особливості ESP RainMaker
Функції ESP RainMaker в основному націлені на три аспекти – керування користувачами, кінцевих користувачів і адміністраторів. Усі функції підтримуються як на публічних, так і на приватних серверах, якщо не вказано інше.
3.4.1 Керування користувачами
Функції керування користувачами дозволяють кінцевим користувачам реєструватися, входити в систему, змінювати паролі, отримувати паролі тощо.
26 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Зареєструйтеся та ввійдіть. Методи реєстрації та входу, які підтримує RainMaker, включають: · Ідентифікатор електронної пошти + Пароль · Номер телефону + Пароль · Обліковий запис Google · Обліковий запис Apple · Обліковий запис GitHub (лише загальнодоступний сервер) · Обліковий запис Amazon (лише приватний сервер)
ПРИМІТКА Зареєструйтеся за допомогою Google/Amazon надає RainMaker доступ до електронної адреси користувача. Під час реєстрації за допомогою Apple надає фіктивну адресу, яку Apple призначає користувачеві спеціально для служби RainMaker. Обліковий запис RainMaker буде створено автоматично для користувачів, які вперше входять за допомогою облікового запису Google, Apple або Amazon.
Змінити пароль Дійсний лише для входу на основі ідентифікатора електронної пошти/номера телефону. Усі інші активні сеанси буде виведено з системи після зміни пароля. Згідно з поведінкою AWS Cognito, сеанси, які вийшли з системи, можуть залишатися активними до 1 години.
Отримати пароль Дійсний лише для входу на основі ідентифікатора електронної пошти/номера телефону.
3.4.2 Функції кінцевого користувача
Функції, відкриті для кінцевих користувачів, включають локальне та дистанційне керування та моніторинг, планування, групування пристроїв, спільне використання пристроїв, push-повідомлення та інтеграцію сторонніх розробників.
Віддалене керування та моніторинг · Конфігурація запиту, значення параметрів і стан підключення для одного або всіх пристроїв. · Встановіть параметри для одного або кількох пристроїв.
Локальний контроль і моніторинг Мобільний телефон і пристрій мають бути підключені до однієї мережі для локального контролю.
Планування · Користувачі заздалегідь встановлюють певні дії на певний час. · Під час виконання розкладу пристрою не потрібне підключення до Інтернету. · Одноразово або повторно (вказавши дні) для одного чи кількох пристроїв.
Групування пристроїв Підтримує багаторівневе абстрактне групування Метадані групи можна використовувати для створення структури домашньої кімнати.
Розділ 3. Знайомство з ESP RainMaker 27

Спільний доступ до пристрою Одним або декількома пристроями можна спільно користуватися одним або декількома користувачами.
Push-сповіщення. Кінцеві користувачі отримуватимуть push-повідомлення про такі події, як: · Додано/видалено нові пристрої · Пристрій підключено до хмари · Пристрій відключено від хмари · Створено/прийнято/відхилено запити на спільний доступ до пристрою · Повідомлення сповіщень від пристроїв
Інтеграції сторонніх розробників Alexa та Google Voice Assistant підтримуються для керування пристроями RainMaker, включаючи освітлення, вимикачі, розетки, вентилятори та датчики температури.
3.4.3 Функції адміністратора
Функції адміністратора дозволяють адміністраторам здійснювати реєстрацію пристроїв, групування пристроїв і оновлення OTA, а також view статистика та дані ESP Insights.
Реєстрація пристрою Створіть сертифікати пристрою та зареєструйтеся за допомогою Admin CLI (лише приватний сервер).
Групування пристроїв Створення абстрактних або структурованих груп на основі інформації про пристрій (лише приватний сервер).
Оновлення по повітрю (OTA) Завантажте мікропрограмне забезпечення на основі версії та моделі на один або кілька пристроїв або групу. Відстежуйте, скасовуйте або архівуйте завдання OTA.
View статистика Viewдоступна статистика включає: · Реєстрації пристроїв (сертифікати, зареєстровані адміністратором) · Активації пристроїв (пристрій підключено вперше) · Облікові записи користувачів · Асоціація користувача та пристрою
View Дані ESP Insights Viewдоступні дані ESP Insights включають: · Помилки, попередження та спеціальні журнали · Звіти про збої та аналіз · Причини перезавантаження · Показники, такі як використання пам'яті, RSSI тощо. · Спеціальні показники та змінні
28 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

3.5 Підсумок
У цьому розділі ми познайомилися з деякими ключовими відмінностями між публічним розгортанням RainMaker і приватним розгортанням. Приватне рішення ESP RainMaker, запущене Espressif, є дуже надійним і розширюваним. Усі чіпи серії ESP32 підключені та адаптовані до AWS, що значно знижує вартість. Розробники можуть зосередитися на перевірці прототипу без необхідності вивчати хмарні продукти AWS. Ми також пояснили реалізацію та особливості ESP RainMaker, а також деякі ключові моменти для розробки за допомогою платформи.
Скануйте, щоб завантажити ESP RainMaker для Android. Скануйте, щоб завантажити ESP RainMaker для iOS
Розділ 3. Знайомство з ESP RainMaker 29

30 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Розділ Налаштування середовища розробки 4
Цей розділ присвячено ESP-IDF, офіційній структурі розробки програмного забезпечення для ESP32-C3. Ми пояснимо, як налаштувати середовище в різних операційних системах, познайомимося зі структурою проекту та системою побудови ESP-IDF, а також з використанням відповідних інструментів розробки. Потім ми представимо процес компіляції та запуску example project, пропонуючи детальне пояснення вихідного журналу на кожному stage.
4.1 ESP-IDF Overview
ESP-IDF (Espressif IoT Development Framework) — це універсальна платформа розробки IoT, надана компанією Espressif Technology. Він використовує C/C++ як основну мову розробки та підтримує крос-компіляцію під основні операційні системи, такі як Linux, Mac і Windows. КолишнійampФайлові програми, включені в цю книгу, розроблено з використанням ESP-IDF, який пропонує такі функції: · Драйвери системного рівня SoC. ESP-IDF містить драйвери для ESP32, ESP32-S2, ESP32-C3,
та інші фішки. Ці драйвери охоплюють периферійну бібліотеку низького рівня (LL), бібліотеку апаратного рівня абстракції (HAL), підтримку RTOS і драйвер верхнього рівня тощо. · Основні компоненти. ESP-IDF містить основні компоненти, необхідні для розробки IoT. Це включає кілька стеків мережевих протоколів, таких як HTTP і MQTT, структуру керування живленням із динамічною частотною модуляцією та такі функції, як Flash Encryption і Secure Boot тощо. · Інструменти розробки та виробництва. ESP-IDF надає широко використовувані інструменти для збірки, флеш-пам’яті та налагодження під час розробки та масового виробництва (див. рис. 4.1), такі як система збирання на основі CMake, ланцюжок інструментів крос-компіляції на основі GCC та JTAG інструмент налагодження на основі OpenOCD тощо. Варто зазначити, що код ESP-IDF переважно відповідає ліцензії з відкритим кодом Apache 2.0. Користувачі можуть розробляти особисте або комерційне програмне забезпечення без обмежень, дотримуючись умов ліцензії на відкрите програмне забезпечення. Крім того, користувачам безкоштовно надаються постійні патентні ліцензії без зобов’язання відкривати будь-які зміни, внесені у вихідний код.
31

малюнок 4.1.

Збірка, перепрошивка та налагодження

інструменти для розробки та масового виробництва

4.1.1 Версії ESP-IDF
Код ESP-IDF розміщено на GitHub як проект із відкритим кодом. Наразі доступні три основні версії: v3, v4 та v5. Кожна основна версія зазвичай містить різні підверсії, наприклад v4.2, v4.3 тощо. Espressif Systems забезпечує 30-місячну підтримку для виправлення помилок і патчів безпеки для кожної випущеної підверсії. Тому регулярно випускаються версії підверсій, наприклад v4.3.1, v4.2.2 тощо. Таблиця 4.1 показує статус підтримки різних версій ESP-IDF для чіпів Espressif, вказуючи, чи є вони в попередній версії.view stage (пропонує підтримку для preview версії, у яких можуть бути відсутні певні функції чи документація) або офіційно підтримуються.

Таблиця 4.1. Статус підтримки різних версій ESP-IDF для мікросхем Espressif

Серія 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 Wireless Adventure: вичерпний посібник з IoT

Ітерація основних версій часто передбачає коригування структури фреймворку та оновлення системи компіляції. наприкладample, основною зміною від v3.* до v4.* була поступова міграція системи збірки від Make до CMake. З іншого боку, ітерація проміжних версій зазвичай передбачає додавання нових функцій або підтримку нових мікросхем.
Важливо розрізняти та розуміти зв’язок між стабільними версіями та гілками GitHub. Версії, позначені як v*.* або v*.*.*, являють собою стабільні версії, які пройшли повне внутрішнє тестування Espressif. Після виправлення код, ланцюжок інструментів і документи випуску для тієї самої версії залишаються незмінними. Однак гілки GitHub (наприклад, гілка release/v4.3) піддаються частим фіксаціям коду, часто щодня. Таким чином, два фрагменти коду в одній гілці можуть відрізнятися, що змушує розробників негайно оновлювати свій код відповідно.
4.1.2 Робочий процес ESP-IDF Git
Espressif дотримується спеціального робочого процесу Git для ESP-IDF, описаного таким чином:
· Нові зміни вносяться до головної гілки, яка служить головною гілкою розробки. Версія ESP-IDF у головній гілці завжди містить -dev tag щоб вказати, що він зараз розробляється, наприклад v4.3-dev. Зміни в головній гілці спочатку будуть повторноviewредаговано та перевірено у внутрішньому сховищі Espressif, а потім відправлено на GitHub після завершення автоматизованого тестування.
· Після того, як нова версія завершила розробку функцій на основній гілці та відповідала критеріям для входу в бета-тестування, вона переходить до нової гілки, такої як release/ v4.3. Крім того, ця нова гілка є tagged як попередня версія, наприклад v4.3-beta1. Розробники можуть звернутися до платформи GitHub, щоб отримати доступ до повного списку гілок і tags для ESP-IDF. Важливо зазначити, що бета-версія (попередня версія) все ще може мати значну кількість відомих проблем. Оскільки бета-версія проходить безперервне тестування, виправлення помилок додаються як у цю версію, так і в головну гілку одночасно. Тим часом головна гілка, можливо, вже почала розробляти нові функції для наступної версії. Коли тестування майже завершено, до гілки додається мітка кандидата на випуск (rc), яка вказує на те, що це потенційний кандидат на офіційний випуск, наприклад v4.3-rc1. На цьому сtagе, гілка залишається попередньою версією.
· Якщо серйозних помилок не виявлено або не повідомлено, попередня версія зрештою отримує мітку основної версії (наприклад, v5.0) або мітку другорядної версії (наприклад, v4.3) і стає офіційною версією випуску, яка документується на сторінці приміток до випуску. Згодом усі помилки, виявлені в цій версії, виправляються у гілці випуску. Після завершення ручного тестування гілці призначається мітка версії виправлення помилок (наприклад, v4.3.2), яка також відображається на сторінці приміток до випуску.
Розділ 4. Налаштування середовища розробки 33

4.1.3 Вибір відповідної версії
Оскільки ESP-IDF офіційно почав підтримувати ESP32-C3 з версії v4.3, а v4.4 ще не було офіційно випущено на момент написання цієї книги, у цій книзі використовується версія v4.3.2, яка є переглянутою версією версії 4.3. Однак важливо зазначити, що до того часу, як ви прочитаєте цю книгу, версії v4.4 або новіші можуть бути вже доступними. При виборі версії ми рекомендуємо наступне:
· Для розробників початкового рівня бажано вибрати стабільну версію v4.3 або її переглянуту версію, яка відповідає попереднімampверсія le, використана в цій книзі.
· Для цілей масового виробництва рекомендується використовувати останню стабільну версію, щоб отримати найновішу технічну підтримку.
· Якщо ви маєте намір поекспериментувати з новими мікросхемами або вивчити нові функції продукту, скористайтеся головною гілкою. Остання версія містить усі найновіші функції, але майте на увазі, що можуть бути відомі чи невідомі помилки.
· Якщо використовувана стабільна версія не містить бажаних нових функцій і ви бажаєте мінімізувати ризики, пов’язані з головною гілкою, подумайте про використання відповідної гілки випуску, такої як гілка release/v4.4. Репозиторій GitHub Epressif спочатку створить гілку release/v4.4, а потім випустить стабільну версію v4.4 на основі конкретного історичного знімка цієї гілки після завершення розробки та тестування всіх функцій.
4.1.4 Завершеноview каталогу ESP-IDF SDK
ESP-IDF SDK складається з двох основних каталогів: esp-idf і .espressif. Перший містить вихідний код сховища ESP-IDF files та сценарії компіляції, тоді як останній переважно зберігає ланцюжки інструментів компіляції та інше програмне забезпечення. Знайомство з цими двома каталогами допоможе розробникам краще використовувати наявні ресурси та прискорити процес розробки. Структура каталогів ESP-IDF описана нижче:
(1) Каталог коду сховища ESP-IDF (/esp/esp-idf), як показано на малюнку 4.2.
a. Компоненти каталогу компонентів
Цей основний каталог інтегрує численні основні програмні компоненти ESP-IDF. Жоден код проекту не можна скомпілювати без використання компонентів у цьому каталозі. Він включає підтримку драйверів для різних мікросхем Espressif. Від бібліотеки LL та інтерфейсів бібліотеки HAL для периферійних пристроїв до драйвера верхнього рівня та Virtual File Підтримка рівня системи (VFS), розробники можуть вибирати відповідні компоненти на різних рівнях для своїх потреб розробки. ESP-IDF також підтримує кілька стандартних стеків мережевих протоколів, таких як TCP/IP, HTTP, MQTT, WebSocket тощо. Розробники можуть використовувати знайомі інтерфейси, такі як Socket, для створення мережевих програм. Компоненти забезпечують розуміння
34 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Малюнок 4.2. Каталог кодів сховища ESP-IDF
широку функціональність і може бути легко інтегрована в програми, дозволяючи розробникам зосередитися виключно на бізнес-логіці. Деякі загальні компоненти включають: · драйвер: цей компонент містить периферійні програми драйверів для різних Espressif
серій мікросхем, таких як GPIO, I2C, SPI, UART, LEDC (ШІМ) тощо. Програми драйверів периферійних пристроїв у цьому компоненті пропонують незалежні від мікросхем абстрактні інтерфейси. Кожен периферійний пристрій має загальний заголовок file (наприклад, gpio.h), усуваючи потребу вирішувати різні питання підтримки, пов’язані з чіпом. · esp_wifi: Wi-Fi, як спеціальний периферійний пристрій, розглядається як окремий компонент. Він включає кілька API, таких як ініціалізація різних режимів драйвера Wi-Fi, налаштування параметрів і обробка подій. Певні функції цього компонента надаються у вигляді бібліотек статичних посилань. ESP-IDF також надає повну документацію драйверів для простоти використання.
Розділ 4. Налаштування середовища розробки 35

· freertos: цей компонент містить повний код FreeRTOS. Окрім надання повної підтримки цієї операційної системи, Espressif також розширив підтримку двоядерних чіпів. Для двоядерних чіпів, таких як ESP32 і ESP32-S3, користувачі можуть створювати завдання на певних ядрах.
b. Каталог документів docs
Цей каталог містить документи щодо розробки, пов’язані з ESP-IDF, зокрема Посібник із початку роботи, Довідковий посібник з API, Посібник із розробки тощо.
ПРИМІТКА Після компіляції за допомогою автоматизованих інструментів вміст цього каталогу розгортається за адресою https://docs.espressif.com/projects/esp-idf. Переконайтеся, що цільовий документ переключено на ESP32-C3 і виберіть вказану версію ESP-IDF.
в. Інструменти інструменту сценарію
У цьому каталозі містяться стандартні зовнішні інструменти компіляції, такі як idf.py, інструмент моніторингу терміналу idf_monitor.py тощо. Підкаталог cmake також містить базовий сценарій files системи компіляції, яка служить основою для реалізації правил компіляції ESP-IDF. Під час додавання змінних середовища вміст у каталозі інструментів додається до системної змінної середовища, що дозволяє виконувати idf.py безпосередньо в шляху проекту.
d. Прample програмний каталог напрampлес
Цей каталог містить велику колекцію ESP-IDF exampфайли програм, які демонструють використання компонентних API. Колишнійampфайли організовані в різні підкаталоги на основі їхніх категорій:
· початок роботи: цей підкаталог містить початковий рівень exampтакі файли, як «hello world» і «blink», щоб допомогти користувачам зрозуміти основи.
· bluetooth: Ви можете знайти пов'язані з Bluetooth напрampтут, зокрема Bluetooth LE Mesh, Bluetooth LE HID, BluFi тощо.
· wifi: цей підкаталог присвячено Wi-Fi напрampфайли, включаючи базові програми, такі як Wi-Fi SoftAP, Wi-Fi Station, espnow, а також власний протокол зв’язку напр.ampлес від Espressif. Він також включає кілька прикладних рівнів, напрampфайли на основі Wi-Fi, такі як Iperf, Sniffer і Smart Config.
· периферійні пристрої: цей великий підкаталог далі поділено на численні підпапки на основі імен периферійних пристроїв. В основному він містить периферійний драйвер напрampдля чіпсів Espressif, з кожним напрample з кількома допampлес. Наприклад, підкаталог gpio містить два exampфайли: GPIO та матрична клавіатура GPIO. Важливо зазначити, що не всі ексampфайли в цьому каталозі застосовуються до ESP32-C3.
36 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

наприкладample, ексampфайли в usb/host застосовуються лише до периферійних пристроїв із апаратним забезпеченням USB-хосту (наприклад, ESP32-S3), а ESP32-C3 не має цього периферійного пристрою. Система компіляції зазвичай надає підказки під час встановлення цілі. README file кожного екзample містить список підтримуваних мікросхем. · протоколи: цей підкаталог містить напрampфайли для різних протоколів зв’язку, включаючи MQTT, HTTP, HTTP-сервер, PPPoS, Modbus, mDNS, SNTP, охоплюючи широкий діапазон протоколів зв’язку, напр.ampнеобхідні для розробки IoT. · ініціалізація: тут ви знайдете ініціалізацію напрampфайли для різних методів, наприклад надання Wi-Fi та Bluetooth LE. · система: цей підкаталог включає системне налагодження напрampфайли (наприклад, трасування стека, трасування під час виконання, моніторинг завдань), керування живленням напрampфайли (наприклад, різні режими сну, співпроцесори) і прampфайли, пов’язані зі звичайними компонентами системи, такими як консольний термінал, цикл подій і системний таймер. · зберігання: у цьому підкаталозі ви знайдете напрampменше всього file системи та механізми зберігання, що підтримуються ESP-IDF (такі як читання та запис флеш-пам’яті, SD-карти та інших носіїв інформації), а також напр.ampфайли енергонезалежного сховища (NVS), FatFS, SPIFFS та ін file системні операції. · безпека: цей підкаталог містить напрampфайли, пов'язані з флеш-шифруванням. (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 на одному хості та легко перемикатися між ними, імпортуючи різні змінні середовища.
в. Інструмент компіляції 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 Налаштування середовища розробки ESP-IDF у Linux
Інструменти розробки та налагодження GNU, необхідні для середовища розробки ESP-IDF, є рідними для системи Linux. Крім того, термінал командного рядка в Linux потужний і зручний, що робить його ідеальним вибором для розробки ESP32-C3. Ти можеш
38 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

виберіть бажаний дистрибутив Linux, але ми рекомендуємо використовувати Ubuntu або інші системи на основі Debian. У цьому розділі містяться вказівки щодо налаштування середовища розробки ESP-IDF на Ubuntu 20.04.
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. Крім того, Git також використовується в ESP-IDF для підтвердження інформації про версію, необхідної для встановлення правильного ланцюжка інструментів, що відповідає певним версіям. Крім 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.
З: Що робити, якщо версія Python не підтримується? A: ESP-IDF v4.3 вимагає версії Python не нижче v3.6. Для старіших версій Ubuntu вручну завантажте та встановіть новішу версію Python і встановіть Python3 як середовище Python за замовчуванням. Ви можете знайти докладні інструкції, виконавши пошук за ключовим словом update-alternatives python.
2. Завантажте код репозиторію ESP-IDF
Відкрийте термінал і створіть папку з назвою esp у вашому домашньому каталозі за допомогою команди mkdir. Ви можете вибрати іншу назву для папки, якщо хочете. Використовуйте команду cd, щоб увійти в папку.
Розділ 4. Налаштування середовища розробки 39

$ mkdir -p /esp $ cd /esp
Використовуйте команду git clone, щоб завантажити код сховища ESP-IDF, як показано нижче:
$ git clone -b v4.3.2 – рекурсивний 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 Налаштування середовища розробки ESP-IDF у Windows
1. Завантажте програму встановлення інструментів ESP-IDF
ПОРАДИ Рекомендовано налаштувати середовище розробки ESP-IDF у Windows 10 або новішій версії. Ви можете завантажити програму встановлення з https://dl.espressif.com/dl/esp-idf/. Інсталятор також є програмним забезпеченням з відкритим кодом, і його вихідний код може бути таким viewза адресою https: //github.com/espressif/idf-installer.
· Онлайн-інсталятор інструментів ESP-IDF
Цей інсталятор відносно невеликий, розміром близько 4 МБ, і інші пакети та код будуть завантажені під час інсталяції. АвансtagЕфективність онлайн-інсталятора полягає в тому, що не тільки пакети програмного забезпечення та код можна завантажити на вимогу під час процесу інсталяції, але також дозволяє інсталювати всі доступні випуски ESP-IDF і останню гілку коду GitHub (наприклад, головну гілку). . Недолікtage полягає в тому, що під час процесу встановлення потрібне підключення до мережі, що може спричинити збій встановлення через проблеми з мережею.
40 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

· Інсталятор офлайн-інструментів ESP-IDF. Цей інсталятор більший, приблизно 1 ГБ, і містить усі пакети програмного забезпечення та код, необхідні для налаштування середовища. Основний авванtagОсобливістю офлайн-інсталятора є те, що його можна використовувати на комп’ютерах без доступу до Інтернету та, як правило, він має вищий рівень успішного встановлення. Слід зазначити, що офлайн-інсталятор може встановлювати лише стабільні випуски ESP-IDF, позначені v*.* або v*.*.*.
2. Запустіть інсталятор інструментів ESP-IDF Після завантаження відповідної версії інсталятора (наприклад, візьміть ESP-IDF Tools Offline 4.3.2ample here), двічі клацніть exe file щоб запустити інтерфейс встановлення ESP-IDF. Нижче показано, як інсталювати стабільну версію ESP-IDF v4.3.2 за допомогою офлайн-інсталятора.
(1) В інтерфейсі «Виберіть мову встановлення», показаному на малюнку 4.4, виберіть мову, яка буде використовуватися зі спадного списку.
Малюнок 4.4. Інтерфейс «Виберіть мову встановлення» (2) Після вибору мови натисніть «ОК», щоб відкрити інтерфейс «Ліцензійна угода»
(див. рис. 4.5). Уважно прочитавши ліцензійну угоду на встановлення, виберіть «Я приймаю угоду» та натисніть «Далі».
Малюнок 4.5. Інтерфейс «Ліцензійна угода» Розділ 4. Налаштування середовища розробки 41

(3) Review конфігурацію системи в інтерфейсі «Перевірка системи перед встановленням» (див. рис. 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 Wireless Adventure: вичерпний посібник з 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
CMD або термінал PowerShell ESP-IDF 4.3, як показано на малюнку 4.12), і змінна середовища ESP-IDF буде автоматично додано під час запуску в терміналі. Після цього ви можете використовувати команду idf.py для операцій. Відкритий CMD ESP-IDF 4.3 показано на малюнку 4.13. 44 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Малюнок 4.12. Встановлено середовище розробки
Малюнок 4.13. ESP-IDF 4.3 CMD
4.2.3 Налаштування середовища розробки ESP-IDF на Mac
Процес інсталяції середовища розробки ESP-IDF у системі Mac такий самий, як і в системі Linux. Команди для завантаження коду репозиторію та встановлення ланцюжка інструментів абсолютно однакові. Трохи відрізняються лише команди для встановлення пакетів залежностей. 1. Встановіть пакети залежностей Відкрийте термінал і встановіть pip, інструмент керування пакетами Python, виконавши таку команду:
% sudo легке встановлення pip
Установіть Homebrew, інструмент керування пакетами для macOS, виконавши таку команду:
% /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
Дотримуйтесь інструкцій, наведених у розділі 4.2.1, щоб установити ланцюжок засобів розробки ESP-IDF. Кроки такі ж, як і для встановлення в системі Linux.
4.2.4 Встановлення коду VS
За замовчуванням ESP-IDF SDK не включає інструмент редагування коду (хоча останній інсталятор ESP-IDF для Windows пропонує можливість інсталювати ESP-IDF Eclipse). Ви можете використовувати будь-який інструмент редагування тексту на свій вибір, щоб редагувати код, а потім скомпілювати його за допомогою команд терміналу.
Одним із популярних інструментів редагування коду є VS Code (Visual Studio Code), який є безкоштовним і багатофункціональним редактором коду зі зручним інтерфейсом. Він пропонує різні plugins які забезпечують такі функції, як навігація кодом, підсвічування синтаксису, керування версіями Git та інтеграція терміналів. Крім того, Espressif розробив спеціальний плагін під назвою Espressif IDF для VS Code, який спрощує налаштування проекту та налагодження.
Ви можете скористатися командою code в терміналі, щоб швидко відкрити поточну папку в VS Code. Крім того, ви можете скористатися комбінацією клавіш Ctrl+, щоб відкрити системну консоль терміналу за замовчуванням у VS Code.
ПОРАДИ Рекомендовано використовувати код VS для розробки коду ESP32-C3. Завантажте та встановіть останню версію VS Code за адресою https://code.visualstudio.com/.
4.2.5 Вступ до сторонніх середовищ розробки
На додаток до офіційного середовища розробки ESP-IDF, яке переважно використовує мову C, ESP32-C3 також підтримує інші основні мови програмування та широкий спектр сторонніх середовищ розробки. Серед відомих варіантів:
Arduino: платформа з відкритим вихідним кодом для апаратного та програмного забезпечення, що підтримує різні мікроконтролери, включаючи ESP32-C3.
Він використовує мову C++ і пропонує спрощений і стандартизований API, який зазвичай називають мовою Arduino. Arduino широко використовується в розробці прототипів і освітніх контекстах. Він надає розширюваний пакет програмного забезпечення та IDE, що дозволяє легко компілювати та прошити.
MicroPython: інтерпретатор мови Python 3, призначений для роботи на платформах вбудованих мікроконтролерів.
Завдяки простій мові сценаріїв він може отримати прямий доступ до периферійних ресурсів ESP32-C3 (таких як UART, SPI та I2C) і комунікаційних функцій (таких як Wi-Fi і Bluetooth LE).
46 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

Це спрощує взаємодію з обладнанням. MicroPython у поєднанні з великою бібліотекою математичних операцій Python дозволяє реалізувати складні алгоритми на ESP32-C3, полегшуючи розробку програм, пов’язаних зі штучним інтелектом. Як мова сценаріїв, немає потреби в повторній компіляції; можна вносити зміни та безпосередньо виконувати сценарії.
NodeMCU: інтерпретатор мови LUA, розроблений для мікросхем серії ESP.
Він підтримує майже всі периферійні функції мікросхем ESP і легший за MicroPython. Подібно до MicroPython, NodeMCU використовує мову сценаріїв, усуваючи необхідність повторної компіляції.
Крім того, ESP32-C3 також підтримує операційні системи NuttX і Zephyr. NuttX — це операційна система реального часу, яка забезпечує POSIX-сумісні інтерфейси, покращуючи переносимість програм. Zephyr — це невелика операційна система реального часу, спеціально розроблена для програм IoT. Він включає численні бібліотеки програмного забезпечення, необхідні для розробки IoT, поступово перетворюючись на комплексну програмну екосистему.
Ця книга не містить детальних інструкцій зі встановлення вищезгаданих середовищ розробки. Ви можете встановити середовище розробки відповідно до ваших вимог, дотримуючись відповідної документації та інструкцій.
4.3 Система компіляції ESP-IDF
4.3.1 Основні поняття системи компіляції
Проект ESP-IDF — це набір основної програми з функцією входу та кількома незалежними функціональними компонентами. наприкладample, проект, який керує світлодіодними перемикачами, в основному складається з основної програми входу та компонента драйвера, який керує GPIO. Якщо ви хочете реалізувати світлодіодне дистанційне керування, вам також потрібно додати Wi-Fi, стек протоколів TCP/IP тощо.
Система компіляції може компілювати, компонувати та генерувати виконуваний файл files (.bin) для коду через набір правил побудови. Система компіляції версії ESP-IDF v4.0 і вище базується на CMake за замовчуванням, а сценарій компіляції CMakeLists.txt можна використовувати для керування поведінкою компіляції коду. Окрім підтримки основного синтаксису CMake, система компіляції ESP-IDF також визначає набір правил компіляції за замовчуванням і функцій CMake, і ви можете написати сценарій компіляції за допомогою простих операторів.
4.3.2 Проект File Структура
Проект — це папка, яка містить основний запис програми, визначені користувачем компоненти та fileнеобхідні для створення виконуваних програм, таких як сценарії компіляції, налаштування
Розділ 4. Налаштування середовища розробки 47

files, таблиці розділів тощо. Проекти можна копіювати та передавати, а той самий виконуваний файл file можуть бути скомпільовані та згенеровані на машинах з тією ж версією середовища розробки ESP-IDF. Типовий проект ESP-IDF file структура показана на малюнку 4.14.
Малюнок 4.14. Типовий проект ESP-IDF file Структура Оскільки ESP-IDF підтримує кілька мікросхем IoT від Espressif, включаючи ESP32, серії ESP32-S, серії ESP32-C, серії ESP32-H тощо, перед компіляцією коду потрібно визначити ціль. Ціль — це як апаратний пристрій, який запускає прикладну програму, так і ціль збірки системи компіляції. Залежно від ваших потреб ви можете вказати одну або кілька цілей для свого проекту. наприкладample, за допомогою команди idf.py set-target esp32c3 ви можете встановити ціль компіляції на ESP32-C3, під час якої будуть завантажені параметри за замовчуванням і шлях ланцюжка інструментів компіляції для ESP32C3. Після компіляції для ESP32C3 можна створити виконувану програму. Ви також можете знову запустити команду set-target, щоб встановити іншу ціль, і система компіляції автоматично очистить і переналаштує. компоненти
Компоненти в ESP-IDF є модульними та незалежними одиницями коду, якими керує система компіляції. Вони організовані як папки, ім’я папки за умовчанням відповідає імені компонента. Кожен компонент має власний сценарій компіляції, який 48 ESP32-C3 Wireless Adventure: Вичерпний посібник з IoT

визначає свої параметри компіляції та залежності. Під час процесу компіляції компоненти компілюються в окремі статичні бібліотеки (.a files) і, зрештою, об’єднані з іншими компонентами для формування прикладної програми.
ESP-IDF надає основні функції, такі як операційна система, периферійні драйвери та стек мережевих протоколів, у формі компонентів. Ці компоненти зберігаються в каталозі компонентів, розташованому в кореневому каталозі ESP-IDF. Розробникам не потрібно копіювати ці компоненти в каталог компонентів myProject. Натомість їм потрібно лише вказати зв’язки залежностей цих компонентів у CMakeLists.txt проекту file за допомогою директив REQUIRES або PRIV_REQUIRES. Система компіляції автоматично знайде та скомпілює необхідні компоненти.
Таким чином, каталог компонентів у myProject не є необхідним. Він використовується лише для включення деяких спеціальних компонентів проекту, які можуть бути сторонніми бібліотеками або визначеним користувачем кодом. Крім того, компоненти можна отримати з будь-якого каталогу, крім ESP-IDF або поточного проекту, наприклад із проекту з відкритим кодом, збереженого в іншому каталозі. У цьому випадку вам потрібно лише додати шлях до компонента, встановивши змінну EXTRA_COMPONENT_DIRS у CMakeLists.txt у кореневому каталозі. Цей каталог замінить будь-який компонент ESP-IDF із такою ж назвою, забезпечуючи використання правильного компонента.
Вхідна програма main Головний каталог у проекті такий самий file структура, як і інші компоненти (наприклад, компонент1). Однак він має особливе значення, оскільки є обов’язковою складовою, яка має бути в кожному проекті. Головний каталог містить вихідний код проекту та точку входу програми користувача, яка зазвичай називається app_main. За замовчуванням виконання програми користувача починається з цієї точки входу. Основний компонент також відрізняється тим, що він автоматично залежить від усіх компонентів у межах шляху пошуку. Тому немає необхідності явно вказувати залежності за допомогою директив REQUIRES або PRIV_REQUIRES у CMakeLists.txt file.
Конфігурація file Кореневий каталог проекту містить конфігурацію file називається sdkconfig, який містить параметри конфігурації для всіх компонентів у проекті. Файл sdkconfig file автоматично генерується системою компіляції та може бути змінений і повторно згенерований командою idf.py menuconfig. Параметри menuconfig здебільшого походять із Kconfig.projbuild проекту та Kconfig компонентів. Розробники компонентів зазвичай додають елементи конфігурації до Kconfig, щоб зробити компонент гнучким і таким, що можна налаштувати.
Каталог збірки. За замовчуванням каталог збірки в межах проекту зберігає проміжні елементи files і fi-
Розділ 4. Налаштування середовища розробки 49

остаточні виконувані програми, згенеровані командою збірки idf.py. Загалом, немає необхідності безпосередньо звертатися до вмісту каталогу збірки. ESP-IDF надає попередньо визначені команди для взаємодії з каталогом, наприклад використання команди idf.py flash для автоматичного пошуку скомпільованого двійкового файлу file і перезавантажте його за вказаною флеш-адресою або використовуючи команду idf.py fullclean, щоб очистити весь каталог збірки.
Таблиця розділів (partitions.csv) Для кожного проекту потрібна таблиця розділів для розділення простору флеш-пам’яті та визначення розміру та початкової адреси виконуваної програми та простору даних користувача. Команда idf.py flash або програма оновлення OTA перезавантажить мікропрограму за відповідною адресою згідно з цією таблицею. ESP-IDF надає кілька таблиць розділів за замовчуванням у компонентах/partition_table, наприклад partitions_singleapp.csv і partitions_two_ota.csv, які можна вибрати в 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 Wireless Adventure: вичерпний посібник з IoT

DEFAULT_LEVEL_NONE = y можна налаштувати інтерфейс UART так, щоб дані журналу не друкувались за замовчуванням. Крім того, якщо потрібно встановити певні параметри для певної цілі, конфігурації file з назвою sdkconfig.defaults.TARGET_NAME можна додати, де TARGET_NAME може бути esp32s2, esp32c3 тощо. Ці конфігурації files імпортуються в 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 у кореневому каталозі проекту називається сценарієм компіляції проекту, який керує процесом компіляції всього проекту. Базовий сценарій компіляції проекту зазвичай містить три рядки:
1. cmake_minimum_required(VERSION 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) імпортує попередньо визначені елементи конфігурації та команди системи компіляції ESP-IDF, включаючи правила збірки за замовчуванням системи компіляції, описані в розділі 4.3.3. project(myProject) створює сам проект і вказує його назву. Це ім’я буде використано як кінцевий вихідний двійковий файл file ім'я, тобто myProject.elf і myProject.bin.
Проект може мати кілька компонентів, включаючи головний компонент. Каталог верхнього рівня кожного компонента містить CMakeLists.txt file, який називається сценарієм компіляції компонента. Сценарії компіляції компонентів в основному використовуються для визначення залежностей компонентів, параметрів конфігурації, вихідного коду files і включений заголовок files для
Розділ 4. Налаштування середовища розробки 51

компіляція. За допомогою спеціальної функції idf_component_register ESP-IDF мінімально необхідний код для сценарію компіляції компонента виглядає наступним чином:

1. idf_component_register(SRCS “src1.c”

INCLUDE_DIRS «включити»

ПОТРІБНО компонент 1)

Параметр SRCS надає список джерел files у компоненті, розділених пробілами, якщо їх декілька fileс. Параметр INCLUDE_DIRS надає список відкритих заголовків file каталоги для компонента, які будуть додані до шляху пошуку для інших компонентів, які залежать від поточного компонента. Параметр REQUIRES визначає загальнодоступні залежності поточного компонента. Необхідно, щоб компоненти явно вказували, від яких компонентів вони залежать, наприклад, компонент2 залежить від компонента1. Однак для головного компонента, який за замовчуванням залежить від усіх компонентів, параметр REQUIRES можна опустити.

Крім того, рідні команди CMake також можна використовувати в сценарії компіляції. наприкладample, використовуйте команду set для встановлення змінних, наприклад set(VARIABLE “VALUE”).

4.3.5 Вступ до загальних команд
ESP-IDF використовує CMake (інструмент конфігурації проекту), Ninja (інструмент побудови проекту) і esptool (флеш-інструмент) у процесі компіляції коду. Кожен інструмент відіграє різну роль у процесі компіляції, збірки та флеш-пам’яті, а також підтримує різні робочі команди. Щоб полегшити роботу користувача, ESP-IDF додає уніфікований інтерфейс idf.py, який дозволяє швидко викликати наведені вище команди.
Перед використанням idf.py переконайтеся, що:
· Змінну середовища IDF_PATH ESP-IDF додано до поточного терміналу. · Каталог виконання команд - це кореневий каталог проекту, який містить
сценарій компіляції проекту CMakeLists.txt.
Загальні команди idf.py такі:
· idf.py –help: відображення списку команд та інструкцій щодо їх використання. · idf.py set-target : налаштування компіляції taidf.py fullcleanrget, наприклад
як заміна з esp32c3. · idf.py menuconfig: запуск menuconfig, графічна конфігурація терміналу
інструмент, який може вибирати або змінювати параметри конфігурації, а результати конфігурації зберігаються в sdkconfig file. · збірка idf.py: ініціація компіляції коду. Проміжний files і остаточна виконувана програма, згенерована компіляцією, буде збережена в каталозі збірки проекту за замовчуванням. Процес компіляції є поступовим, що означає, що якщо лише одне джерело file змінюється, тільки змінений file буде складено наступного разу.

52 ESP32-C3 Wireless Adventure: вичерпний посібник з IoT

· idf.py clean: очищення проміжного files, згенерований компіляцією проекту. Весь проект буде примусово компілюватися під час наступної компіляції. Зауважте, що конфігурація CMake і зміни конфігурації, внесені за допомогою menuconfig, не будуть видалені під час очищення.
· idf.py fullclean: видалення всього каталогу збірки, включаючи всі вихідні дані конфігурації CMake fileс. При повторному створенні проекту CMake налаштує проект з нуля. Зауважте, що ця команда рекурсивно видалить усі files у каталозі збірки, тому використовуйте його з обережністю та конфігурацію проекту file не буде видалено.
· idf.py flash: прошивання двійкового файлу виконуваної програми file створений збіркою цільового ESP32-C3. Параметри -стор і -б використовуються для встановлення назви пристрою послідовного порту та швидкості передачі даних для прошивки відповідно. Якщо ці два параметри не вказано, послідовний порт буде визначено автоматично та використано швидкість передачі за замовчуванням.
· монітор idf.py: відображення вихідного сигналу послідовного порту цільового ESP32-C3. Параметр -p можна використовувати для вказівки імені пристрою для послідовного порту хоста. Під час друку послідовного порту натисніть комбінацію клавіш Ctrl+], щоб вийти з монітора.
Наведені вище команди також можна комбінувати за потреби. наприкладample, команда idf.py build flash monitor виконає послідовно компіляцію коду, флеш і відкриє монітор послідовного порту.
Ви можете відвідати https://bookc3.espressif.com/build-system, щоб дізнатися більше про систему компіляції ESP-IDF.
4.4 Практика: складання впрampПрограма «Blink»
4.4.1 Прикладample Аналіз
У цьому розділі буде прикладом програма Blinkampщоб проаналізувати file детально структура та правила кодування реального проекту. Програма Blink реалізує ефект миготіння світлодіодів, а проект знаходиться в каталозі examples/get-started/blink, який містить джерело file, конфігурація files і кілька сценаріїв компіляції.
Проект розумного освітлення, представлений у цій книзі, базується на цьому прикладіampпрограма le. Функції будуть поступово додаватися в наступних розділах, щоб остаточно завершити його.
Вихідний код Щоб продемонструвати весь процес розробки, програму Blink було скопійовано до esp32c3-iot-projects/device firmware/1 blink.
Структура каталогів проекту blink files показано на рисунку 4.15.
Проект blink містить лише один головний каталог, який є спеціальним компонентом, який
Розділ 4. Налаштування середовища розробки 53

малюнок 4.15. File структура каталогів проекту blink

повинні бути включені, як описано в розділі 4.3.2. Головний каталог в основному використовується для зберігання реалізації функції app_main(), яка є точкою входу в програму користувача. Проект blink не включає каталог компонентів, оскільки це напр.ample потребує лише використання компонентів, які постачаються з ESP-IDF, і не потребує додаткових компонентів. CMakeLists.txt, включений до проекту blink, використовується для керування процесом компіляції, тоді як Kconfig.projbuild використовується для додавання елементів конфігурації для цього прикладуampфайл програми в меню конфіг. Інше непотрібне files не впливатимуть на компіляцію коду, тому вони не будуть обговорюватися тут. Детальний вступ до проекту blink files полягає в наступному.

1. /*blink.c містить наступний заголовок files*/

2. #включити

//Стандартний заголовок бібліотеки 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 містить низку заголовків files, що відповідає декларації функції

цій. ESP-IDF зазвичай дотримується порядку включення заголовка стандартної бібліотеки files, FreeR-

заголовок TOS files, заголовок драйвера files, заголовок іншого компонента files і заголовок проекту files.

Порядок заголовка fileможуть вплинути на кінцевий результат компіляції, тому спробуйте

дотримуйтеся стандартних правил. Слід зазначити, що файл sdkconfig.h генерується автоматично

за допомогою kconfig і може бути налаштований лише за допомогою команди idf.py menuconfig.

Пряма зміна цього заголовка file буде перезаписано.

1. /*Ви можете вибрати GPIO, що відповідає світлодіодному індикатору в idf.py menuconfig, а результатом модифікації menuconfig є те, що значення CONFIG_BLINK

_GPIO буде змінено. Ви також можете безпосередньо змінити визначення макросу

тут і змініть CONFIG_BLINK_GPIO на фіксоване значення.*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO

3. void app_main(void)

4. {

/*Налаштувати IO як функцію GPIO за замовчуванням, увімкнути режим підтягування та

вимкнути режими введення та виведення*/

gpio_reset_pin(BLINK_GPIO);

54 ESP32-C3 Wireless Adventure: вичерпний посібник з 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”); /*Вимкнути світлодіод (низький вихідний рівень)*/ gpio_set_level(BLINK_GPIO, 0); /*Затримка (1000 мс)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf(“Ввімкнення LEDn”); /*Увімкнути світлодіод (вихідний високий рівень)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay(1000 / portTICK_PERIOD_MS); }

Функція app_main() у Blink example програма служить точкою входу для програм користувача. Це проста функція без параметрів і значення, що повертається. Ця функція викликається після завершення ініціалізації системи, яка включає такі завдання, як ініціалізація послідовного порту журналу, налаштування одно-/двоядерного ядра та налаштування сторожового таймера.

Функція app_main() виконується в контексті завдання під назвою main. Розмір стека та пріоритет цього завдання можна налаштувати в menuconfig Componentconfig Common ESP-related.

Для таких простих завдань, як блимання світлодіода, весь необхідний код можна реалізувати безпосередньо у функції app_main(). Зазвичай це передбачає ініціалізацію GPIO, що відповідає світлодіодному індикатору, і використання циклу while(1) для ввімкнення та вимкнення світлодіода. Крім того, ви можете використовувати FreeRTOS API, щоб створити нове завдання, яке обробляє миготіння світлодіода. Після успішного створення нового завдання можна вийти з функції app_main().

Вміст main/CMakeLists.txt file, який керує процесом компіляції для основного компонента, виглядає наступним чином:

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

Серед них main/CMakeLists.txt викликає лише одну системну функцію компіляції, тобто idf_component_register. Подібно до CMakeLists.txt для більшості інших компонентів, blink.c додається до SRCS, а джерело files, доданий до SRCS, буде скомпільовано. У той же час «.», який представляє шлях, де знаходиться CMakeLists.txt, слід додати до INCLUDE_DIRS як каталоги пошуку для заголовка fileс. Вміст CMakeLists.txt такий:
1. #Вкажіть v3.5 як найстарішу версію CMake, що підтримується поточним проектом 2. #Версії, нижчі за v3.5, необхідно оновити перед продовженням компіляції 3. cmake_minimum_required(ВЕРСІЯ 3.5) 4. #Включити стандартну конфігурацію CMake ESP -Система компіляції IDF

Розділ 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 Wireless Adventure [pdfПосібник користувача
ESP32-C3 Wireless Adventure, ESP32-C3, Wireless Adventure, Adventure

Список літератури

Посібник користувача

ESP32-C3 Wireless Adventure

ESP32-C3 Wireless Adventure

Вичерпний посібник з IoT

Технічні характеристики

Інструкція з використання продукту

Підготовка

Впровадження та практика проектів IoT

Практика: Smart Light Project

Структура проекту

Функції проекту

Підготовка обладнання

Процес розробки

Знайомство з ESP RainMaker

Що таке ESP RainMaker?

Впровадження ESP RainMaker

Практика: ключові моменти для розробки з ESP RainMaker

Особливості ESP RainMaker

Налаштування середовища розробки

Розробка обладнання та драйверів

Розробка апаратного забезпечення інтелектуальних світлових продуктів на основі ESP32-C3

Особливості та склад продуктів Smart Light

Дизайн апаратного забезпечення базової системи ESP32-C3

FAQ

З: Що таке ESP RainMaker?

Q: Як я можу налаштувати середовище розробки для
ESP32-C3?

З: Які функції ESP RainMaker?

Документи / Ресурси

Список літератури

Залиште коментар

Скасувати відповідь

ESP32-C3 Wireless Adventure

ESP32-C3 Wireless Adventure

Вичерпний посібник з IoT

Технічні характеристики

Інструкція з використання продукту

Підготовка

Впровадження та практика проектів IoT

Практика: Smart Light Project

Структура проекту

Функції проекту

Підготовка обладнання

Процес розробки

Знайомство з ESP RainMaker

Що таке ESP RainMaker?

Впровадження ESP RainMaker

Практика: ключові моменти для розробки з ESP RainMaker

Особливості ESP RainMaker

Налаштування середовища розробки

Розробка обладнання та драйверів

Розробка апаратного забезпечення інтелектуальних світлових продуктів на основі ESP32-C3

Особливості та склад продуктів Smart Light

Дизайн апаратного забезпечення базової системи ESP32-C3

FAQ

З: Що таке ESP RainMaker?

Q: Як я можу налаштувати середовище розробки для ESP32-C3?

З: Які функції ESP RainMaker?

Документи / Ресурси

Список літератури

Пов’язані публікації

Залиште коментар

Скасувати відповідь

Q: Як я можу налаштувати середовище розробки для
ESP32-C3?