Bezprzewodowa przygoda ESP32-C3

Bezprzewodowa przygoda ESP32-C3

Kompleksowy przewodnik po IoT

Systemy Espressif 12 czerwca 2023 r

Specyfikacje

  • Produkt: Bezprzewodowa przygoda ESP32-C3
  • Producent: Espressif Systems
  • Data: 12 czerwca 2023 r.

Instrukcje użytkowania produktu

Przygotowanie

Przed użyciem ESP32-C3 Wireless Adventure upewnij się, że tak
zaznajomiony z koncepcjami i architekturą IoT. To pomoże
rozumiesz, jak urządzenie wpasowuje się w większy ekosystem IoT
i jego potencjalne zastosowania w inteligentnych domach.

Wprowadzenie i praktyka projektów IoT

W tej sekcji poznasz typowe projekty IoT,
w tym podstawowe moduły dla popularnych urządzeń IoT, moduły podstawowe
aplikacji klienckich i popularnych platform chmurowych IoT. To będzie
zapewnią Ci podstawę do zrozumienia i tworzenia własnych
własne projekty IoT.

Sprawdź swoją wiedzę: Projekt inteligentnego oświetlenia

W tym projekcie ćwiczeniowym dowiesz się, jak stworzyć smart
światło za pomocą bezprzewodowej przygody ESP32-C3. Struktura projektu,
funkcje, przygotowanie sprzętu i proces rozwoju
szczegółowo wyjaśnione.

Struktura projektu

Projekt składa się z kilku elementów, m.in
ESP32-C3 Bezprzewodowa przygoda, diody LED, czujniki i chmura
tył.

Funkcje projektu

Inteligentny projekt świetlny pozwala kontrolować jasność i
zmianę koloru diod LED zdalnie poprzez aplikację mobilną lub web
interfejs.

Przygotowanie sprzętu

Aby przygotować się do projektu, musisz zebrać
niezbędne komponenty sprzętowe, takie jak ESP32-C3 Wireless
Tablica przygodowa, diody LED, rezystory i zasilacz.

Proces rozwoju

Proces rozwoju obejmuje skonfigurowanie rozwoju
środowiska, pisanie kodu sterującego diodami LED, podłączanie do
backend w chmurze i testowanie funkcjonalności smarta
światło.

Wprowadzenie do ESP RainMaker

ESP RainMaker to potężna platforma do tworzenia IoT
urządzenia. W tej sekcji dowiesz się czym jest ESP RainMaker i
jak można to wdrożyć w swoich projektach.

Co to jest ESP RainMaker?

ESP RainMaker to platforma oparta na chmurze, która udostępnia zestaw
narzędzia i usługi do budowy i zarządzania urządzeniami IoT.

Implementacja ESP RainMaker

W tej sekcji opisano różne komponenty biorące udział w programie
wdrożenie ESP RainMaker, w tym obsługa reklamacji,
Agent RainMaker, backend w chmurze i klient RainMaker.

Przećwicz: Kluczowe punkty dotyczące programowania z ESP RainMaker

W tej części praktycznej poznasz najważniejsze punkty
należy wziąć pod uwagę podczas programowania przy użyciu ESP RainMaker. Obejmuje to urządzenie
zgłaszanie roszczeń, synchronizacja danych i zarządzanie użytkownikami.

Funkcje ESP RainMaker

ESP RainMaker oferuje różne funkcje zarządzania użytkownikami
użytkowników i administratorów. Funkcje te pozwalają na łatwe urządzenie
konfiguracja, zdalne sterowanie i monitorowanie.

Konfigurowanie środowiska programistycznego

W tej sekcji znajdziesz więcejview ESP-IDF (Espressif IoT
Development Framework), które są oficjalnymi ramami rozwoju
dla urządzeń opartych na ESP32. Wyjaśnia różne wersje
ESP-IDF i jak skonfigurować środowisko programistyczne.

Rozwój sprzętu i sterowników

Projektowanie sprzętu inteligentnych produktów oświetleniowych w oparciu o ESP32-C3

W tej sekcji skupiono się na projektowaniu sprzętu inteligentnego światła
produkty oparte na bezprzewodowej przygodzie ESP32-C3. Obejmuje
cechy i skład inteligentnych produktów oświetleniowych, a także
projekt sprzętowy systemu rdzenia ESP32-C3.

Funkcje i skład inteligentnych produktów oświetleniowych

W tej podsekcji opisano funkcje i komponenty, które sprawiają, że
up inteligentnych produktów oświetleniowych. Omówiono różne funkcjonalności
oraz rozważania projektowe dotyczące tworzenia inteligentnych świateł.

Projekt sprzętu systemu rdzenia ESP32-C3

Konstrukcja sprzętowa systemu rdzenia ESP32-C3 obejmuje zasilanie
zasilanie, sekwencja włączenia, reset systemu, flash SPI, źródło zegara,
oraz kwestie dotyczące częstotliwości radiowych i anten. Ten podrozdział zapewnia
szczegółowe informacje na temat tych aspektów.

Często zadawane pytania

P: Co to jest ESP RainMaker?

Odp.: ESP RainMaker to platforma oparta na chmurze udostępniająca narzędzia
oraz usługi w zakresie budowy i zarządzania urządzeniami IoT. To upraszcza
proces rozwoju i pozwala na łatwą konfigurację urządzenia, zdalną
kontrola i monitorowanie.

P: Jak mogę skonfigurować środowisko programistyczne dla
ESP32-C3?

Odp.: Aby skonfigurować środowisko programistyczne dla ESP32-C3, potrzebujesz
aby zainstalować ESP-IDF (Espressif IoT Development Framework) i
skonfiguruj go zgodnie z dostarczonymi instrukcjami. ESP-IDF to
oficjalne ramy rozwojowe dla urządzeń opartych na ESP32.

P: Jakie są funkcje ESP RainMaker?

Odp.: ESP RainMaker oferuje różne funkcje, w tym funkcje użytkownika
zarządzanie, funkcje użytkownika końcowego i funkcje administracyjne. Zarządzanie użytkownikami
pozwala na łatwe zgłaszanie urządzeń i synchronizację danych. Użytkownik końcowy
funkcje umożliwiają zdalne sterowanie urządzeniami za pośrednictwem aplikacji mobilnej lub
web interfejs. Funkcje administracyjne zapewniają narzędzia do monitorowania urządzenia
i zarządzania.

Bezprzewodowa przygoda ESP32-C3
Kompleksowy przewodnik po IoT
Systemy Espressif 12 czerwca 2023 r

Zawartość

Przygotowanie

1

1 Wprowadzenie do Internetu Rzeczy

3

1.1 Architektura IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Zastosowanie IoT w inteligentnych domach . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Wprowadzenie i praktyka projektów IoT

9

2.1 Wprowadzenie do typowych projektów IoT . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Podstawowe moduły dla popularnych urządzeń IoT . . . . . . . . . . . . . . . . . 9

2.1.2 Podstawowe moduły aplikacji klienckich . . . . . . . . . . . . . . . . . . . 10

2.1.3 Wprowadzenie do popularnych platform chmurowych IoT . . . . . . . . . . . . . . 11

2.2 Praktyka: Projekt inteligentnego oświetlenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Struktura projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Funkcje projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Przygotowanie sprzętu . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Proces rozwoju. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Wprowadzenie do ESP RainMaker

19

3.1 Co to jest ESP RainMaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Implementacja ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Reklamacja usługi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 Agent RainMakera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 Backend w chmurze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.4 Klient RainMakera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Praktyka: Kluczowe punkty rozwoju z ESP RainMaker . . . . . . . . . . . . 25

3.4 Funkcje ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 Zarządzanie użytkownikami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 Funkcje użytkownika końcowego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.3 Funkcje administracyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Konfigurowanie środowiska programistycznego

31

4.1 Koniec ESP-IDFview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Wersje ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3

4.1.2 Przebieg pracy w Git ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 Wybór odpowiedniej wersji . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4 Koniecview katalogu SDK ESP-IDF. . . . . . . . . . . . . . . . . . . . 34 4.2 Konfigurowanie środowiska programistycznego ESP-IDF . . . . . . . . . . . . . . . . . 38 4.2.1 Konfigurowanie środowiska programistycznego ESP-IDF w systemie Linux . . . . . . . . 38 4.2.2 Konfigurowanie środowiska programistycznego ESP-IDF w systemie Windows . . . . . . 40 4.2.3 Konfigurowanie środowiska programistycznego ESP-IDF na komputerze Mac . . . . . . . . . 45 4.2.4 Instalacja kodu VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 Wprowadzenie do środowisk programistycznych innych firm . . . . . . . . 46 4.3 System kompilacji ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 Podstawowe pojęcia dotyczące systemu kompilacji . . . . . . . . . . . . . . . . . . 47 4.3.2 Projekt File Struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 Domyślne reguły kompilacji systemu kompilacji . . . . . . . . . . . . . 50 4.3.4 Wprowadzenie do skryptu kompilacji . . . . . . . . . . . . . . . . . . 51 4.3.5 Wprowadzenie do typowych poleceń . . . . . . . . . . . . . . . . . . . 52 4.4 Ćwicz: Kompilowanie Przykładample Program „Miganie” . . . . . . . . . . . . . . . . . . 53 4.4.1 Przykładample Analiza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2 Kompilowanie programu Blink . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 Flashowanie programu Blink . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Analiza dziennika portu szeregowego programu Blink . . . . . . . . . . . . . . 60 4.5 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

II Rozwój sprzętu i sterowników

65

5 Projektowanie sprzętu inteligentnych produktów oświetleniowych w oparciu o ESP32-C3

67

5.1 Cechy i skład produktów Smart Light . . . . . . . . . . . . . . . 67

5.2 Projekt sprzętowy systemu podstawowego ESP32-C3 . . . . . . . . . . . . . . . . . . . 70

5.2.1 Zasilanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2 Sekwencja włączania i reset systemu . . . . . . . . . . . . . . . . . . 74

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

5.2.4 Źródło zegara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.5 RF i antena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.6 Kołki do spinania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2.7 Kontroler GPIO i PWM . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Praktyka: Budowa inteligentnego systemu oświetlenia za pomocą ESP32-C3 . . . . . . . . . . . . . 80

5.3.1 Wybór modułów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3.2 Konfiguracja GPIO sygnałów PWM . . . . . . . . . . . . . . . . . . . . 82

5.3.3 Pobieranie oprogramowania sprzętowego i interfejs debugowania . . . . . . . . . . . . 82

5.3.4 Wytyczne dotyczące projektowania RF . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 Wytyczne dotyczące projektowania zasilaczy . . . . . . . . . . . . . . . . . . . 86 5.4 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Rozwój kierowcy

87

6.1 Proces rozwoju sterowników . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 Aplikacje peryferyjne ESP32-C3 . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Podstawy sterowników LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.1 Przestrzenie kolorów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2 Sterownik LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.3 Ściemnianie diod LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.4 Wprowadzenie do PWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.4 Rozwój sterownika przyciemniania LED . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 Magazynowanie nieulotne (NVS) . . . . . . . . . . . . . . . . . . . . . . . . 97

6.4.2 Kontroler LED PWM (LEDC) . . . . . . . . . . . . . . . . . . . . . . . 98

6.4.3 Programowanie LED PWM . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 Praktyka: Dodawanie sterowników do projektu Smart Light . . . . . . . . . . . . . . . . . 103

6.5.1 Sterownik przycisku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5.2 Sterownik przyciemniania LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.6 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

III Bezprzewodowa komunikacja i sterowanie

109

7 Konfiguracja i połączenie Wi-Fi

111

7.1 Podstawy Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.1 Wprowadzenie do Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.2 Ewolucja IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.3 Koncepcje Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.1.4 Połączenie Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2 Podstawy Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.2.1 Wprowadzenie do Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.2 Pojęcia dotyczące Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.2.3 Połączenie Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Konfiguracja sieci Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.3.1 Przewodnik konfiguracji sieci Wi-Fi . . . . . . . . . . . . . . . . . . . . 131

7.3.2 SoftAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

7.3.3 Inteligentna konfiguracja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

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

7.3.5 Inne metody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.4 Programowanie Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 Komponenty Wi-Fi w ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 Ćwiczenie: Połączenie Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 Ćwiczenie: Inteligentne połączenie Wi-Fi . . . . . . . . . . . . . . . . . . . . . 145
7.5 Praktyka: Konfiguracja Wi-Fi w projekcie Smart Light . . . . . . . . . . . . . . . 156 7.5.1 Połączenie Wi-Fi w projekcie Smart Light . . . . . . . . . . . . . . . . . 156 7.5.2 Inteligentna konfiguracja Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8 Sterowanie lokalne

159

8.1 Wprowadzenie do sterowania lokalnego . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1.1 Zastosowanie sterowania lokalnego . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.2 Zaawansowanytages sterowania lokalnego. . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.3 Wykrywanie kontrolowanych urządzeń poprzez smartfony . . . . . . . . . . 161

8.1.4 Przesyłanie danych pomiędzy smartfonami i urządzeniami . . . . . . . . 162

8.2 Typowe metody lokalnego wykrywania . . . . . . . . . . . . . . . . . . . . . . . . 162

8.2.1 Transmisja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

8.2.2 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

8.2.3 Porównanie transmisji i multiemisji . . . . . . . . . . . . . . 176

8.2.4 Protokół aplikacji multiemisji mDNS dla lokalnego wykrywania . . . . . . . . 176

8.3 Wspólne protokoły komunikacyjne dla danych lokalnych . . . . . . . . . . . . . . . 179

8.3.1 Protokół kontroli transmisji (TCP) . . . . . . . . . . . . . . . . . . . 179

8.3.2 Protokół przesyłania hipertekstu (HTTP) . . . . . . . . . . . . . . . . . . . 185

8.3.3 Dane użytkownikatagProtokół RAM (UDP). . . . . . . . . . . . . . . . . . . . . . 189

8.3.4 Protokół ograniczonej aplikacji (CoAP) . . . . . . . . . . . . . . . . 192

8.3.5 Protokół Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.3.6 Podsumowanie protokołów transmisji danych . . . . . . . . . . . . . . . 203

8.4 Gwarancja bezpieczeństwa danych. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

8.4.1 Wprowadzenie do zabezpieczeń warstwy transportowej (TLS) . . . . . . . . . . . . . 207

8.4.2 Wprowadzenie do Datagram Transport Layer Security (DTLS) . . . . . . . 213

8.5 Praktyka: Sterowanie lokalne w projekcie Smart Light . . . . . . . . . . . . . . . . . . 217

8.5.1 Tworzenie lokalnego serwera sterowania opartego na Wi-Fi . . . . . . . . . . . . . . . 217

8.5.2 Weryfikacja funkcjonalności sterowania lokalnego za pomocą skryptów . . . . . . . . . . . 221

8.5.3 Tworzenie lokalnego serwera sterowania opartego na technologii Bluetooth . . . . . . . . . . . . 222

8.6 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 Kontrola w chmurze

225

9.1 Wprowadzenie do zdalnego sterowania . . . . . . . . . . . . . . . . . . . . . . . . . . 225

9.2 Protokoły komunikacji danych w chmurze . . . . . . . . . . . . . . . . . . . . . . 226

9.2.1 Wprowadzenie do MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 9.2.2 Zasady MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.3 Format komunikatu MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.4 Porównanie protokołów . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5 Konfigurowanie brokera MQTT w systemach Linux i Windows . . . . . . . . . . . . 233 9.2.6 Konfigurowanie klienta MQTT w oparciu o ESP-IDF . . . . . . . . . . . . . . . . 235 9.3 Zapewnienie bezpieczeństwa danych MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.1 Znaczenie i funkcja certyfikatów . . . . . . . . . . . . . . . . . . . 237 9.3.2 Lokalne generowanie certyfikatów . . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 Konfiguracja brokera MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 Konfiguracja klienta MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.4 Ćwiczenie: Zdalne sterowanie poprzez ESP RainMaker . . . . . . . . . . . . . . . . 243 9.4.1 Podstawy ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.2 Protokół komunikacyjny węzła i chmury wewnętrznej . . . . . . . . . . . 244 9.4.3 Komunikacja pomiędzy Klientem a Zapleczem Chmury . . . . . . . . . . . 249 9.4.4 Role użytkowników . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 Usługi podstawowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.4.6 Inteligentne światło Npample. . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.7 Aplikacja RainMaker i integracje z innymi firmami . . . . . . . . . . . . . . . 262 9.5 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

10 Tworzenie aplikacji na smartfony

269

10.1 Wprowadzenie do tworzenia aplikacji na smartfony . . . . . . . . . . . . . . . . . . 269

10.1.1 Ponadview rozwoju aplikacji na smartfony. . . . . . . . . . . . . . . 270

10.1.2 Struktura projektu Android . . . . . . . . . . . . . . . . . . . . . . 270

10.1.3 Struktura projektu iOS . . . . . . . . . . . . . . . . . . . . . . . . 271

10.1.4 Cykl życia działania w systemie Android . . . . . . . . . . . . . . . . . . . . . . 272

10.1.5 Cykl życia iOS ViewKontroler. . . . . . . . . . . . . . . . . . . . . . 273

10.2 Tworzenie nowego projektu aplikacji na smartfony . . . . . . . . . . . . . . . . . . . . . 275

10.2.1 Przygotowanie do programowania Androida . . . . . . . . . . . . . . . . . . . 275

10.2.2 Tworzenie nowego projektu na Androida . . . . . . . . . . . . . . . . . . . . . . 275

10.2.3 Dodawanie zależności dla MyRainmaker . . . . . . . . . . . . . . . . . 276

10.2.4 Prośba o pozwolenie w Androidzie. . . . . . . . . . . . . . . . . . . . . . 277

10.2.5 Przygotowanie do programowania iOS . . . . . . . . . . . . . . . . . . . . . . 277

10.2.6 Tworzenie nowego projektu iOS . . . . . . . . . . . . . . . . . . . . . . . . 278

10.2.7 Dodawanie zależności dla MyRainmaker . . . . . . . . . . . . . . . . . 279

10.2.8 Prośba o pozwolenie w iOS . . . . . . . . . . . . . . . . . . . . . . . . . 280

10.3 Analiza wymagań funkcjonalnych aplikacji. . . . . . . . . . . . . . . . . . 281

10.3.1 Analiza wymagań funkcjonalnych projektu . . . . . . . . . . . . 282

10.3.2 Analiza wymagań dotyczących zarządzania użytkownikami . . . . . . . . . . . . . . . 282 10.3.3 Analiza wymagań dotyczących udostępniania urządzeń i wiązania . . . . . . . 283 10.3.4 Analiza wymagań dotyczących zdalnego sterowania . . . . . . . . . . . . . . . . 283 10.3.5 Analiza wymagań harmonogramowych . . . . . . . . . . . . . . . . . . . 284 10.3.6 Analiza wymagań Centrum Użytkownika . . . . . . . . . . . . . . . . . . 285 10.4 Rozwój zarządzania użytkownikami . . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.1 Wprowadzenie do interfejsów API RainMaker . . . . . . . . . . . . . . . . . . . . . . 285 10.4.2 Inicjowanie komunikacji poprzez smartfon . . . . . . . . . . . . . . . . 286 10.4.3 Rejestracja konta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 10.4.4 Logowanie do konta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 10.5 Rozwój udostępniania urządzeń . . . . . . . . . . . . . . . . . . . . . . . 292 10.5.1 Urządzenia skanujące . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 10.5.2 Podłączanie urządzeń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.5.3 Generowanie tajnych kluczy . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.4 Pobieranie identyfikatora węzła . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.5 Urządzenia do udostępniania . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 10.6 Rozwój kontroli urządzeń . . . . . . . . . . . . . . . . . . . . . . . . . . 302 10.6.1 Powiązanie urządzeń z kontami w chmurze . . . . . . . . . . . . . . . . . . . . 303 10.6.2 Pobieranie listy urządzeń . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.6.3 Uzyskiwanie statusu urządzenia . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 10.6.4 Zmiana stanu urządzenia . . . . . . . . . . . . . . . . . . . . . . . . . . 310 10.7 Tworzenie harmonogramu i centrum użytkownika . . . . . . . . . . . . . . . . . . . 313 10.7.1 Implementacja funkcji planowania . . . . . . . . . . . . . . . . . . . . 313 10.7.2 Implementowanie Centrum Użytkownika . . . . . . . . . . . . . . . . . . . . . . . . . 315 10.7.3 Więcej interfejsów Cloud API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.8 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

11 Aktualizacja oprogramowania sprzętowego i zarządzanie wersjami

321

11.1 Aktualizacja oprogramowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

11.1.1 Ponadview tablic partycji. . . . . . . . . . . . . . . . . . . . . . . . 322

11.1.2 Proces uruchamiania oprogramowania sprzętowego . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

11.1.3 Ponadview mechanizmu OTA. . . . . . . . . . . . . . . . . . . . . 326

11.2 Zarządzanie wersjami oprogramowania sprzętowego . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.1 Oznaczenie oprogramowania sprzętowego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.2 Wycofywanie i zapobieganie wycofywaniu . . . . . . . . . . . . . . . . . . . . . . . . 331

11.3 Ćwicz: Bezprzewodowo (OTA) Npample. . . . . . . . . . . . . . . . . . . . . . . 332

11.3.1 Aktualizacja oprogramowania sprzętowego poprzez hosta lokalnego. . . . . . . . . . . . . . . . . 332

11.3.2 Aktualizacja oprogramowania sprzętowego poprzez ESP RainMaker . . . . . . . . . . . . . . . 335

11.4 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

IV Optymalizacja i produkcja masowa

343

12 Zarządzanie energią i optymalizacja niskiego zużycia energii

345

12.1 Zarządzanie energią ESP32-C3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

12.1.1 Dynamiczne skalowanie częstotliwości . . . . . . . . . . . . . . . . . . . . . . . . 346

12.1.2 Konfiguracja zarządzania energią . . . . . . . . . . . . . . . . . . . . 348

12.2 Tryb niskiego poboru mocy ESP32-C3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

12.2.1 Tryb uśpienia modemu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

12.2.2 Tryb lekkiego uśpienia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

12.2.3 Tryb głębokiego uśpienia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

12.2.4 Pobór prądu w różnych trybach zasilania . . . . . . . . . . . . . 358

12.3 Zarządzanie energią i debugowanie przy niskim poborze mocy . . . . . . . . . . . . . . . . . 359

12.3.1 Debugowanie dziennika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

12.3.2 Debugowanie GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

12.4 Praktyka: Zarządzanie energią w projekcie Smart Light . . . . . . . . . . . . . . . 363

12.4.1 Konfiguracja funkcji zarządzania energią . . . . . . . . . . . . . . . . . 364

12.4.2 Używanie blokad zarządzania energią . . . . . . . . . . . . . . . . . . . . . . 365

12.4.3 Sprawdzanie zużycia energii . . . . . . . . . . . . . . . . . . . . . . . 366

12.5 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

13 ulepszonych funkcji zabezpieczeń urządzenia

369

13.1 Ponadview bezpieczeństwa danych urządzeń IoT. . . . . . . . . . . . . . . . . . . . . . . 369

13.1.1 Dlaczego warto zabezpieczać dane urządzenia IoT? . . . . . . . . . . . . . . . . . . . . . . 370

13.1.2 Podstawowe wymagania dotyczące bezpieczeństwa danych urządzeń IoT . . . . . . . . . . . . 371

13.2 Ochrona integralności danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

13.2.1 Wprowadzenie do metody weryfikacji integralności . . . . . . . . . . . . . . 372

13.2.2 Weryfikacja integralności danych oprogramowania sprzętowego . . . . . . . . . . . . . . . . . . 373

13.2.3ample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3 Ochrona poufności danych. . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.1 Wprowadzenie do szyfrowania danych . . . . . . . . . . . . . . . . . . . . . . 374

13.3.2 Wprowadzenie do schematu szyfrowania Flash . . . . . . . . . . . . . . . . . 376

13.3.3 Przechowywanie klucza szyfrującego Flash . . . . . . . . . . . . . . . . . . . . . . . 379

13.3.4 Tryb pracy szyfrowania Flash. . . . . . . . . . . . . . . . . . . . 380

13.3.5 Proces szyfrowania Flash . . . . . . . . . . . . . . . . . . . . . . . . . . 381

13.3.6 Wprowadzenie do szyfrowania NVS . . . . . . . . . . . . . . . . . . . . . . 383

13.3.7amppliki szyfrowania Flash i szyfrowania NVS . . . . . . . . . . . 384

13.4 Ochrona legalności danych. . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.1 Wprowadzenie do podpisu cyfrowego . . . . . . . . . . . . . . . . . . . . . 386

13.4.2 Ponadview programu bezpiecznego rozruchu. . . . . . . . . . . . . . . . . . . . . 388

13.4.3 Wprowadzenie do bezpiecznego rozruchu programowego . . . . . . . . . . . . . . . . . . . 388 13.4.4 Wprowadzenie do bezpiecznego rozruchu sprzętowego . . . . . . . . . . . . . . . . . . 390 13.4.5 Przykładamples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 13.5 Praktyka: Zabezpieczenia w produkcji masowej . . . . . . . . . . . . . . . . . . 396 13.5.1 Szyfrowanie Flash i bezpieczny rozruch . . . . . . . . . . . . . . . . . . . . . 396 13.5.2 Włączanie szyfrowania Flash i bezpiecznego rozruchu za pomocą narzędzi Batch Flash . . 397 13.5.3 Włączanie szyfrowania Flash i bezpiecznego rozruchu w projekcie Smart Light . . . 398 13.6 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

14 Nagrywanie i testowanie oprogramowania sprzętowego do masowej produkcji

399

14.1 Nagrywanie oprogramowania sprzętowego w produkcji masowej . . . . . . . . . . . . . . . . . . . . . . 399

14.1.1 Definiowanie partycji danych . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.2 Nagrywanie oprogramowania sprzętowego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

14.2 Testowanie produkcji masowej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

14.3 Praktyka: Dane dotyczące produkcji masowej w projekcie Smart Light . . . . . . . . . . . . . 404

14.4 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

15 ESP Insights: Platforma zdalnego monitorowania

405

15.1 Wprowadzenie do ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

15.2 Rozpoczęcie pracy z ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . 409

15.2.1 Rozpoczęcie pracy z ESP Insights w projekcie esp-insights . . . . . . 409

15.2.2 Bieganie Przykładample w projekcie esp-insights . . . . . . . . . . . . . . . 411

15.2.3 Raportowanie informacji Coredump . . . . . . . . . . . . . . . . . . . . . 411

15.2.4 Dostosowywanie dzienników zainteresowań . . . . . . . . . . . . . . . . . . . . . . . . 412

15.2.5 Zgłaszanie przyczyny ponownego uruchomienia . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.2.6 Raportowanie metryk niestandardowych . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.3 Praktyka: Wykorzystanie ESP Insights w projekcie Smart Light . . . . . . . . . . . . . . . 416

15.4 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Wstęp
ESP32-C3 to jednordzeniowy mikrokontroler Wi-Fi i Bluetooth 5 (LE), oparty na architekturze RISC-V typu open source. Zapewnia właściwą równowagę mocy, możliwości wejścia/wyjścia i bezpieczeństwa, oferując w ten sposób optymalne i ekonomiczne rozwiązanie dla podłączonych urządzeń. Aby pokazać różne zastosowania rodziny ESP32-C3, ta książka autorstwa Espressif zabierze Cię w interesującą podróż po AIoT, zaczynając od podstaw opracowywania projektów IoT i konfiguracji środowiska, po praktyczne ćwiczeniaamples. Pierwsze cztery rozdziały mówią o IoT, ESP RainMaker i ESP-IDF. Rozdziały 5 i 6 zawierają krótkie informacje na temat projektowania sprzętu i rozwoju sterowników. W miarę postępów odkryjesz, jak skonfigurować swój projekt za pośrednictwem sieci Wi-Fi i aplikacji mobilnych. Na koniec nauczysz się optymalizować swój projekt i wprowadzać go do masowej produkcji.
Jeśli jesteś inżynierem w pokrewnych dziedzinach, architektem oprogramowania, nauczycielem, studentem lub kimkolwiek, kto interesuje się IoT, ta książka jest dla Ciebie.
Możesz pobrać kod npampPlik użyty w tej książce pochodzi z witryny Espressif w serwisie GitHub. Aby uzyskać najnowsze informacje na temat rozwoju IoT, śledź nasze oficjalne konto.

Przedmowa
Informatyczny świat
Na fali Internetu Internet Rzeczy (IoT) zadebiutował, stając się nowym rodzajem infrastruktury w gospodarce cyfrowej. Aby przybliżyć technologię społeczeństwu, Espressif Systems pracuje nad wizją, zgodnie z którą programiści ze wszystkich środowisk mogą wykorzystywać IoT do rozwiązywania niektórych z najbardziej palących problemów naszych czasów. Świat „inteligentnej sieci wszystkich rzeczy” jest tym, czego oczekujemy od przyszłości.
Projektowanie własnych chipów stanowi kluczowy element tej wizji. Ma to być maraton, wymagający ciągłych przełamań technologicznych granic. Od „Game Changer” ESP8266 po serię ESP32 integrującą łączność Wi-Fi i Bluetoothr (LE), a następnie ESP32-S3 wyposażony w akcelerację AI, Espressif nigdy nie przestaje badać i opracowywać produktów dla rozwiązań AIoT. Dzięki naszemu oprogramowaniu open source, takiemu jak IoT Development Framework ESP-IDF, Mesh Development Framework ESP-MDF i Device Connectivity Platform ESP RainMaker, stworzyliśmy niezależny framework do budowania aplikacji AIoT.
Według stanu na lipiec 2022 r. łączna liczba dostaw chipsetów IoT firmy Espressif przekroczyła 800 milionów, co stanowi wiodącą pozycję na rynku MCU Wi-Fi i zapewnia zasilanie ogromnej liczby podłączonych urządzeń na całym świecie. Dążenie do doskonałości sprawia, że ​​każdy produkt Espressif jest wielkim hitem ze względu na wysoki poziom integracji i efektywność kosztową. Wypuszczenie ESP32-C3 stanowi znaczący kamień milowy w opracowanej przez firmę Espressif technologii. Jest to jednordzeniowy, 32-bitowy MCU oparty na architekturze RISC-V z 400 KB pamięci SRAM, który może pracować z częstotliwością 160 MHz. Posiada zintegrowane Wi-Fi 2.4 GHz i Bluetooth 5 (LE) z obsługą dalekiego zasięgu. Zapewnia doskonałą równowagę pomiędzy mocą, możliwościami wejścia/wyjścia i bezpieczeństwem, oferując w ten sposób optymalne i ekonomiczne rozwiązanie dla podłączonych urządzeń. Książka ta, oparta na tak potężnym ESP32-C3, ma pomóc czytelnikom zrozumieć wiedzę związaną z IoT dzięki szczegółowym ilustracjom i praktycznym przykładomamples.
Dlaczego napisaliśmy tę książkę?
Espressif Systems to coś więcej niż firma produkująca półprzewodniki. To także firma zajmująca się platformą IoT, która zawsze dąży do przełomów i innowacji w obszarze technologii. Jednocześnie firma Espressif udostępniła społeczności samodzielnie opracowany system operacyjny i środowisko oprogramowania na zasadach open source, tworząc unikalny ekosystem. Inżynierowie, twórcy i entuzjaści technologii aktywnie opracowują nowe aplikacje w oparciu o produkty Espressif, swobodnie komunikują się i dzielą się swoim doświadczeniem. Fascynujące pomysły programistów możesz cały czas zobaczyć na różnych platformach, takich jak YouTube i GitHub. Popularność produktów Espressif pobudziła rosnącą liczbę autorów, którzy wyprodukowali ponad 100 książek opartych na chipsetach Espressif, w ponad dziesięciu językach, w tym angielskim, chińskim, niemieckim, francuskim i japońskim.

To wsparcie i zaufanie partnerów społecznych zachęca Espressif do ciągłych innowacji. „Staramy się, aby nasze chipy, systemy operacyjne, frameworki, rozwiązania, chmura, praktyki biznesowe, narzędzia, dokumentacja, teksty, pomysły itp. były coraz bardziej adekwatne do odpowiedzi, których ludzie potrzebują w obliczu najpilniejszych problemów współczesnego życia. To najwyższa ambicja i kompas moralny Espressif”. powiedział pan Teo Swee Ann, założyciel i dyrektor generalny Espressif.
Espressif ceni czytanie i pomysły. Ponieważ ciągłe unowocześnianie technologii IoT stawia inżynierom wyższe wymagania, w jaki sposób możemy pomóc większej liczbie osób w szybkim opanowaniu chipów IoT, systemów operacyjnych, struktur oprogramowania, schematów aplikacji i produktów usług w chmurze? Jak to się mówi, lepiej nauczyć człowieka łowić ryby, niż dać mu rybę. Podczas sesji burzy mózgów przyszło nam do głowy, że moglibyśmy napisać książkę, aby systematycznie uporządkować kluczową wiedzę na temat rozwoju IoT. Udało nam się, szybko zebraliśmy grupę starszych inżynierów i połączyliśmy doświadczenie zespołu technicznego w programowaniu wbudowanym, tworzeniu sprzętu i oprogramowania IoT, co przyczyniło się do publikacji tej książki. W trakcie pisania staraliśmy się zachować obiektywizm i uczciwość, uwolnić się od kokonu i używać zwięzłych wyrażeń, aby oddać złożoność i urok Internetu Rzeczy. Starannie podsumowaliśmy często zadawane pytania, odnieśliśmy się do opinii i sugestii społeczności, aby jasno odpowiedzieć na pytania napotkane w procesie rozwoju oraz zapewnić praktyczne wytyczne dotyczące rozwoju IoT dla odpowiednich techników i decydentów.
Struktura książki
W tej książce przyjęto perspektywę inżyniera i krok po kroku objaśniono wiedzę niezbędną do opracowania projektów IoT. Składa się z czterech części, jak następuje:
· Przygotowanie (rozdział 1): W tej części przedstawiono architekturę IoT, typowe ramy projektu IoT, platformę chmurową ESP RainMakerr i środowisko programistyczne ESP-IDF, aby położyć solidny fundament pod rozwój projektu IoT.
· Rozwój sprzętu i sterowników (rozdział 5): W oparciu o chipset ESP6-C32, w tej części omówiono minimalny system sprzętowy i rozwój sterowników, a także implementowano kontrolę przyciemniania, gradacji kolorów i komunikacji bezprzewodowej.
· Komunikacja bezprzewodowa i sterowanie (rozdział 7): W tej części opisano inteligentny schemat konfiguracji Wi-Fi oparty na chipie ESP11-C32, protokołach sterowania lokalnego i w chmurze oraz lokalnym i zdalnym sterowaniu urządzeniami. Zawiera także schematy tworzenia aplikacji na smartfony, aktualizacji oprogramowania sprzętowego i zarządzania wersjami.
· Optymalizacja i produkcja masowa (rozdziały 12-15): Ta część jest przeznaczona dla zaawansowanych aplikacji IoT, skupiając się na optymalizacji produktów w zakresie zarządzania energią, optymalizacji przy niskim poborze mocy i zwiększonym bezpieczeństwie. Wprowadza także nagrywanie i testowanie oprogramowania sprzętowego w masowej produkcji oraz diagnostykę statusu działania i dzienników oprogramowania sprzętowego urządzenia za pośrednictwem platformy zdalnego monitorowania ESP Insights.

O kodzie źródłowym
Czytelnicy mogą uruchomić exampprogramów zawartych w tej książce, wprowadzając kod ręcznie lub korzystając z kodu źródłowego dołączonego do książki. Kładziemy nacisk na połączenie teorii i praktyki, dlatego niemal w każdym rozdziale wyznaczyliśmy sekcję Praktyka opartą na projekcie Smart Light. Wszystkie kody są open source. Czytelnicy mogą pobrać kod źródłowy i omówić go w sekcjach związanych z tą książką w serwisie GitHub i na naszym oficjalnym forum esp32.com. Kod źródłowy tej książki podlega warunkom licencji Apache 2.0.
Uwaga autora
Niniejsza książka została oficjalnie wyprodukowana przez Espressif Systems i napisana przez starszych inżynierów firmy. Jest odpowiedni dla menedżerów i personelu badawczo-rozwojowego w branżach związanych z IoT, nauczycieli i studentów kierunków pokrewnych oraz entuzjastów dziedziny Internetu Rzeczy. Mamy nadzieję, że ta książka może służyć jako podręcznik pracy, źródło informacji i książeczka przy łóżku, aby być jak dobry nauczyciel i przyjaciel.
Przygotowując tę ​​książkę, odwoływaliśmy się do istotnych wyników badań ekspertów, naukowców i techników w kraju i za granicą i staraliśmy się je cytować zgodnie z normami akademickimi. Nie da się jednak uniknąć pewnych pominięć, dlatego w tym miejscu chcielibyśmy wyrazić nasz głęboki szacunek i wdzięczność wszystkim autorom, których to dotyczy. Dodatkowo zacytowaliśmy informacje z Internetu, dlatego dziękujemy autorom oryginałów i wydawcom oraz przepraszamy, że nie jesteśmy w stanie wskazać źródła każdej informacji.
Aby stworzyć książkę o wysokiej jakości, zorganizowaliśmy rundy wewnętrznych dyskusji i wyciągnęliśmy wnioski z sugestii i opinii czytelników próbnych oraz redaktorów wydawcy. W tym miejscu chcielibyśmy jeszcze raz podziękować za pomoc, która przyczyniła się do powodzenia tej pracy.
Na koniec, ale najważniejsze, dziękuję wszystkim w Espressif, którzy tak ciężko pracowali nad narodzinami i popularyzacją naszych produktów.
Rozwój projektów IoT wymaga szerokiego zakresu wiedzy. Ze względu na długość książki oraz poziom i doświadczenie autora, pominięcia są nieuniknione. Dlatego też uprzejmie prosimy ekspertów i czytelników o krytykę i poprawienie naszych błędów. Jeśli masz jakieś sugestie dotyczące tej książki, skontaktuj się z nami pod adresem book@espressif.com. Czekamy na Twoją opinię.

Jak korzystać z tej książki?
Kod projektów opisanych w tej książce jest open source. Możesz pobrać go z naszego repozytorium GitHub i podzielić się swoimi przemyśleniami i pytaniami na naszym oficjalnym forum. GitHub: https://github.com/espressif/book-esp32c3-iot-projects Forum: https://www.esp32.com/bookc3 W całej książce fragmenty będą wyróżnione, jak pokazano poniżej.
Kod źródłowy W tej książce kładziemy nacisk na połączenie teorii i praktyki, dlatego prawie w każdym rozdziale umieściliśmy sekcję dotyczącą praktyki dotyczącą projektu Smart Light. Odpowiednie kroki i strona źródłowa zostaną zaznaczone pomiędzy dwiema liniami zaczynającymi się od tag Kod źródłowy.
UWAGA/WSKAZÓWKI Tutaj możesz znaleźć krytyczne informacje i przypomnienia dotyczące pomyślnego debugowania programu. Zostaną one zaznaczone pomiędzy dwiema grubymi liniami zaczynającymi się od tag UWAGA lub WSKAZÓWKI.
Większość poleceń w tej książce jest wykonywana w systemie Linux, co jest sygnalizowane znakiem „$”. Jeśli wykonanie polecenia wymaga uprawnień administratora, monit zostanie zastąpiony przez „#”. Wiersz poleceń w systemach Mac to „%”, zgodnie z sekcją 4.2.3 Instalowanie protokołu ESP-IDF na komputerze Mac.
Treść tej książki zostanie wydrukowana w Karcie, natomiast kod npamppliki, komponenty, funkcje, zmienne, kod file nazwy, katalogi kodów i ciągi znaków będą w Courier New.
Polecenia lub teksty, które użytkownik musi wprowadzić, a także polecenia, które można wprowadzić za pomocą klawisza „Enter”, zostaną wydrukowane czcionką Courier New pogrubioną czcionką. Logi i bloki kodu będą prezentowane w jasnoniebieskich ramkach.
Exampna:
Po drugie, użyj esp-idf/components/nvs flash/nvs partycja generator/nvs partycja gen.py, aby wygenerować plik binarny partycji NVS file na hoście deweloperskim za pomocą następującego polecenia:
$ python $IDF PATH/komponenty/nvs flash/generator partycji nvs/partycja nvs gen.py – masa wejściowa prod.csv – masa wyjściowa prod.bin – rozmiar ROZMIAR PARTYCJI NVS

Rozdział 1

Wstęp

Do

IoT

Pod koniec XX wieku, wraz z rozwojem sieci komputerowych i technologii komunikacyjnych, Internet szybko włączył się w życie ludzi. Wraz z rozwojem technologii internetowej narodził się pomysł Internetu Rzeczy (IoT). Dosłownie IoT oznacza Internet, w którym rzeczy są ze sobą połączone. Podczas gdy pierwotny Internet przełamuje ograniczenia przestrzeni i czasu oraz zawęża dystans między „osobą a osobą”, Internet Rzeczy sprawia, że ​​„rzeczy” stają się ważnym uczestnikiem, zbliżając „ludzi” i „rzeczy”. W dającej się przewidzieć przyszłości IoT stanie się siłą napędową branży informacyjnej.
Czym zatem jest Internet Rzeczy?
Trudno jest dokładnie zdefiniować Internet Rzeczy, gdyż jego znaczenie i zakres stale ewoluują. W 1995 roku Bill Gates po raz pierwszy poruszył ideę Internetu Rzeczy w swojej książce The Road Ahead. Mówiąc najprościej, IoT umożliwia obiektom wymianę informacji między sobą za pośrednictwem Internetu. Jego ostatecznym celem jest ustanowienie „Internetu wszystkiego”. To wczesna interpretacja IoT, a także fantazja o technologii przyszłości. Trzydzieści lat później, wraz z szybkim rozwojem gospodarki i technologii, fantazja staje się rzeczywistością. Od inteligentnych urządzeń, inteligentnych domów, inteligentnych miast, Internetu pojazdów i urządzeń do noszenia, po „metawers” ​​wspierany przez technologie IoT – stale pojawiają się nowe koncepcje. W tym rozdziale zaczniemy od wyjaśnienia architektury Internetu rzeczy, a następnie przedstawimy najpopularniejsze zastosowanie IoT, czyli inteligentny dom, aby pomóc Ci w jasnym zrozumieniu IoT.
1.1 Architektura IoT
Internet rzeczy obejmuje wiele technologii, które mają różne potrzeby i formy zastosowań w różnych branżach. Aby uporządkować strukturę, kluczowe technologie i charakterystykę zastosowań IoT, konieczne jest ustalenie jednolitej architektury i standardowego systemu technicznego. W tej książce architekturę Internetu Rzeczy podzielono po prostu na cztery warstwy: warstwę percepcji i kontroli, warstwę sieci, warstwę platformy i warstwę aplikacji.
Warstwa percepcji i kontroli Jako najbardziej podstawowy element architektury IoT, warstwa percepcji i kontroli stanowi rdzeń umożliwiający kompleksowe wykrywanie IoT. Jego główną funkcją jest zbieranie, identyfikacja i kontrola informacji. Składa się z różnorodnych urządzeń posiadających zdolność percepcji,
3

identyfikację, kontrolę i wykonanie oraz jest odpowiedzialny za pobieranie i analizowanie danych, takich jak właściwości materiałów, trendy behawioralne i stan urządzenia. W ten sposób IoT rozpoznaje prawdziwy świat fizyczny. Poza tym warstwa może również kontrolować stan urządzenia.
Najbardziej powszechnymi urządzeniami tej warstwy są różnego rodzaju czujniki, które pełnią ważną rolę w zbieraniu i identyfikacji informacji. Czujniki przypominają ludzkie narządy zmysłów, takie jak czujniki światłoczułe odpowiadające wzrokowi, czujniki akustyczne odpowiadające słuchowi, czujniki gazu reagujące na węch oraz czujniki wrażliwe na nacisk i temperaturę dotykające. Dzięki tym wszystkim „narządom zmysłów” przedmioty stają się „ożywione” i zdolne do inteligentnej percepcji, rozpoznawania i manipulacji światem fizycznym.
Warstwa sieciowa Główną funkcją warstwy sieciowej jest przesyłanie informacji, w tym danych uzyskanych z warstwy percepcji i kontroli do określonego celu, a także poleceń wydawanych z warstwy aplikacji z powrotem do warstwy percepcji i kontroli. Pełni funkcję ważnego mostu komunikacyjnego łączącego różne warstwy systemu IoT. Stworzenie podstawowego modelu Internetu rzeczy obejmuje dwa etapy integracji obiektów w sieć: dostęp do Internetu i transmisję przez Internet.
Dostęp do Internetu Internet umożliwia wzajemne powiązanie osoby z osobą, ale nie pozwala na włączenie rzeczy do wielkiej rodziny. Przed pojawieniem się Internetu Rzeczy większość rzeczy nie nadawała się do podłączenia do sieci. Dzięki ciągłemu rozwojowi technologii IoT udaje się łączyć rzeczy z Internetem, realizując w ten sposób wzajemne powiązanie między „ludźmi i rzeczami” oraz „rzeczami i rzeczami”. Istnieją dwa popularne sposoby realizacji połączenia internetowego: dostęp do sieci przewodowej i dostęp do sieci bezprzewodowej.
Metody dostępu do sieci przewodowej obejmują Ethernet, komunikację szeregową (np. RS-232, RS-485) i USB, natomiast dostęp do sieci bezprzewodowej zależy od komunikacji bezprzewodowej, którą można dalej podzielić na komunikację bezprzewodową krótkiego zasięgu i komunikację bezprzewodową dalekiego zasięgu.
Komunikacja bezprzewodowa krótkiego zasięgu obejmuje ZigBee, Bluetoothr, Wi-Fi, komunikację bliskiego zasięgu (NFC) i identyfikację radiową (RFID). Komunikacja bezprzewodowa dalekiego zasięgu obejmuje ulepszoną komunikację typu maszynowego (eMTC), LoRa, wąskopasmowy Internet rzeczy (NB-IoT), 2G, 3G, 4G, 5G itp.
Transmisja przez Internet Różne metody dostępu do Internetu prowadzą do odpowiedniego fizycznego łącza transmisji danych. Następną rzeczą jest podjęcie decyzji, jakiego protokołu komunikacyjnego użyć do przesyłania danych. W porównaniu z terminalami internetowymi większość terminali IoT ma obecnie ich mniej
4 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

dostępne zasoby, takie jak wydajność przetwarzania, pojemność pamięci, przepustowość sieci itp., dlatego konieczne jest wybranie protokołu komunikacyjnego, który w zastosowaniach IoT zajmuje mniej zasobów. Obecnie powszechnie stosowane są dwa protokoły komunikacyjne: Message Queuing Telemetry Transport (MQTT) i Constrained Application Protocol (CoAP).
Warstwa platformy Warstwa platformy odnosi się głównie do platform chmurowych IoT. Gdy wszystkie terminale IoT są połączone w sieć, ich dane muszą zostać zagregowane na platformie chmurowej IoT, aby mogły zostać obliczone i zapisane. Warstwa platformy wspiera głównie aplikacje IoT w ułatwianiu dostępu i zarządzania masywnymi urządzeniami. Łączy terminale IoT z platformą chmurową, zbiera dane terminali i wydaje polecenia terminalom w celu wdrożenia zdalnego sterowania. Jako usługa pośrednia służąca przydzielaniu sprzętu do zastosowań przemysłowych, warstwa platformy odgrywa rolę łączącą w całej architekturze IoT, przenosząc abstrakcyjną logikę biznesową i ustandaryzowany podstawowy model danych, który może nie tylko zapewnić szybki dostęp do urządzeń, ale także zapewnić potężne możliwości modułowe w celu zaspokojenia różnych potrzeb w scenariuszach zastosowań przemysłowych. Warstwa platformy obejmuje głównie moduły funkcjonalne, takie jak dostęp do urządzeń, zarządzanie urządzeniami, zarządzanie bezpieczeństwem, komunikacja komunikatów, monitorowanie operacji i konserwacji oraz aplikacje danych.
· Dostęp do urządzeń, realizujący połączenie i komunikację pomiędzy terminalami i platformami chmurowymi IoT.
· Zarządzanie urządzeniami, w tym funkcje takie jak tworzenie urządzeń, konserwacja urządzeń, konwersja danych, synchronizacja danych i dystrybucja urządzeń.
· Zarządzanie bezpieczeństwem, zapewnienie bezpieczeństwa transmisji danych IoT z punktu widzenia uwierzytelniania bezpieczeństwa i bezpieczeństwa komunikacji.
· Komunikacja komunikatów obejmująca trzy kierunki transmisji, czyli terminal wysyła dane do platformy chmurowej IoT, platforma chmurowa IoT przesyła dane po stronie serwera lub innych platform chmurowych IoT, a strona serwera zdalnie steruje urządzeniami IoT.
· Monitorowanie obsługi i utrzymania, obejmujące monitorowanie i diagnostykę, aktualizację oprogramowania sprzętowego, debugowanie online, usługi dziennika itp.
· Aplikacje danych, obejmujące przechowywanie, analizę i wykorzystanie danych.
Warstwa aplikacji Warstwa aplikacji wykorzystuje dane z warstwy platformy do zarządzania aplikacją, filtrowania ich i przetwarzania za pomocą narzędzi takich jak bazy danych i oprogramowanie analityczne. Uzyskane dane można wykorzystać w rzeczywistych zastosowaniach IoT, takich jak inteligentna opieka zdrowotna, inteligentne rolnictwo, inteligentne domy i inteligentne miasta.
Oczywiście architekturę IoT można podzielić na więcej warstw, ale niezależnie od tego, z ilu warstw się składa, podstawowa zasada pozostaje zasadniczo taka sama. Nauka
Rozdział 1. Wprowadzenie do IoT 5

na temat architektury IoT pomaga pogłębić naszą wiedzę na temat technologii IoT i budować w pełni funkcjonalne projekty IoT.
1.2 Zastosowanie IoT w inteligentnych domach
IoT przeniknął do wszystkich dziedzin życia, a najbardziej powiązaną z nami aplikacją IoT jest inteligentny dom. Wiele tradycyjnych urządzeń jest obecnie wyposażonych w jedno lub więcej urządzeń IoT, a wiele nowo budowanych domów od początku projektowanych jest z wykorzystaniem technologii IoT. Rysunek 1.1 przedstawia niektóre popularne urządzenia inteligentnego domu.
Rysunek 1.1. Popularne urządzenia inteligentnego domu Rozwój inteligentnego domu można po prostu podzielić na inteligentne produktytage, połączenie scen stage i inteligentne stage, jak pokazano na rysunku 1.2.
Rysunek 1.2. Rozwój stage inteligentnego domu 6 ESP32-C3 Wireless Adventure: kompleksowy przewodnik po IoT

Pierwszy stage dotyczy inteligentnych produktów. W odróżnieniu od tradycyjnych domów, w inteligentnych domach urządzenia IoT odbierają sygnały za pomocą czujników i są połączone w sieć za pośrednictwem technologii komunikacji bezprzewodowej, takich jak Wi-Fi, Bluetooth LE i ZigBee. Użytkownicy mogą sterować inteligentnymi produktami na różne sposoby, takimi jak aplikacje na smartfony, asystenci głosowi, inteligentne sterowanie głośnikami itp.tage skupia się na wzajemnym powiązaniu scen. W tym stage, programiści nie rozważają już kontrolowania pojedynczego inteligentnego produktu, ale połączenie dwóch lub więcej inteligentnych produktów, do pewnego stopnia automatyzując i ostatecznie tworząc niestandardowy tryb sceny. Na przykładample, gdy użytkownik naciśnie dowolny przycisk trybu sceny, światła, zasłony i klimatyzatory zostaną automatycznie dostosowane do ustawień wstępnych. Oczywiście warunkiem wstępnym jest łatwe skonfigurowanie logiki powiązań, w tym warunków wyzwalania i działań wykonawczych. Wyobraź sobie, że tryb ogrzewania klimatyzacji zostaje uruchomiony, gdy temperatura w pomieszczeniu spadnie poniżej 10°C; że o godzinie 7 rano włącza się muzyka, która ma obudzić użytkownika, otwierają się inteligentne zasłony, a urządzenie do gotowania ryżu lub tostera uruchamia się poprzez inteligentne gniazdko; gdy użytkownik wstanie i skończy się myć, śniadanie jest już podawane, dzięki czemu nie będzie opóźnień w pójściu do pracy. Jak wygodne stało się nasze życie! Trzeci stage idzie do inteligencji stagmi. W miarę zwiększania się dostępu do inteligentnych urządzeń domowych wzrastać będzie także ilość generowanych danych. Przy pomocy chmury obliczeniowej, big data i sztucznej inteligencji jakby w inteligentne domy wszczepiono „inteligentniejszy mózg”, który nie wymaga już częstych poleceń od użytkownika. Zbierają dane z poprzednich interakcji oraz poznają wzorce zachowań i preferencje użytkownika, aby automatyzować działania, w tym przekazywać rekomendacje przy podejmowaniu decyzji. Obecnie większość inteligentnych domów znajduje się na scenie połączeń stagmi. Wraz ze wzrostem współczynnika penetracji i inteligencji inteligentnych produktów, bariery między protokołami komunikacyjnymi są usuwane. Inteligentne domy z pewnością staną się w przyszłości naprawdę „inteligentne”, podobnie jak system AI Jarvis w Iron Man, który może nie tylko pomóc użytkownikowi kontrolować różne urządzenia, zajmować się codziennymi sprawami, ale także posiadać super moc obliczeniową i zdolność myślenia. W inteligentnych stage, istoty ludzkie otrzymają lepsze usługi zarówno pod względem ilościowym, jak i jakościowym.
Rozdział 1. Wprowadzenie do IoT 7

8 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Rozdział Wprowadzenie i praktyka 2 projektów IoT
W Rozdziale 1 przedstawiliśmy architekturę IoT oraz role i wzajemne powiązania warstwy percepcji i kontroli, warstwy sieci, warstwy platformy i warstwy aplikacji, a także rozwój inteligentnego domu. Jednak podobnie jak wtedy, gdy uczymy się malować, wiedza teoretyczna nie wystarczy. Musimy „ubrudzić sobie ręce”, aby wcielić projekty IoT w życie, aby naprawdę opanować technologię. Dodatkowo, gdy projekt przechodzi do produkcji masowej stage, należy wziąć pod uwagę więcej czynników, takich jak połączenie sieciowe, konfiguracja, interakcja z platformą chmurową IoT, zarządzanie oprogramowaniem sprzętowym i aktualizacjami, zarządzanie produkcją masową i konfiguracja zabezpieczeń. Na co zatem musimy zwrócić uwagę, opracowując kompletny projekt IoT? W Rozdziale 1 wspomnieliśmy, że inteligentny dom to jeden z najczęstszych scenariuszy zastosowań IoT, a inteligentne oświetlenie to jedno z najbardziej podstawowych i praktycznych urządzeń, które można zastosować w domach, hotelach, siłowniach, szpitalach itp. Dlatego też w Rozdziale XNUMX w tej książce za punkt wyjścia przyjmiemy konstrukcję projektu inteligentnego oświetlenia, wyjaśnimy jego komponenty i funkcje oraz udzielimy wskazówek dotyczących opracowania projektu. Mamy nadzieję, że wyciągniecie wnioski z tego przypadku i stworzycie więcej aplikacji IoT.
2.1 Wprowadzenie do typowych projektów IoT
Pod względem rozwoju podstawowe moduły funkcjonalne projektów IoT można podzielić na rozwój oprogramowania i sprzętu urządzeń IoT, rozwój aplikacji klienckich oraz rozwój platformy chmurowej IoT. Ważne jest wyjaśnienie podstawowych modułów funkcjonalnych, które zostaną szerzej opisane w tej sekcji.
2.1.1 Podstawowe moduły dla popularnych urządzeń IoT
Rozwój oprogramowania i sprzętu urządzeń IoT obejmuje następujące podstawowe moduły: Zbieranie danych
Urządzenia IoT warstwy percepcyjnej i kontrolnej, stanowiące dolną warstwę architektury IoT, łączą czujniki i urządzenia za pośrednictwem chipów i urządzeń peryferyjnych, aby umożliwić gromadzenie danych i kontrolę działania.
9

Powiązanie konta i wstępna konfiguracja W przypadku większości urządzeń IoT powiązanie konta i wstępna konfiguracja są przeprowadzane w jednym procesie operacyjnym, npample, łączenie urządzeń z użytkownikami poprzez konfigurację sieci Wi-Fi.
Interakcja z platformami chmurowymi IoT Aby monitorować i sterować urządzeniami IoT, konieczne jest także połączenie ich z platformami chmurowymi IoT, aby móc wydawać polecenia i raportować stan poprzez wzajemną interakcję.
Kontrola urządzeń Po połączeniu z platformami chmurowymi IoT urządzenia mogą komunikować się z chmurą i być rejestrowane, powiązane lub kontrolowane. Użytkownicy mogą sprawdzać stan produktu i wykonywać inne operacje w aplikacji na smartfona za pośrednictwem platform chmurowych IoT lub lokalnych protokołów komunikacyjnych.
Aktualizacja oprogramowania sprzętowego Urządzenia IoT mogą również dokonać aktualizacji oprogramowania sprzętowego w oparciu o potrzeby producentów. Otrzymując polecenia wysyłane przez chmurę, zostanie zrealizowana aktualizacja oprogramowania sprzętowego i zarządzanie wersjami. Dzięki tej funkcji aktualizacji oprogramowania sprzętowego możesz stale ulepszać funkcje urządzeń IoT, naprawiać defekty i poprawiać komfort użytkowania.
2.1.2 Podstawowe moduły aplikacji klienckich
Aplikacje klienckie (np. aplikacje na smartfony) składają się głównie z następujących podstawowych modułów:
System kont i autoryzacja Obsługuje autoryzację kont i urządzeń.
Sterowanie urządzeniami Aplikacje na smartfony są zazwyczaj wyposażone w funkcje sterujące. Użytkownicy mogą łatwo łączyć się z urządzeniami IoT i zarządzać nimi w dowolnym miejscu i czasie za pomocą aplikacji na smartfony. W prawdziwym inteligentnym domu urządzenia są sterowane głównie za pomocą aplikacji na smartfony, co nie tylko umożliwia inteligentne zarządzanie urządzeniami, ale także oszczędza koszty siły roboczej. Dlatego też sterowanie urządzeniami jest koniecznością w przypadku aplikacji klienckich, np. sterowanie atrybutami funkcji urządzenia, sterowanie scenami, planowanie, zdalne sterowanie, łączenie urządzeń itp. Użytkownicy inteligentnych domów mogą również dostosowywać sceny do osobistych potrzeb, sterując oświetleniem, urządzeniami gospodarstwa domowego, wejściem itp., aby życie w domu było wygodniejsze i wygodniejsze. Mogą ustawić czas działania klimatyzacji, zdalnie ją wyłączyć, automatycznie włączyć światło w przedpokoju po odblokowaniu drzwi lub przełączyć się w tryb „kinowy” za pomocą jednego przycisku.
Powiadomienia Aplikacje klienckie aktualizują w czasie rzeczywistym stan urządzeń IoT i wysyłają alerty, gdy urządzenia działają nieprawidłowo.
10 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Posprzedażowa obsługa klienta Aplikacje na smartfony mogą zapewniać obsługę posprzedażową produktów, aby w odpowiednim czasie rozwiązywać problemy związane z awariami urządzeń IoT i operacjami technicznymi.
Polecane funkcje Aby sprostać potrzebom różnych użytkowników, można dodać inne funkcje, takie jak Shake, NFC, GPS itp. GPS może pomóc w ustaleniu dokładności operacji na scenie w zależności od lokalizacji i odległości, natomiast funkcja Shake pozwala użytkownikom ustawić polecenia do wykonania dla konkretnego urządzenia lub sceny poprzez potrząsanie.
2.1.3 Wprowadzenie do powszechnych platform chmurowych IoT
Platforma chmurowa IoT to platforma typu „wszystko w jednym”, która integruje takie funkcje, jak zarządzanie urządzeniami, komunikacja w zakresie bezpieczeństwa danych i zarządzanie powiadomieniami. Ze względu na grupę docelową i dostępność platformy chmurowe IoT można podzielić na publiczne platformy chmurowe IoT (zwane dalej „chmurą publiczną”) oraz prywatne platformy chmurowe IoT (zwane dalej „chmurą prywatną”).
Chmura publiczna zwykle oznacza współdzielone platformy chmurowe IoT dla przedsiębiorstw lub osób fizycznych, obsługiwane i utrzymywane przez dostawców platform oraz udostępniane za pośrednictwem Internetu. Może być bezpłatna lub tania i zapewnia usługi w całej otwartej sieci publicznej, takiej jak Alibaba Cloud, Tencent Cloud, Baidu Cloud, AWS IoT, Google IoT itp. Jako platforma wspierająca, chmura publiczna może integrować dostawców usług wyższego szczebla i dalszym użytkownikom końcowym w celu stworzenia nowego łańcucha wartości i ekosystemu.
Chmura prywatna jest zbudowana wyłącznie do użytku korporacyjnego, co gwarantuje najlepszą kontrolę nad danymi, bezpieczeństwem i jakością usług. Jej usługi i infrastruktura są utrzymywane oddzielnie przez przedsiębiorstwa, a wspierający sprzęt i oprogramowanie są również dedykowane konkretnym użytkownikom. Przedsiębiorstwa mogą dostosowywać usługi w chmurze do potrzeb swojej działalności. Obecnie niektórzy producenci inteligentnych domów posiadają już prywatne platformy chmurowe IoT i w oparciu o nie opracowują aplikacje inteligentnego domu.
Chmura publiczna i chmura prywatna mają swoje zaletytages, co zostanie wyjaśnione później.
Aby osiągnąć łączność komunikacyjną, konieczne jest ukończenie przynajmniej oprogramowania wbudowanego po stronie urządzenia, wraz z serwerami biznesowymi, platformami chmurowymi IoT i aplikacjami na smartfony. W obliczu tak ogromnego projektu chmura publiczna zwykle zapewnia zestawy programistyczne dla aplikacji na urządzenia i smartfony, aby przyspieszyć proces. Zarówno chmura publiczna, jak i prywatna zapewniają usługi, w tym dostęp do urządzeń, zarządzanie urządzeniami, cień urządzenia oraz obsługę i konserwację.
Dostęp do urządzeń Platformy chmurowe IoT muszą zapewniać nie tylko interfejsy umożliwiające dostęp do urządzeń za pomocą protokołów
Rozdział 2. Wprowadzenie i praktyka projektów IoT 11

takie jak MQTT, CoAP, HTTPS i WebSocket, ale także funkcja uwierzytelniania bezpieczeństwa urządzenia w celu blokowania sfałszowanych i nielegalnych urządzeń, skutecznie zmniejszając ryzyko naruszenia bezpieczeństwa. Takie uwierzytelnianie obsługuje zazwyczaj różne mechanizmy, dlatego w przypadku urządzeń produkowanych masowo konieczne jest wstępne przypisanie certyfikatu urządzenia zgodnie z wybranym mechanizmem uwierzytelniania i wypalenie go w urządzeniach.
Zarządzanie urządzeniami Funkcja zarządzania urządzeniami udostępniana przez platformy chmurowe IoT może nie tylko pomóc producentom monitorować status aktywacji i status online ich urządzeń w czasie rzeczywistym, ale także umożliwia takie opcje, jak dodawanie/usuwanie urządzeń, odzyskiwanie, dodawanie/usuwanie grup, aktualizacja oprogramowania sprzętowego i zarządzanie wersjami.
Platformy chmurowe Cień urządzenia IoT mogą tworzyć trwałą wersję wirtualną (cień urządzenia) dla każdego urządzenia, a status cienia urządzenia można synchronizować i uzyskiwać za pomocą aplikacji na smartfony lub inne urządzenia za pośrednictwem protokołów transmisji Internetu. Cień urządzenia przechowuje najnowszy zgłoszony stan i oczekiwany stan każdego urządzenia, a nawet jeśli urządzenie jest w trybie offline, nadal może uzyskać status, wywołując interfejsy API. Cień urządzenia zapewnia zawsze włączone interfejsy API, co ułatwia tworzenie aplikacji na smartfony wchodzących w interakcję z urządzeniami.
Obsługa i konserwacja Funkcja O&M obejmuje trzy aspekty: · Prezentowanie informacji statystycznych na temat urządzeń IoT i powiadomień. · Zarządzanie logami umożliwia pobieranie informacji o zachowaniu urządzenia, przepływie wiadomości w górę/w dół i treści wiadomości. · Debugowanie urządzeń obsługuje dostarczanie poleceń, aktualizację konfiguracji i sprawdzanie interakcji pomiędzy platformami chmurowymi IoT a komunikatami urządzenia.
2.2 Praktyka: Projekt inteligentnego światła
Po teoretycznym wprowadzeniu w każdym rozdziale znajdziesz część ćwiczeniową związaną z projektem Smart Light, która pomoże Ci zdobyć praktyczne doświadczenie. Projekt opiera się na chipie ESP32-C3 firmy Espressif i platformie ESP RainMaker IoT Cloud i obejmuje moduły bezprzewodowe w inteligentnych produktach oświetleniowych, wbudowane oprogramowanie dla inteligentnych urządzeń oparte na ESP32C3, aplikacje na smartfony i interakcję ESP RainMaker.
Kod źródłowy Aby zapewnić lepszą naukę i rozwój doświadczenia, projekt opisany w tej książce został udostępniony na zasadach open source. Kod źródłowy możesz pobrać z naszego repozytorium GitHub pod adresem https://github. com/espressif/book-esp32c3-iot-projects.
12 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

2.2.1 Struktura projektu
Projekt Smart Light składa się z trzech części: Inteligentne urządzenia oświetleniowe oparte na ESP32-C3, odpowiedzialne za interakcję z platformami chmurowymi IoT oraz sterowanie włącznikiem, jasnością i temperaturą barwową diody LED lamp sieczka. II. Aplikacje na smartfony (w tym aplikacje na tablety działające na systemach Android i iOS), odpowiedzialne za konfigurację sieciową inteligentnych produktów oświetleniowych, a także odpytywanie i kontrolowanie ich stanu.
iii. Platforma chmurowa IoT oparta na ESP RainMaker. Dla uproszczenia w tej książce rozważymy platformę chmurową IoT i serwer biznesowy jako całość. Szczegóły dotyczące ESP RainMaker zostaną podane w Rozdziale 3.
Zależność pomiędzy strukturą projektu Smart Light a architekturą IoT pokazano na rysunku 2.1.
Rysunek 2.1. Struktura projektu inteligentnego oświetlenia
2.2.2 Funkcje projektu
Podzielone według struktury funkcje każdej części są następujące. Inteligentne urządzenia oświetleniowe
· Konfiguracja sieci i połączenie. · Sterowanie LED PWM, np. włącznikiem, jasnością, temperaturą barwową itp. · Sterowanie automatyką lub sceną, np. wyłącznikiem czasowym. · Szyfrowanie i bezpieczny rozruch Flasha. · Aktualizacja oprogramowania sprzętowego i zarządzanie wersjami.
Rozdział 2. Wprowadzenie i praktyka projektów IoT 13

Aplikacje na smartfony · Konfiguracja sieci i powiązanie urządzenia. · Inteligentna kontrola produktów oświetleniowych, np. włącznik, jasność, temperatura barwowa itp. · Ustawienia automatyki lub sceny, np. wyłącznik czasowy. · Sterowanie lokalne/zdalne. · Rejestracja użytkownika, logowanie itp.
Platforma chmurowa ESP RainMaker IoT · Umożliwianie dostępu do urządzeń IoT. · Udostępnienie interfejsów API obsługi urządzenia dostępnych dla aplikacji na smartfony. · Aktualizacja oprogramowania sprzętowego i zarządzanie wersjami.
2.2.3 Przygotowanie sprzętu
Jeśli jesteś zainteresowany wdrożeniem projektu w życie, będziesz potrzebować również następującego sprzętu: inteligentne oświetlenie, smartfony, routery Wi-Fi oraz komputer spełniający wymagania instalacyjne środowiska programistycznego. Inteligentne światła
Inteligentne światła to nowy rodzaj żarówek, których kształt nawiązuje do zwykłej żarówki. Inteligentne światło składa się z zasilacza obniżającego napięcie kondensatora, modułu bezprzewodowego (z wbudowanym ESP32-C3), kontrolera LED i matrycy LED RGB. Po podłączeniu do zasilania napięcie 15 V DC objtagWyjście po obniżeniu napięcia kondensatora, prostowaniu diody i regulacji dostarcza energię do sterownika LED i matrycy LED. Kontroler LED może automatycznie wysyłać wysokie i niskie poziomy w określonych odstępach czasu, przełączając matrycę LED RGB między zamkniętą (świeci się) a otwartą (światło wyłączone), dzięki czemu może emitować cyjan, żółty, zielony, fioletowy, niebieski, czerwony i białe światło. Moduł bezprzewodowy odpowiada za połączenie z routerem Wi-Fi, odbieranie i raportowanie stanu inteligentnych świateł oraz wysyłanie poleceń sterujących diodą LED.
Rysunek 2.2. Symulowane inteligentne światło
We wczesnym rozwoju stage, możesz symulować inteligentne światło za pomocą płytki ESP32-C3DevKitM-1 połączonej z diodą LED RGB lamp koraliki (patrz rysunek 2.2). Ale powinieneś
14 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

pamiętaj, że nie jest to jedyny sposób na złożenie inteligentnego światła. Projekt sprzętowy projektu przedstawionego w tej książce obejmuje jedynie moduł bezprzewodowy (z wbudowanym ESP32-C3), ale nie zawiera kompletnego projektu sprzętowego inteligentnego oświetlenia. Ponadto firma Espressif produkuje również płytkę rozwojową audio ESP32C3-Lyra opartą na ESP32-C3, służącą do sterowania oświetleniem za pomocą dźwięku. Płytka posiada interfejsy dla mikrofonów i głośników oraz umożliwia sterowanie paskami LED. Można go używać do opracowywania bardzo tanich i wydajnych nadawców audio i rytmicznych pasków świetlnych. Rysunek 2.3 przedstawia płytkę ESP32-C3Lyra połączoną z paskiem 40 diod LED.
Rysunek 2.3. ESP32-C3-Lyra połączona z paskiem 40 diod LED
Smartfony (Android/iOS) Projekt Smart Light obejmuje opracowanie aplikacji na smartfony umożliwiającej konfigurowanie i kontrolowanie inteligentnych produktów oświetleniowych.
Routery Wi-Fi Routery Wi-Fi konwertują sygnały sieci przewodowej i sygnały sieci komórkowej na sygnały sieci bezprzewodowej, dzięki czemu komputery, smartfony, tablety i inne urządzenia bezprzewodowe mogą łączyć się z siecią. Na przykładample, szerokopasmowe łącze w domu wystarczy podłączyć do routera Wi-Fi, aby uzyskać bezprzewodową sieć urządzeń Wi-Fi. Głównym standardem protokołu obsługiwanym przez routery Wi-Fi jest IEEE 802.11n, ze średnią szybkością TxRate wynoszącą 300 Mb/s lub maksymalnie 600 Mb/s. Są wstecznie kompatybilne ze standardami IEEE 802.11b i IEEE 802.11g. Układ ESP32-C3 firmy Espressif obsługuje standard IEEE 802.11b/g/n, dzięki czemu możesz wybrać router Wi-Fi jednopasmowy (2.4 GHz) lub dwuzakresowy (2.4 GHz i 5 GHz).
Komputerowe środowisko programistyczne (Linux/macOS/Windows) zostanie przedstawione w Rozdziale 4. Rozdział 2. Wprowadzenie i praktyka w projektach IoT 15

2.2.4 Proces rozwoju
Rysunek 2.4. Etapy rozwoju projektu Smart Light
Projektowanie sprzętu Projektowanie sprzętu urządzeń IoT jest niezbędne w projekcie IoT. Kompletny projekt inteligentnego oświetlenia ma wyprodukować alamp pracujący pod napięciem sieciowym. Różni producenci produkują lampmają różne style i typy sterowników, ale ich moduły bezprzewodowe mają zwykle tę samą funkcję. Aby uprościć proces rozwoju projektu Smart Ligh, w tej książce omówiono jedynie projektowanie sprzętu i tworzenie oprogramowania modułów bezprzewodowych.
Konfiguracja platformy chmurowej IoT Aby korzystać z platform chmurowych IoT, należy skonfigurować projekty na backendzie, takie jak tworzenie produktów, tworzenie urządzeń, ustawianie właściwości urządzeń itp.
Tworzenie wbudowanego oprogramowania dla urządzeń IoT Wdrażaj oczekiwane funkcje za pomocą ESP-IDF, pakietu SDK firmy Espressif po stronie urządzenia, w tym łączenie się z platformami chmurowymi IoT, opracowywanie sterowników LED i aktualizacja oprogramowania sprzętowego.
Tworzenie aplikacji na smartfony Twórz aplikacje na smartfony dla systemów Android i iOS w celu realizacji rejestracji i logowania użytkowników, kontroli urządzeń i innych funkcji.
Optymalizacja urządzeń IoT Po zakończeniu podstawowego rozwoju funkcji urządzenia IoT można przejść do zadań optymalizacyjnych, takich jak optymalizacja mocy.
Testowanie produkcji masowej Przeprowadzaj testy produkcji masowej zgodnie z powiązanymi normami, takimi jak test działania sprzętu, test starzenia, test RF itp.
Pomimo opisanych powyżej kroków, projekt Smart Light niekoniecznie podlega takiej procedurze, ponieważ w tym samym czasie można realizować różne zadania. Na przykładample, oprogramowanie wbudowane i aplikacje na smartfony mogą być rozwijane równolegle. Niektóre kroki, takie jak optymalizacja urządzeń IoT i testowanie produkcji masowej, mogą również wymagać powtórzenia.
16 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

2.3 Podsumowanie
W tym rozdziale najpierw wyjaśniliśmy podstawowe komponenty i moduły funkcjonalne projektu IoT, a następnie przedstawiliśmy w praktyce przypadek Smart Light, odnosząc się do jego struktury, funkcji, przygotowania sprzętu i procesu rozwoju. Czytelnicy mogą wyciągnąć wnioski z praktyki i zyskać pewność, że w przyszłości będą w stanie realizować projekty IoT przy minimalnej liczbie błędów.
Rozdział 2. Wprowadzenie i praktyka projektów IoT 17

18 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Rozdział 3

Wstęp

Do

ESP

Deszczotwórca

Internet rzeczy (IoT) oferuje nieograniczone możliwości zmiany sposobu życia ludzi, jednak rozwój inżynierii IoT jest pełen wyzwań. Dzięki chmurom publicznym producenci terminali mogą wdrażać funkcjonalność produktów za pomocą następujących rozwiązań:
W oparciu o platformy chmurowe dostawców rozwiązań. W ten sposób producenci terminali muszą jedynie zaprojektować sprzęt produktu, następnie podłączyć sprzęt do chmury za pomocą dostarczonego modułu komunikacyjnego i skonfigurować funkcje produktu zgodnie z wytycznymi. Jest to wydajne podejście, ponieważ eliminuje potrzebę programowania oraz obsługi i konserwacji (O&M) po stronie serwera i aplikacji. Pozwala producentom terminali skoncentrować się na projektowaniu sprzętu bez konieczności rozważania wdrożenia chmury. Jednakże takie rozwiązania (np. oprogramowanie sprzętowe urządzenia i aplikacja) zazwyczaj nie są oprogramowaniem typu open source, więc funkcje produktu będą ograniczone przez platformę chmurową dostawcy, której nie można dostosować. Tymczasem dane użytkowników i urządzeń również należą do platformy chmurowej.
W oparciu o produkty chmurowe W tym rozwiązaniu po zakończeniu projektowania sprzętu producenci terminali muszą nie tylko wdrożyć funkcje chmurowe z wykorzystaniem jednego lub większej liczby produktów chmurowych udostępnianych przez chmurę publiczną, ale także muszą połączyć sprzęt z chmurą. Na przykładample, aby połączyć się z Amazon Web Services (AWS) producenci terminali muszą korzystać z produktów AWS, takich jak Amazon API Gateway, AWS IoT Core i AWS Lambda, aby umożliwić dostęp do urządzenia, zdalne sterowanie, przechowywanie danych, zarządzanie użytkownikami i inne podstawowe funkcje. Nie tylko wymaga od producentów terminali elastycznego korzystania i konfigurowania produktów w chmurze przy dogłębnym zrozumieniu i bogatym doświadczeniu, ale także wymaga od nich uwzględnienia kosztów budowy i utrzymania w początkowej i późniejszej fazietages Stanowi to ogromne wyzwanie dla energii i zasobów firmy.
W porównaniu z chmurami publicznymi, chmury prywatne są zwykle budowane na potrzeby konkretnych projektów i produktów. Twórcy chmury prywatnej otrzymują najwyższy poziom swobody w projektowaniu protokołów i wdrażaniu logiki biznesowej. Producenci terminali mogą dowolnie tworzyć produkty i projekty, a także łatwo integrować i zwiększać możliwości danych użytkowników. Łączenie wysokiego bezpieczeństwa, skalowalności i niezawodności chmury publicznej z zaawansowaną technologiątages chmury prywatnej, firma Espressif uruchomiła ESP
19

RainMaker, głęboko zintegrowane rozwiązanie chmury prywatnej oparte na chmurze Amazon. Użytkownicy mogą wdrożyć ESP RainMaker i zbudować prywatną chmurę po prostu za pomocą konta AWS.
3.1 Co to jest ESP RainMaker?
ESP RainMaker to kompletna platforma AIoT zbudowana z wielu dojrzałych produktów AWS. Zapewnia różne usługi wymagane w masowej produkcji, takie jak dostęp do chmury urządzeń, aktualizacja urządzeń, zarządzanie backendem, logowanie przez strony trzecie, integracja głosowa i zarządzanie użytkownikami. Korzystając z bezserwerowego repozytorium aplikacji (SAR) udostępnianego przez AWS, producenci terminali mogą szybko wdrożyć ESP RainMaker na swoich kontach AWS, co oszczędza czas i jest łatwe w obsłudze. Zarządzany i utrzymywany przez Espressif, SAR używany przez ESP RainMaker pomaga programistom obniżyć koszty utrzymania chmury i przyspieszyć rozwój produktów AIoT, tworząc w ten sposób bezpieczne, stabilne i konfigurowalne rozwiązania AIoT. Rysunek 3.1 przedstawia architekturę ESP RainMaker.
Rysunek 3.1. Architektura ESP RainMaker
Serwer publiczny ESP RainMaker firmy Espressif jest bezpłatny dla wszystkich entuzjastów, twórców i nauczycieli ESP w celu oceny rozwiązań. Programiści mogą logować się za pomocą kont Apple, Google lub GitHub i szybko tworzyć własne prototypy aplikacji IoT. Serwer publiczny integruje Alexę i Google Home oraz zapewnia usługi kontroli głosowej, które są obsługiwane przez Alexa Skill i Google Actions. Jego funkcja rozpoznawania semantycznego jest również obsługiwana przez strony trzecie. Urządzenia RainMaker IoT reagują tylko na określone działania. Aby uzyskać wyczerpującą listę obsługiwanych poleceń głosowych, sprawdź platformy innych firm. Ponadto Espressif oferuje publiczną aplikację RainMaker, dzięki której użytkownicy mogą kontrolować produkty za pomocą smartfonów. 20 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

3.2 Implementacja ESP RainMaker
Jak pokazano na rysunku 3.2, ESP RainMaker składa się z czterech części: · Usługa Claiming Service, umożliwiająca urządzeniom RainMaker dynamiczne uzyskiwanie certyfikatów. · RainMaker Cloud (znany również jako backend w chmurze), udostępniający usługi takie jak filtrowanie wiadomości, zarządzanie użytkownikami, przechowywanie danych i integracje z firmami zewnętrznymi. · RainMaker Agent, umożliwiający urządzeniom RainMaker łączenie się z RainMaker Cloud. · Klient RainMaker (aplikacja RainMaker lub skrypty CLI) do udostępniania, tworzenia użytkowników, kojarzenia i sterowania urządzeniami itp.
Rysunek 3.2. Struktura ESP RainMakera
ESP RainMaker zapewnia kompletny zestaw narzędzi do rozwoju produktu i produkcji masowej, w tym: RainMaker SDK
Zestaw RainMaker SDK jest oparty na ESP-IDF i udostępnia kod źródłowy agenta po stronie urządzenia oraz powiązane interfejsy API w języku C do tworzenia oprogramowania sprzętowego. Programiści muszą jedynie napisać logikę aplikacji, a resztę pozostawić frameworkowi RainMaker. Więcej informacji na temat interfejsów API języka C można znaleźć na stronie https://bookc3.espressif.com/rm/c-api-reference. Aplikacja RainMaker Publiczna wersja aplikacji RainMaker umożliwia programistom dokończenie udostępniania urządzeń oraz kontrolowanie i sprawdzanie stanu urządzeń (np. inteligentnych produktów oświetleniowych). Jest ona dostępna w sklepach z aplikacjami na iOS i Androida. Więcej szczegółów można znaleźć w rozdziale 10. Interfejsy API REST Interfejsy API REST pomagają użytkownikom tworzyć własne aplikacje podobne do aplikacji RainMaker. Więcej informacji można znaleźć na stronie https://swaggerapis.rainmaker.espressif.com/.
Rozdział 3. Wprowadzenie do ESP RainMaker 21

Interfejsy API języka Python Interfejs CLI oparty na języku Python, dostarczany z pakietem RainMaker SDK, umożliwia implementację wszystkich funkcji podobnych do funkcji smartfonów. Więcej informacji na temat interfejsów API języka Python można znaleźć na stronie https://bookc3.espressif.com/rm/python-api-reference.
Interfejs CLI administratora Interfejs CLI administratora z wyższym poziomem dostępu jest przeznaczony do prywatnego wdrożenia ESP RainMaker w celu zbiorczego generowania certyfikatów urządzeń.
3.2.1 Reklamacja usługi
Cała komunikacja pomiędzy urządzeniami RainMaker a backendem chmury odbywa się poprzez MQTT+TLS. W kontekście ESP RainMaker „Odbieranie” to proces, podczas którego urządzenia uzyskują certyfikaty z usługi zgłaszania roszczeń w celu połączenia się z zapleczem chmury. Należy pamiętać, że usługa Claiming Service ma zastosowanie wyłącznie do publicznej usługi RainMaker, natomiast w przypadku wdrożenia prywatnego certyfikaty urządzeń muszą zostać wygenerowane zbiorczo za pośrednictwem interfejsu CLI administratora. ESP RainMaker obsługuje trzy typy usług zgłaszania roszczeń: Samodzielne zgłaszanie roszczeń
Urządzenie samo pobiera certyfikaty poprzez tajny klucz zaprogramowany w eFuse po podłączeniu do Internetu. Zgłaszanie na podstawie hosta Certyfikaty są uzyskiwane od hosta programistycznego z kontem RainMaker. Wspomagane ubieganie się o certyfikaty Certyfikaty są uzyskiwane za pośrednictwem aplikacji na smartfony podczas udostępniania.
3.2.2 Agent RainMakera
Rysunek 3.3. Struktura pakietu RainMaker SDK Podstawową funkcją RainMaker Agent jest zapewnianie łączności i wspomaganie warstwy aplikacji w przetwarzaniu danych w chmurze typu uplink/downlink. Jest zbudowany w oparciu o zestaw RainMaker SDK 22 ESP32-C3 Wireless Adventure: kompleksowy przewodnik po IoT

i opracowany w oparciu o sprawdzony framework ESP-IDF, z wykorzystaniem komponentów ESP-IDF, takich jak RTOS, NVS i MQTT. Rysunek 3.3 przedstawia strukturę pakietu RainMaker SDK.
Zestaw RainMaker SDK zawiera dwie główne funkcje.
Połączenie
I. Współpraca z Claiming Service w celu uzyskania certyfikatów urządzeń.
II. Łączenie się z backendem chmury przy użyciu bezpiecznego protokołu MQTT w celu zapewnienia zdalnej łączności i wdrożenia zdalnego sterowania, raportowania komunikatów, zarządzania użytkownikami, zarządzania urządzeniami itp. Domyślnie wykorzystuje komponent MQTT w ESP-IDF i zapewnia warstwę abstrakcji do łączenia się z innymi stosy protokołów.
iii. Udostępnianie komponentu udostępniania Wi-Fi do połączeń i udostępniania Wi-Fi, szczególnie komponentu https ota do aktualizacji OTA i komponentu esp local ctrl do wykrywania i łączenia urządzeń lokalnych. Wszystkie te cele można osiągnąć poprzez prostą konfigurację.
Przetwarzanie danych
I. Przechowywanie certyfikatów urządzeń wydanych przez Claiming Service oraz danych potrzebnych do uruchomienia RainMakera, domyślnie przy użyciu interfejsu dostarczonego przez komponent nvs flash, oraz udostępnianie interfejsów API dla programistów do bezpośredniego użytku.
II. Wykorzystanie mechanizmu wywołania zwrotnego do przetwarzania danych w chmurze typu uplink/downlink i automatyczne odblokowywanie danych do warstwy aplikacji w celu łatwego przetwarzania przez programistów. Na przykładample RainMaker SDK zapewnia bogate interfejsy do ustanawiania danych TSL (ThingSpecification Language), które są wymagane do definiowania modeli TSL w celu opisania urządzeń IoT i implementacji funkcji, takich jak synchronizacja, odliczanie i sterowanie głosowe. W przypadku podstawowych funkcji interaktywnych, takich jak synchronizacja, RainMaker SDK zapewnia rozwiązanie niewymagające programowania, które można po prostu włączyć w razie potrzeby. Następnie RainMaker Agent bezpośrednio przetworzy dane, wyśle ​​je do chmury poprzez powiązany temat MQTT i przekaże informacje zwrotne o zmianach danych w chmurze poprzez mechanizm wywołania zwrotnego.
3.2.3 Backend w chmurze
Backend chmury jest zbudowany na AWS Serverless Computing i realizowany poprzez AWS Cognito (system zarządzania tożsamością), Amazon API Gateway, AWS Lambda (usługa przetwarzania bezserwerowego), Amazon DynamoDB (baza danych NoSQL), AWS IoT Core (rdzeń dostępowy IoT zapewniający dostęp MQTT i filtrowanie reguł), Amazon Simple Email Service (prosta usługa poczty SES), Amazon CloudFront (sieć szybkiej dostawy), Amazon Simple Queue Service (kolejkowanie wiadomości SQS) i Amazon S3 (usługa Bucket Storage). Ma na celu optymalizację skalowalności i bezpieczeństwa. Dzięki ESP RainMaker programiści mogą zarządzać urządzeniami bez konieczności pisania kodu w chmurze. Wiadomości zgłaszane przez urządzenia są przesyłane w sposób przejrzysty
Rozdział 3. Wprowadzenie do ESP RainMaker 23

klientów aplikacji lub innych usług stron trzecich. Tabela 3.1 przedstawia produkty i funkcje chmury AWS używane w zapleczu chmury, a więcej produktów i funkcji jest w fazie opracowywania.
Tabela 3.1. Produkty i funkcje chmurowe AWS wykorzystywane przez backend chmury

Produkt chmurowy AWS używany przez RainMaker

Funkcjonować

AWS Cognito

Zarządzanie poświadczeniami użytkowników i obsługa logowania stron trzecich

AWS-Lambda

Implementacja podstawowej logiki biznesowej backendu w chmurze

Amazon Timestream Przechowywanie danych szeregów czasowych

Amazon DynamoDB Przechowywanie prywatnych informacji klientów

Rdzeń AWS IoT

Obsługa komunikacji MQTT

Amazon SES

Świadczenie usług wysyłania wiadomości e-mail

Amazon CloudFront Przyspieszenie zarządzania backendem webdostęp do serwisu

Amazon SQS

Przekazywanie wiadomości z AWS IoT Core

3.2.4 Klient RainMakera
Klienci RainMaker, tacy jak App i CLI, komunikują się z backendem chmury za pośrednictwem interfejsów API REST. Szczegółowe informacje i instrukcje dotyczące API REST można znaleźć w dokumentacji Swaggera udostępnionej przez Espressif. Klient aplikacji mobilnej RainMaker jest dostępny zarówno dla systemów iOS, jak i Android. Umożliwia udostępnianie, kontrolę i udostępnianie urządzeń, a także tworzenie i umożliwianie zadań odliczania oraz łączenie się z platformami innych firm. Może automatycznie ładować interfejs użytkownika i ikony zgodnie z konfiguracją zgłaszaną przez urządzenia oraz w pełni wyświetlać TSL urządzenia.
Na przykładample, jeśli inteligentne światło jest zbudowane na dostarczonym przez RainMaker SDK npampplików ikona i interfejs użytkownika żarówki zostaną załadowane automatycznie po zakończeniu udostępniania. Użytkownicy mogą zmieniać kolor i jasność światła za pośrednictwem interfejsu i uzyskać kontrolę strony trzeciej, łącząc Alexa Smart Home Skill lub Google Smart Home Actions ze swoimi kontami ESP RainMaker. Rysunek 3.4 przedstawia ikonę i interfejs użytkownika, npamppliki żarówek odpowiednio w aplikacji Alexa, Google Home i ESP RainMaker.

24 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

(a) Npample – Aleksa

(b) Przykładample – Strona główna Google

(c) Przykładample – ESP RainMaker
Rysunek 3.4. Examppliki ikon i interfejs użytkownika żarówki w aplikacji Alexa, Google Home i ESP RainMaker
3.3 Praktyka: Kluczowe punkty rozwoju z ESP RainMaker
Po ukończeniu warstwy sterownika urządzenia programiści mogą rozpocząć tworzenie modeli TSL i przetwarzać dane łącza w dół przy użyciu interfejsów API dostarczonych przez RainMaker SDK, a także włączyć podstawowe usługi ESP RainMaker w oparciu o definicję produktu i wymagania.
Rozdział 3. Wprowadzenie do ESP RainMaker 25

W sekcji 9.4 tej książki wyjaśniono implementację inteligentnego światła LED w RainMakerze. Podczas debugowania programiści mogą używać narzędzi CLI w pakiecie RainMaker SDK do komunikacji z inteligentnym światłem (lub wywoływać interfejsy API REST ze Swaggera).
W rozdziale 10 omówione zostanie wykorzystanie interfejsów API REST w tworzeniu aplikacji na smartfony. Uaktualnienia OTA inteligentnych świateł LED zostaną omówione w rozdziale 11. Jeśli programiści włączyli zdalne monitorowanie ESP Insights, backend zarządzający ESP RainMaker wyświetli dane ESP Insights. Szczegóły zostaną zaprezentowane w Rozdziale 15.
ESP RainMaker obsługuje wdrażanie prywatne, które różni się od publicznego serwera RainMaker pod następującymi względami:
Usługa zgłaszania roszczeń Aby generować certyfikaty w przypadku wdrożeń prywatnych, zamiast funkcji zgłaszania wymagane jest użycie interfejsu wiersza polecenia RainMaker Admin. W przypadku serwerów publicznych programiści muszą otrzymać uprawnienia administratora, aby móc przeprowadzić aktualizację oprogramowania sprzętowego, ale jest to niepożądane w przypadku wdrożeń komercyjnych. W związku z tym nie można zapewnić oddzielnej usługi uwierzytelniania w przypadku roszczeń własnych, ani praw administratora w przypadku roszczeń kierowanych przez hosta lub wspomaganych.
Aplikacje na telefon W przypadku wdrożeń prywatnych aplikacje należy konfigurować i kompilować osobno, aby zapewnić brak interoperacyjności systemów kont.
Logowania innych firm i integracja głosowa Programiści muszą oddzielnie skonfigurować konta Google i Apple Developer, aby umożliwić logowanie innych firm, a także integrację Alexa Skill i Google Voice Assistant.
WSKAZÓWKI Szczegółowe informacje na temat wdrażania chmury można znaleźć na stronie https://customer.rainmaker.espressif. kom. Jeśli chodzi o oprogramowanie sprzętowe, migracja z serwera publicznego na serwer prywatny wymaga jedynie wymiany certyfikatów urządzeń, co znacznie poprawia efektywność migracji i zmniejsza koszty migracji i wtórnego debugowania.
3.4 Funkcje ESP RainMaker
Funkcje ESP RainMaker skupiają się głównie na trzech aspektach – zarządzaniu użytkownikami, użytkownikach końcowych i administratorach. Wszystkie funkcje są obsługiwane zarówno na serwerach publicznych, jak i prywatnych, chyba że zaznaczono inaczej.
3.4.1 Zarządzanie użytkownikami
Funkcje zarządzania użytkownikami umożliwiają użytkownikom końcowym rejestrację, logowanie, zmianę haseł, odzyskiwanie haseł itp.
26 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Zarejestruj się i zaloguj Metody rejestracji i logowania obsługiwane przez RainMaker obejmują: · Identyfikator e-mail + hasło · Numer telefonu + hasło · Konto Google · Konto Apple · Konto GitHub (tylko serwer publiczny) · Konto Amazon (tylko serwer prywatny)
UWAGA Zarejestruj się za pomocą Google/Amazon udostępnia RainMakerowi adres e-mail użytkownika. Zarejestruj się za pomocą Apple, udostępniając fałszywy adres, który Apple przypisuje użytkownikowi specjalnie na potrzeby usługi RainMaker. Konto RainMaker zostanie utworzone automatycznie dla użytkowników logujących się po raz pierwszy za pomocą konta Google, Apple lub Amazon.
Zmień hasło Dotyczy tylko logowania na podstawie identyfikatora e-mail/numeru telefonu. Wszystkie inne aktywne sesje zostaną wylogowane po zmianie hasła. Zgodnie z zachowaniem AWS Cognito, wylogowane sesje mogą pozostać aktywne do 1 godziny.
Odzyskaj hasło Ważne tylko w przypadku logowania na podstawie identyfikatora e-mail/numeru telefonu.
3.4.2 Funkcje użytkownika końcowego
Funkcje dostępne dla użytkowników końcowych obejmują lokalne i zdalne sterowanie oraz monitorowanie, planowanie, grupowanie urządzeń, udostępnianie urządzeń, powiadomienia push i integracje z firmami zewnętrznymi.
Zdalne sterowanie i monitorowanie · Zapytanie o konfigurację, wartości parametrów i stan połączenia dla jednego lub wszystkich urządzeń. · Ustaw parametry dla jednego lub wielu urządzeń.
Lokalne sterowanie i monitorowanie Telefon komórkowy i urządzenie muszą być podłączone do tej samej sieci, aby można było sterować lokalnie.
Planowanie · Użytkownicy wstępnie ustalają określone działania w określonym czasie. · Podczas wykonywania harmonogramu urządzenie nie wymaga połączenia z Internetem. · Jednorazowy lub powtórzony (poprzez określenie dni) dla jednego lub wielu urządzeń.
Grupowanie urządzeń Obsługuje wielopoziomowe grupowanie abstrakcyjne Metadane grupowe mogą zostać użyte do stworzenia struktury Home Room.
Rozdział 3. Wprowadzenie do ESP RainMaker 27

Udostępnianie urządzenia Jedno lub więcej urządzeń można udostępnić jednemu lub większej liczbie użytkowników.
Powiadomienia push Użytkownicy końcowi będą otrzymywać powiadomienia push o następujących zdarzeniach: · Dodano/usunięto nowe urządzenia · Urządzenie podłączone do chmury · Urządzenie zostało odłączone od chmury · Utworzono/zaakceptowano/odrzucono żądania udostępnienia urządzenia · Komunikaty alarmowe zgłaszane przez urządzenia
Obsługiwane są integracje innych firm Alexa i Google Voice Assistant w celu sterowania urządzeniami RainMaker, w tym oświetleniem, przełącznikami, gniazdkami, wentylatorami i czujnikami temperatury.
3.4.3 Funkcje administracyjne
Funkcje administracyjne umożliwiają administratorom wdrażanie rejestracji urządzeń, grupowania urządzeń i aktualizacji OTA, a także view statystyki i dane ESP Insights.
Rejestracja urządzenia Wygeneruj certyfikaty urządzenia i zarejestruj się w Admin CLI (tylko serwer prywatny).
Grupowanie urządzeń Twórz grupy abstrakcyjne lub strukturalne w oparciu o informacje o urządzeniach (tylko serwer prywatny).
Aktualizacje OTA (Over-the-Air) Przesyłaj oprogramowanie sprzętowe w oparciu o wersję i model do jednego lub większej liczby urządzeń lub grupy. Monitoruj, anuluj lub archiwizuj zadania OTA.
View statystyka Viewmożliwe statystyki obejmują: · Rejestracje urządzeń (certyfikaty zarejestrowane przez administratora) · Aktywacje urządzeń (urządzenie podłączone po raz pierwszy) · Konta użytkowników · Powiązanie użytkownika z urządzeniem
View Dane ESP Insights ViewDostępne dane ESP Insights obejmują: · Błędy, ostrzeżenia i dzienniki niestandardowe · Raporty i analizy awarii · Przyczyny ponownego uruchomienia · Metryki, takie jak użycie pamięci, RSSI itp. · Niestandardowe metryki i zmienne
28 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

3.5 Podsumowanie
W tym rozdziale przedstawiliśmy kilka kluczowych różnic pomiędzy publicznym wdrożeniem RainMakera a wdrożeniem prywatnym. Prywatne rozwiązanie ESP RainMaker wprowadzone przez Espressif jest wysoce niezawodne i rozszerzalne. Wszystkie chipy serii ESP32 zostały podłączone i dostosowane do AWS, co znacznie obniża koszty. Programiści mogą skupić się na weryfikacji prototypu bez konieczności poznawania produktów chmurowych AWS. Wyjaśniliśmy także implementację i funkcje ESP RainMaker oraz kilka kluczowych punktów rozwoju przy użyciu platformy.
Zeskanuj, aby pobrać ESP RainMaker na Androida. Skanuj, aby pobrać ESP RainMaker na iOS
Rozdział 3. Wprowadzenie do ESP RainMaker 29

30 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Rozdział Konfiguracja 4 Środowisko programistyczne
W tym rozdziale skupiono się na ESP-IDF, oficjalnym frameworku programistycznym dla ESP32-C3. Wyjaśnimy, jak skonfigurować środowisko na różnych systemach operacyjnych, przedstawimy strukturę projektu i system kompilacji ESP-IDF, a także wykorzystanie powiązanych narzędzi programistycznych. Następnie przedstawimy proces kompilacji i uruchamiania example, oferując jednocześnie szczegółowe wyjaśnienie dziennika wyjściowego w każdym stage.
4.1 Koniec ESP-IDFview
ESP-IDF (Espressif IoT Development Framework) to kompleksowa platforma rozwoju IoT dostarczana przez firmę Espressif Technology. Używa C/C++ jako głównego języka programistycznego i obsługuje kompilację krzyżową w głównych systemach operacyjnych, takich jak Linux, Mac i Windows. ByłyampProgramy zawarte w tej książce są tworzone przy użyciu protokołu ESP-IDF, który oferuje następujące funkcje: · Sterowniki na poziomie systemu SoC. ESP-IDF zawiera sterowniki dla ESP32, ESP32-S2, ESP32-C3,
i inne chipsy. Sterowniki te obejmują bibliotekę niskiego poziomu (LL) urządzeń peryferyjnych, bibliotekę warstwy abstrakcji sprzętu (HAL), obsługę RTOS i oprogramowanie sterowników wyższej warstwy itp. · Niezbędne komponenty. ESP-IDF zawiera podstawowe komponenty wymagane do rozwoju IoT. Obejmuje to wiele stosów protokołów sieciowych, takich jak HTTP i MQTT, strukturę zarządzania energią z dynamiczną modulacją częstotliwości oraz funkcje takie jak szyfrowanie Flash i bezpieczny rozruch itp. · Narzędzia rozwojowe i produkcyjne. ESP-IDF zapewnia powszechnie używane narzędzia do budowania, flashowania i debugowania podczas programowania i masowej produkcji (patrz rysunek 4.1), takie jak system budowania oparty na CMake, łańcuch narzędzi do kompilacji krzyżowej oparty na GCC i JTAG narzędzie do debugowania oparte na OpenOCD itp. Warto zauważyć, że kod ESP-IDF jest przede wszystkim zgodny z licencją open source Apache 2.0. Użytkownicy mogą bez ograniczeń tworzyć oprogramowanie osobiste lub komercyjne, przestrzegając warunków licencji open source. Dodatkowo użytkownicy otrzymują bezpłatnie stałe licencje patentowe, bez obowiązku udostępniania kodu źródłowego jakichkolwiek modyfikacji dokonanych w kodzie źródłowym.
31

Rysunek 4.1.

Budowanie, flashowanie i debugowanie

narzędzia do rozwoju i produkcji masowej

4.1.1 Wersje ESP-IDF
Kod ESP-IDF jest hostowany w serwisie GitHub jako projekt typu open source. Obecnie dostępne są trzy główne wersje: v3, v4 i v5. Każda główna wersja zwykle zawiera różne subwersje, takie jak v4.2, v4.3 i tak dalej. Espressif Systems zapewnia 30-miesięczne wsparcie w zakresie poprawek błędów i poprawek bezpieczeństwa dla każdej wydanej wersji podrzędnej. Dlatego też regularnie publikowane są także wersje Subversion, takie jak v4.3.1, v4.2.2 itd. Tabela 4.1 przedstawia stan obsługi różnych wersji ESP-IDF dla chipów Espressif, wskazując, czy są one w fazie wstępnej.view stage (oferuje wsparcie dla preview wersje, którym może brakować pewnych funkcji lub dokumentacji) lub są oficjalnie obsługiwane.

Tabela 4.1. Status obsługi różnych wersji ESP-IDF dla chipów Espressif

Seria ESP32 ESP32-S2 ESP32-C3 ESP32-S3 ESP32-C2 ESP32-H2

Obsługiwana wersja 4.1

obsługiwana wersja 4.2 obsługiwana

v4.3 obsługiwane obsługiwane obsługiwane

v4.4 obsługiwane obsługiwane obsługiwane obsługiwane
przedview

v5.0 obsługiwany obsługiwany obsługiwany obsługiwany obsługiwany przedview

32 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Iteracja głównych wersji często wiąże się z dostosowaniem struktury frameworka i aktualizacjami systemu kompilacji. Na przykładample, główną zmianą z wersji 3.* do wersji 4.* była stopniowa migracja systemu kompilacji z Make do CMake. Z drugiej strony iteracja mniejszych wersji zazwyczaj wiąże się z dodaniem nowych funkcji lub obsługą nowych chipów.
Ważne jest, aby rozróżnić i zrozumieć związek pomiędzy wersjami stabilnymi a gałęziami GitHub. Wersje oznaczone jako v*.* lub v*.*.* reprezentują wersje stabilne, które przeszły pełne testy wewnętrzne przeprowadzone przez firmę Espressif. Po naprawieniu kod, łańcuch narzędzi i dokumenty wersji dla tej samej wersji pozostają niezmienione. Jednakże gałęzie GitHuba (np. gałąź wydania/v4.3) podlegają częstym zatwierdzaniom kodu, często codziennie. Dlatego dwa fragmenty kodu w tej samej gałęzi mogą się różnić, co wymaga od programistów niezwłocznej odpowiedniej aktualizacji kodu.
4.1.2 Przepływ pracy w Git ESP-IDF
Espressif stosuje się do specyficznego przepływu pracy Git dla ESP-IDF, opisanego w następujący sposób:
· Nowe zmiany wprowadzane są w gałęzi głównej, która służy jako główna gałąź rozwojowa. Wersja ESP-IDF w gałęzi master zawsze zawiera opcję -dev tag aby wskazać, że jest obecnie w fazie rozwoju, np. v4.3-dev. Najpierw zostaną wprowadzone zmiany w gałęzi masterviewwyedytowany i przetestowany w wewnętrznym repozytorium Espressif, a następnie przesłany do GitHub po zakończeniu automatycznych testów.
· Gdy nowa wersja zakończy rozwój funkcji w gałęzi głównej i spełni kryteria wejścia do testów beta, przechodzi do nowej gałęzi, takiej jak wydanie/v4.3. Ponadto ten nowy oddział jest tagged jako wersja przedpremierowa, np. v4.3-beta1. Programiści mogą skorzystać z platformy GitHub, aby uzyskać dostęp do pełnej listy oddziałów i tags dla ESP-IDF. Należy pamiętać, że wersja beta (wersja przedpremierowa) może nadal zawierać znaczną liczbę znanych problemów. Ponieważ wersja beta przechodzi ciągłe testy, poprawki błędów są dodawane jednocześnie do tej wersji i gałęzi głównej. W międzyczasie gałąź master mogła już rozpocząć opracowywanie nowych funkcji dla następnej wersji. Kiedy testowanie jest prawie ukończone, do gałęzi dodawana jest etykieta Release Candidate (rc), wskazująca, że ​​jest to potencjalny kandydat do oficjalnego wydania, np. v4.3-rc1. W tym stage, gałąź pozostaje wersją przedpremierową.
· Jeśli nie zostaną odkryte ani zgłoszone żadne poważne błędy, wersja przedpremierowa ostatecznie otrzymuje etykietę wersji głównej (np. v5.0) lub etykietę wersji pomocniczej (np. v4.3) i staje się oficjalną wersją wydaną, co jest udokumentowane na stronie informacji o wydaniu. Następnie wszelkie błędy zidentyfikowane w tej wersji zostaną naprawione w gałęzi wydania. Po zakończeniu testów ręcznych do gałęzi zostaje przypisana etykieta wersji zawierającej poprawki błędów (np. v4.3.2), co jest również widoczne na stronie informacji o wydaniu.
Rozdział 4. Konfigurowanie środowiska programistycznego 33

4.1.3 Wybór odpowiedniej wersji
Ponieważ ESP-IDF oficjalnie rozpoczął obsługę ESP32-C3 od wersji v4.3, a wersja v4.4 nie została jeszcze oficjalnie opublikowana w momencie pisania tej książki, wersją używaną w tej książce jest v4.3.2, która jest wersją poprawioną z wersji 4.3. Należy jednak pamiętać, że w momencie czytania tej książki wersja 4.4 lub nowsza może być już dostępna. Przy wyborze wersji polecamy:
· Dla początkujących programistów zaleca się wybranie stabilnej wersji v4.3 lub jej poprawionej wersji, która jest zgodna z poprzedniąampwersja używana w tej książce.
· W przypadku produkcji masowej zaleca się korzystanie z najnowszej stabilnej wersji, aby móc korzystać z najaktualniejszego wsparcia technicznego.
· Jeśli zamierzasz eksperymentować z nowymi chipami lub odkrywać nowe funkcje produktu, skorzystaj z gałęzi master. Najnowsza wersja zawiera wszystkie najnowsze funkcje, ale należy pamiętać, że mogą występować znane lub nieznane błędy.
· Jeśli używana wersja stabilna nie zawiera pożądanych nowych funkcji i chcesz zminimalizować ryzyko związane z gałęzią główną, rozważ użycie odpowiedniej gałęzi wydania, takiej jak gałąź release/v4.4. Repozytorium GitHub firmy Espressif utworzy najpierw gałąź release/v4.4, a następnie wypuści stabilną wersję v4.4 w oparciu o konkretną migawkę historyczną tej gałęzi, po zakończeniu tworzenia i testowania wszystkich funkcji.
4.1.4 Ponadview katalogu SDK ESP-IDF
Zestaw SDK ESP-IDF składa się z dwóch głównych katalogów: esp-idf i .espressif. Pierwsza zawiera kod źródłowy repozytorium ESP-IDF files i skrypty kompilacji, podczas gdy ta ostatnia przechowuje głównie łańcuchy narzędzi kompilacji i inne oprogramowanie. Znajomość tych dwóch katalogów pomoże programistom lepiej wykorzystać dostępne zasoby i przyspieszyć proces programowania. Struktura katalogów ESP-IDF jest opisana poniżej:
(1) Katalog kodu repozytorium ESP-IDF (/esp/esp-idf), jak pokazano na rysunku 4.2.
A. Składniki katalogu komponentów
Ten katalog główny integruje wiele istotnych komponentów oprogramowania ESP-IDF. Żaden kod projektu nie może zostać skompilowany bez polegania na komponentach znajdujących się w tym katalogu. Zawiera obsługę sterowników dla różnych układów Espressif. Od bibliotek LL i interfejsów bibliotecznych HAL dla urządzeń peryferyjnych po interfejsy wyższego poziomu Driver i Virtual File Obsługa warstwy systemowej (VFS), programiści mogą wybierać odpowiednie komponenty na różnych poziomach dla swoich potrzeb programistycznych. ESP-IDF obsługuje także wiele standardowych stosów protokołów sieciowych, takich jak TCP/IP, HTTP, MQTT, WebSocket itp. Programiści mogą wykorzystywać znane interfejsy, takie jak Socket, do tworzenia aplikacji sieciowych. Komponenty zapewniają zrozumienie
34 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Rysunek 4.2. Katalog kodów repozytorium ESP-IDF
dużą funkcjonalność i można go łatwo zintegrować z aplikacjami, umożliwiając programistom skupienie się wyłącznie na logice biznesowej. Niektóre typowe komponenty obejmują: · Sterownik: Ten komponent zawiera programy sterowników urządzeń peryferyjnych dla różnych Espressif
serie chipów, takie jak GPIO, I2C, SPI, UART, LEDC (PWM) itp. Programy sterowników peryferyjnych w tym komponencie oferują abstrakcyjne interfejsy niezależne od chipa. Każde urządzenie peryferyjne ma wspólne gniazdo file (takich jak gpio.h), eliminując potrzebę zajmowania się różnymi pytaniami dotyczącymi wsparcia specyficznego dla chipa. · esp_wifi: Wi-Fi, jako specjalne urządzenie peryferyjne, jest traktowane jako oddzielny element. Zawiera wiele interfejsów API, takich jak inicjowanie różnych trybów sterownika Wi-Fi, konfiguracja parametrów i przetwarzanie zdarzeń. Niektóre funkcje tego komponentu są dostarczane w formie statycznych bibliotek linkowanych. ESP-IDF zapewnia również obszerną dokumentację sterowników ułatwiającą obsługę.
Rozdział 4. Konfigurowanie środowiska programistycznego 35

· freertos: Ten komponent zawiera pełny kod FreeRTOS. Oprócz zapewnienia kompleksowego wsparcia dla tego systemu operacyjnego, Espressif rozszerzył także swoje wsparcie na układy dwurdzeniowe. W przypadku układów dwurdzeniowych, takich jak ESP32 i ESP32-S3, użytkownicy mogą tworzyć zadania na określonych rdzeniach.
B. Dokumenty katalogu dokumentów
Ten katalog zawiera dokumenty programistyczne związane z ESP-IDF, w tym Przewodnik wprowadzający, Podręcznik referencyjny API, Przewodnik programistyczny itp.
UWAGA Po skompilowaniu za pomocą zautomatyzowanych narzędzi zawartość tego katalogu jest wdrażana pod adresem https://docs.espressif.com/projects/esp-idf. Upewnij się, że przełączyłeś docelowy dokument na ESP32-C3 i wybrałeś określoną wersję ESP-IDF.
C. Narzędzia narzędzi skryptowych
Ten katalog zawiera powszechnie używane narzędzia do kompilacji, takie jak idf.py oraz narzędzie terminala monitorującego idf_monitor.py itp. Podkatalog cmake zawiera także podstawowy skrypt files systemu kompilacji, służącego jako podstawa do wdrażania reguł kompilacji ESP-IDF. Podczas dodawania zmiennych środowiskowych zawartość katalogu narzędzi jest dodawana do systemowej zmiennej środowiskowej, umożliwiając wykonanie idf.py bezpośrednio pod ścieżką projektu.
D. Byłyample katalog programu npamples
Katalog ten zawiera obszerną kolekcję ESP-IDF examppliki demonstrujące użycie komponentów API. Byłyamppliki są podzielone na różne podkatalogi w oparciu o ich kategorie:
· get-started: Ten podkatalog zawiera podstawowe narzędzia, npamptakie jak „witaj, świecie” i „mrugnij”, aby pomóc użytkownikom zrozumieć podstawy.
· bluetooth: Możesz znaleźć powiązane z Bluetooth npamppliki tutaj, w tym Bluetooth LE Mesh, Bluetooth LE HID, BluFi i inne.
· wifi: Ten podkatalog skupia się na Wi-Fi npamppliki, w tym podstawowe programy takie jak Wi-Fi SoftAP, Wi-Fi Station, espnow, a także autorski protokół komunikacyjny examples z Espressif. Zawiera także wiele warstw aplikacji, npamppliki oparte na Wi-Fi, takie jak Iperf, Sniffer i Smart Config.
· urządzenia peryferyjne: Ten obszerny podkatalog jest dalej podzielony na liczne podfoldery w oparciu o nazwy urządzeń peryferyjnych. Zawiera głównie sterownik urządzeń peryferyjnych, npamples dla chipsów Espressif, z każdym example z kilkoma pod-examples. Na przykład podkatalog gpio zawiera dwa examppliki: Klawiatura matrycowa GPIO i GPIO. Należy pamiętać, że nie wszyscy exampPliki w tym katalogu mają zastosowanie do ESP32-C3.
36 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Na przykładample, byłyampPliki w usb/host mają zastosowanie tylko do urządzeń peryferyjnych ze sprzętem hosta USB (takich jak ESP32-S3), a ESP32-C3 nie ma tego urządzenia peryferyjnego. System kompilacji zazwyczaj wyświetla monity podczas ustawiania celu. Plik README file każdego byłegoampplik zawiera listę obsługiwanych układów. · protokoły: Ten podkatalog zawiera npamppliki dla różnych protokołów komunikacyjnych, w tym MQTT, HTTP, HTTP Server, PPPoS, Modbus, mDNS, SNTP, obejmujące szeroki zakres protokołów komunikacyjnych np.amppliki wymagane do rozwoju IoT. · zaopatrzenie: Tutaj znajdziesz zaopatrzenie npamppliki dla różnych metod, takich jak udostępnianie Wi-Fi i udostępnianie Bluetooth LE. · system: Ten podkatalog zawiera debugowanie systemu, npamppliki (np. śledzenie stosu, śledzenie czasu wykonywania, monitorowanie zadań), zarządzanie energią npamppliki (np. różne tryby uśpienia, koprocesory) i npamppliki związane z typowymi komponentami systemu, takimi jak terminal konsoli, pętla zdarzeń i zegar systemowy. · przechowywanie: W tym podkatalogu znajdziesz npampprzede wszystkim file systemy i mechanizmy przechowywania obsługiwane przez ESP-IDF (takie jak odczyt i zapis Flash, kart SD i innych nośników pamięci), a także examppliki pamięci nieulotnej (NVS), FatFS, SPIFFS i inne file operacji systemowych. · bezpieczeństwo: Ten podkatalog zawiera npamppliki związane z szyfrowaniem flash. (2) Katalog łańcucha narzędzia kompilacji ESP-IDF (/.espressif), jak pokazano na rysunku 4.3.
Rysunek 4.3. Katalog łańcucha narzędzi kompilacji ESP-IDF
Rozdział 4. Konfigurowanie środowiska programistycznego 37

A. Katalog dystrybucji oprogramowania dist
Łańcuch narzędzi ESP-IDF i inne oprogramowanie są dystrybuowane w postaci skompresowanych pakietów. Podczas procesu instalacji narzędzie instalacyjne najpierw pobiera skompresowany pakiet do katalogu dist, a następnie rozpakowuje go do określonego katalogu. Po zakończeniu instalacji zawartość tego katalogu można bezpiecznie usunąć.
B. Katalog środowiska wirtualnego Python python env
Różne wersje ESP-IDF opierają się na określonych wersjach pakietów Pythona. Instalowanie tych pakietów bezpośrednio na tym samym hoście może prowadzić do konfliktów między wersjami pakietów. Aby rozwiązać ten problem, ESP-IDF wykorzystuje wirtualne środowiska Pythona do izolowania różnych wersji pakietów. Dzięki temu mechanizmowi programiści mogą instalować wiele wersji ESP-IDF na tym samym hoście i łatwo przełączać się między nimi, importując różne zmienne środowiskowe.
C. Narzędzia katalogowe łańcucha narzędzi do kompilacji ESP-IDF
Katalog ten zawiera głównie narzędzia do kompilacji krzyżowej wymagane do kompilacji projektów ESP-IDF, takie jak narzędzia CMake, narzędzia do kompilacji Ninja i łańcuch narzędzi gcc, który generuje końcowy program wykonywalny. Dodatkowo w tym katalogu znajduje się standardowa biblioteka języka C/C++ wraz z odpowiednim nagłówkiem fileS. Jeśli program odwołuje się do nagłówka systemowego file jak #include , łańcuch narzędzi kompilacji zlokalizuje plik stdio.h file w tym katalogu.
4.2 Konfigurowanie środowiska programistycznego ESP-IDF
Środowisko programistyczne ESP-IDF obsługuje główne systemy operacyjne, takie jak Windows, Linux i macOS. W tej sekcji opisano, jak skonfigurować środowisko programistyczne w każdym systemie. Zalecane jest rozwijanie ESP32-C3 na systemie Linux, co zostanie szczegółowo omówione w tym miejscu. Wiele instrukcji ma zastosowanie na różnych platformach ze względu na podobieństwo narzędzi programistycznych. Dlatego też zaleca się uważne zapoznanie się z treścią tego rozdziału.
UWAGA Możesz skorzystać z dokumentów online dostępnych pod adresem https://bookc3.espressif.com/esp32c3, które zawierają polecenia wymienione w tej sekcji.
4.2.1 Konfigurowanie środowiska programistycznego ESP-IDF w systemie Linux
Narzędzia programistyczne i debugujące GNU wymagane w środowisku programistycznym ESP-IDF pochodzą z systemu Linux. Ponadto terminal wiersza poleceń w systemie Linux jest wydajny i przyjazny dla użytkownika, co czyni go idealnym wyborem do programowania ESP32-C3. Możesz
38 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

wybierz preferowaną dystrybucję Linuksa, ale zalecamy używanie Ubuntu lub innych systemów opartych na Debianie. Ta sekcja zawiera wskazówki dotyczące konfigurowania środowiska programistycznego ESP-IDF w systemie Ubuntu 20.04.
1. Zainstaluj wymagane pakiety
Otwórz nowy terminal i wykonaj następujące polecenie, aby zainstalować wszystkie niezbędne pakiety. Polecenie automatycznie pominie pakiety, które są już zainstalowane.
$ 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
WSKAZÓWKI Aby wykonać powyższe polecenie, musisz użyć konta administratora i hasła. Domyślnie przy wpisywaniu hasła nie będą wyświetlane żadne informacje. Aby kontynuować procedurę, wystarczy nacisnąć klawisz „Enter”.
Git to kluczowe narzędzie do zarządzania kodem w ESP-IDF. Po pomyślnym skonfigurowaniu środowiska programistycznego możesz użyć polecenia git log, aby view wszystkie zmiany w kodzie wprowadzone od czasu utworzenia ESP-IDF. Ponadto Git jest również używany w ESP-IDF do potwierdzania informacji o wersji, które są niezbędne do zainstalowania prawidłowego łańcucha narzędzi odpowiadającego konkretnym wersjom. Oprócz Gita do innych ważnych narzędzi systemowych zalicza się Python. ESP-IDF zawiera wiele skryptów automatyzacji napisanych w języku Python. Narzędzia takie jak CMake, Ninja-build i Ccache są szeroko stosowane w projektach C/C++ i służą jako domyślne narzędzia do kompilacji i budowania kodu w ESP-IDF. libusb-1.0-0 i dfu-util to główne sterowniki używane do komunikacji szeregowej USB i nagrywania oprogramowania sprzętowego. Po zainstalowaniu pakietów oprogramowania możesz używać apt show polecenie, aby uzyskać szczegółowe opisy każdego pakietu. Na przykładample, użyj apt show git, aby wydrukować informacje opisowe narzędzia Git.
P: Co zrobić, jeśli wersja Pythona nie jest obsługiwana? Odp.: ESP-IDF v4.3 wymaga wersji Pythona nie starszej niż v3.6. W przypadku starszych wersji Ubuntu należy ręcznie pobrać i zainstalować wyższą wersję Pythona i ustawić Python3 jako domyślne środowisko Python. Szczegółowe instrukcje można znaleźć, wyszukując słowo kluczowe update-alternatives python.
2. Pobierz kod repozytorium ESP-IDF
Otwórz terminal i utwórz folder o nazwie esp w swoim katalogu domowym za pomocą polecenia mkdir. Jeśli wolisz, możesz wybrać inną nazwę folderu. Użyj polecenia cd, aby wejść do folderu.
Rozdział 4. Konfigurowanie środowiska programistycznego 39

$ mkdir -p /esp $ cd /esp
Użyj polecenia git clone, aby pobrać kod repozytorium ESP-IDF, jak pokazano poniżej:
$ git clone -b v4.3.2 –rekurencyjny https://github.com/espressif/esp-idf.git
W powyższym poleceniu parametr -b v4.3.2 określa wersję do pobrania (w tym przypadku wersję 4.3.2). Parametr –recursive zapewnia, że ​​wszystkie podrepozytoria ESP-IDF będą pobierane rekurencyjnie. Informacje o podrepozytoriach można znaleźć w pliku .gitmodules file.
3. Zainstaluj łańcuch narzędzi programistycznych ESP-IDF
Espressif udostępnia zautomatyzowany skrypt install.sh umożliwiający pobranie i zainstalowanie łańcucha narzędzi. Ten skrypt sprawdza aktualną wersję ESP-IDF i środowisko systemu operacyjnego, a następnie pobiera i instaluje odpowiednią wersję pakietów narzędzi Pythona i łańcuchów narzędzi kompilacji. Domyślna ścieżka instalacji łańcucha narzędzi to /.espressif. Wszystko, co musisz zrobić, to przejść do katalogu esp-idf i uruchomić install.sh.
$ cd /esp/esp-idf $ ./install.sh
Jeśli pomyślnie zainstalujesz łańcuch narzędzi, na terminalu wyświetli się:
Wszystko gotowe!
W tym momencie pomyślnie skonfigurowałeś środowisko programistyczne ESP-IDF.
4.2.2 Konfigurowanie środowiska programistycznego ESP-IDF w systemie Windows
1. Pobierz instalator narzędzi ESP-IDF
WSKAZÓWKI Zalecane jest skonfigurowanie środowiska programistycznego ESP-IDF na systemie Windows 10 lub nowszym. Instalator można pobrać ze strony https://dl.espressif.com/dl/esp-idf/. Instalator jest również oprogramowaniem typu open source i jego kod źródłowy może taki być viewpod adresem https: //github.com/espressif/idf-installer.
· Instalator narzędzi online ESP-IDF
Ten instalator jest stosunkowo mały, ma około 4 MB, a inne pakiety i kod zostaną pobrane podczas procesu instalacji. AdwantagCechą instalatora online jest to, że nie tylko można pobrać pakiety oprogramowania i kod na żądanie podczas procesu instalacji, ale także umożliwia instalację wszystkich dostępnych wydań ESP-IDF i najnowszej gałęzi kodu GitHub (takiej jak gałąź główna) . Wadatage jest to, że podczas procesu instalacji wymagane jest połączenie sieciowe, co może spowodować niepowodzenie instalacji z powodu problemów z siecią.
40 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

· Instalator narzędzi ESP-IDF offline. Ten instalator jest większy, ma rozmiar około 1 GB i zawiera wszystkie pakiety oprogramowania i kod wymagany do skonfigurowania środowiska. Główna zaletatagZaletą instalatora offline jest to, że można go używać na komputerach bez dostępu do Internetu i ogólnie ma wyższy wskaźnik powodzenia instalacji. Należy zauważyć, że instalator offline może instalować tylko stabilne wersje ESP-IDF oznaczone v*.* lub v*.*.*.
2. Uruchom instalator narzędzi ESP-IDF Po pobraniu odpowiedniej wersji instalatora (np. ESP-IDF Tools Offline 4.3.2ample tutaj), kliknij dwukrotnie plik exe file aby uruchomić interfejs instalacyjny ESP-IDF. Poniżej pokazano, jak zainstalować stabilną wersję ESP-IDF v4.3.2 przy użyciu instalatora offline.
(1) W interfejsie „Wybierz język instalacji” pokazanym na rysunku 4.4 wybierz z listy rozwijanej język, który ma być używany.
Rysunek 4.4. Interfejs „Wybierz język instalacji” (2) Po wybraniu języka kliknij „OK”, aby wyświetlić interfejs „Umowa licencyjna”
(patrz rysunek 4.5). Po uważnym przeczytaniu umowy licencyjnej instalacji wybierz „Akceptuję umowę” i kliknij „Dalej”.
Rysunek 4.5. Interfejs „Umowa licencyjna” Rozdział 4. Konfigurowanie środowiska programistycznego 41

(3) Odpview konfigurację systemu w interfejsie „Przedinstalacyjna kontrola systemu” (patrz rysunek 4.6). Sprawdź wersję systemu Windows i informacje o zainstalowanym oprogramowaniu antywirusowym. Kliknij „Dalej”, jeśli wszystkie elementy konfiguracji są normalne. W przeciwnym razie możesz kliknąć „Pełny dziennik”, aby uzyskać rozwiązania oparte na kluczowych elementach.
Rysunek 4.6. Interfejs „Sprawdzanie systemu przed instalacją” WSKAZÓWKI
Możesz przesłać dzienniki do https://github.com/espressif/idf-installer/issues, aby uzyskać pomoc. (4) Wybierz katalog instalacyjny ESP-IDF. Tutaj wybierz D:/.espressif, jak pokazano w
Rysunek 4.7 i kliknij „Dalej”. Pamiętaj, że .espressif jest ukrytym katalogiem. Po zakończeniu instalacji możesz view konkretną zawartość tego katalogu, otwierając plik file menedżera i wyświetlanie ukrytych elementów.
Rysunek 4.7. Wybierz katalog instalacyjny ESP-IDF 42 ESP32-C3 Wireless Adventure: kompleksowy przewodnik po IoT

(5) Sprawdź komponenty, które należy zainstalować, jak pokazano na rysunku 4.8. Zalecane jest skorzystanie z opcji domyślnej, czyli dokończenie instalacji, a następnie kliknięcie przycisku „Dalej”.
Rysunek 4.8. Wybierz komponenty do zainstalowania (6) Potwierdź komponenty do zainstalowania i kliknij „Instaluj”, aby rozpocząć automatyczną instalację
proces stacjonowania, jak pokazano na rysunku 4.9. Proces instalacji może trwać kilkadziesiąt minut, a pasek postępu procesu instalacji pokazano na rysunku 4.10. Proszę cierpliwie czekać.
Rysunek 4.9. Przygotowanie do instalacji (7) Po zakończeniu instalacji zaleca się zaznaczenie opcji „Zarejestruj ESP-IDF
Pliki wykonywalne narzędzi jako wyjątki programu Windows Defender…”, aby zapobiec usunięciu oprogramowania antywirusowego fileS. Dodanie elementów wykluczonych może również pominąć częste skanowanie przez program antywirusowy
Rozdział 4. Konfigurowanie środowiska programistycznego 43

Rysunek 4.10. Oprogramowanie paska postępu instalacji, znacznie poprawiające wydajność kompilacji kodu systemu Windows. Kliknij „Zakończ”, aby zakończyć instalację środowiska programistycznego, jak pokazano na rysunku 4.11. Możesz zaznaczyć opcję „Uruchom środowisko ESP-IDF PowerShell” lub „Uruchom wiersz poleceń ESP-IDF”. Uruchom okno kompilacji bezpośrednio po instalacji, aby mieć pewność, że środowisko programistyczne działa normalnie.
Rysunek 4.11. Instalacja zakończona (8) Otwórz zainstalowane środowisko programistyczne na liście programów (ESP-IDF 4.3 lub nowszy).
Terminal CMD lub ESP-IDF 4.3 PowerShell, jak pokazano na rysunku 4.12), a zmienna środowiskowa ESP-IDF zostanie automatycznie dodana podczas uruchamiania w terminalu. Następnie możesz użyć polecenia idf.py do operacji. Otwarty CMD ESP-IDF 4.3 pokazano na rysunku 4.13. 44 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Rysunek 4.12. Zainstalowane środowisko programistyczne
Rysunek 4.13. ESP-IDF 4.3 CMD
4.2.3 Konfigurowanie środowiska programistycznego ESP-IDF na komputerze Mac
Proces instalacji środowiska programistycznego ESP-IDF w systemie Mac jest taki sam, jak w systemie Linux. Polecenia pobierania kodu repozytorium i instalowania łańcucha narzędzi są dokładnie takie same. Tylko polecenia instalowania pakietów zależności są nieco inne. 1. Zainstaluj pakiety zależności Otwórz terminal i zainstaluj pip, narzędzie do zarządzania pakietami w języku Python, uruchamiając następującą komendę:
% Sudo łatwa instalacja pip
Zainstaluj Homebrew, narzędzie do zarządzania pakietami dla systemu macOS, uruchamiając następującą komendę:
% /bin/bash -c „$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
Zainstaluj wymagane pakiety zależności, uruchamiając następującą komendę:
% brew python3 zainstaluj cmake ninja ccache dfu-util
2. Pobierz kod repozytorium ESP-IDF Postępuj zgodnie z instrukcjami podanymi w sekcji 4.2.1, aby pobrać kod repozytorium ESP-IDF. Kroki są takie same, jak w przypadku pobierania w systemie Linux.
Rozdział 4. Konfigurowanie środowiska programistycznego 45

3. Zainstaluj łańcuch narzędzi programistycznych ESP-IDF
Postępuj zgodnie z instrukcjami podanymi w sekcji 4.2.1, aby zainstalować łańcuch narzędzi programistycznych ESP-IDF. Kroki są takie same, jak w przypadku instalacji w systemie Linux.
4.2.4 Instalacja kodu VS
Domyślnie zestaw ESP-IDF SDK nie zawiera narzędzia do edycji kodu (chociaż najnowszy instalator ESP-IDF dla systemu Windows oferuje opcję instalacji ESP-IDF Eclipse). Możesz użyć dowolnego narzędzia do edycji tekstu, aby edytować kod, a następnie skompilować go za pomocą poleceń terminala.
Jednym z popularnych narzędzi do edycji kodu jest VS Code (Visual Studio Code), który jest darmowym i bogatym w funkcje edytorem kodu z przyjaznym dla użytkownika interfejsem. Oferuje różne plugins które zapewniają funkcje takie jak nawigacja po kodzie, podświetlanie składni, kontrola wersji Git i integracja terminali. Dodatkowo Espressif opracował dedykowaną wtyczkę o nazwie Espressif IDF dla VS Code, która upraszcza konfigurację projektu i debugowanie.
Możesz użyć polecenia code w terminalu, aby szybko otworzyć bieżący folder w VS Code. Alternatywnie możesz użyć skrótu Ctrl+, aby otworzyć domyślną konsolę terminala systemu w VS Code.
WSKAZÓWKI Do tworzenia kodu ESP32-C3 zaleca się używanie kodu VS. Pobierz i zainstaluj najnowszą wersję VS Code pod adresem https://code.visualstudio.com/.
4.2.5 Wprowadzenie do środowisk programistycznych stron trzecich
Oprócz oficjalnego środowiska programistycznego ESP-IDF, które wykorzystuje głównie język C, ESP32-C3 obsługuje także inne główne języki programowania i szeroką gamę środowisk programistycznych innych firm. Niektóre godne uwagi opcje obejmują:
Arduino: platforma typu open source zarówno dla sprzętu, jak i oprogramowania, obsługująca różne mikrokontrolery, w tym ESP32-C3.
Wykorzystuje język C++ i oferuje uproszczone i ujednolicone API, potocznie zwane językiem Arduino. Arduino jest szeroko stosowane w rozwoju prototypów i w kontekstach edukacyjnych. Zapewnia rozszerzalny pakiet oprogramowania i IDE, które pozwala na łatwą kompilację i flashowanie.
MicroPython: interpreter języka Python 3 przeznaczony do działania na platformach wbudowanych mikrokontrolerów.
Dzięki prostemu językowi skryptowemu może uzyskać bezpośredni dostęp do zasobów peryferyjnych ESP32-C3 (takich jak UART, SPI i I2C) oraz funkcji komunikacyjnych (takich jak Wi-Fi i Bluetooth LE).
46 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

Upraszcza to interakcję ze sprzętem. MicroPython w połączeniu z rozbudowaną biblioteką operacji matematycznych Pythona umożliwia implementację złożonych algorytmów na ESP32-C3, ułatwiając rozwój aplikacji związanych ze sztuczną inteligencją. Jako język skryptowy nie ma potrzeby powtarzania kompilacji; można wprowadzać modyfikacje i bezpośrednio wykonywać skrypty.
NodeMCU: interpreter języka LUA opracowany dla układów serii ESP.
Obsługuje prawie wszystkie funkcje peryferyjne układów ESP i jest lżejszy niż MicroPython. Podobnie jak MicroPython, NodeMCU wykorzystuje język skryptowy, eliminując potrzebę powtarzania kompilacji.
Ponadto ESP32-C3 obsługuje również systemy operacyjne NuttX i Zephyr. NuttX to system operacyjny czasu rzeczywistego, który zapewnia interfejsy zgodne z POSIX, zwiększając przenośność aplikacji. Zephyr to mały system operacyjny czasu rzeczywistego zaprojektowany specjalnie do zastosowań IoT. Zawiera liczne biblioteki oprogramowania wymagane w rozwoju IoT, stopniowo przekształcając się w kompleksowy ekosystem oprogramowania.
Książka ta nie zawiera szczegółowych instrukcji instalacji dla wyżej wymienionych środowisk programistycznych. Możesz zainstalować środowisko programistyczne w oparciu o swoje wymagania, postępując zgodnie z odpowiednią dokumentacją i instrukcjami.
4.3 System kompilacji ESP-IDF
4.3.1 Podstawowe pojęcia dotyczące systemu kompilacji
Projekt ESP-IDF to zbiór programu głównego z funkcją wprowadzania i wieloma niezależnymi komponentami funkcjonalnymi. Na przykładample, projekt sterujący przełącznikami LED, składa się głównie z głównego programu wejściowego i komponentu sterownika sterującego GPIO. Jeśli chcesz zrealizować zdalne sterowanie LED, musisz także dodać Wi-Fi, stos protokołów TCP/IP itp.
System kompilacji może kompilować, łączyć i generować pliki wykonywalne files (.bin) dla kodu poprzez zestaw reguł budowania. System kompilacji ESP-IDF v4.0 i nowszych wersji jest domyślnie oparty na CMake, a skrypt kompilacji CMakeLists.txt może służyć do kontrolowania zachowania kompilacji kodu. Oprócz obsługi podstawowej składni CMake, system kompilacji ESP-IDF definiuje także zestaw domyślnych reguł kompilacji i funkcji CMake, a także można napisać skrypt kompilacji za pomocą prostych instrukcji.
4.3.2 Projekt File Struktura
Projekt to folder zawierający główny program wejściowy, komponenty zdefiniowane przez użytkownika i filewymagane do budowania aplikacji wykonywalnych, takich jak skrypty kompilacji, konfiguracja
Rozdział 4. Konfigurowanie środowiska programistycznego 47

files, tablice partycji itp. Projekty można kopiować i przekazywać dalej, a także ten sam plik wykonywalny file można skompilować i wygenerować na komputerach z tą samą wersją środowiska programistycznego ESP-IDF. Typowy projekt ESP-IDF file konstrukcję pokazano na rysunku 4.14.
Rysunek 4.14. Typowy projekt ESP-IDF file struktura Ponieważ ESP-IDF obsługuje wiele układów IoT firmy Espressif, w tym ESP32, serie ESP32-S, serie ESP32-C, serie ESP32-H itp., przed skompilowaniem kodu należy określić cel. Celem jest zarówno urządzenie sprzętowe, na którym uruchamiana jest aplikacja, jak i cel kompilacji systemu kompilacji. W zależności od potrzeb możesz określić jeden lub więcej celów dla swojego projektu. Na przykładample, za pomocą polecenia idf.py set-target esp32c3 możesz ustawić cel kompilacji na ESP32-C3, podczas którego zostaną załadowane domyślne parametry i ścieżka łańcucha narzędzia kompilacji dla ESP32C3. Po kompilacji można wygenerować program wykonywalny dla ESP32C3. Możesz także ponownie uruchomić polecenie set-target, aby ustawić inny cel, a system kompilacji automatycznie wyczyści i ponownie skonfiguruje. Komponenty
Komponenty ESP-IDF to modułowe i niezależne jednostki kodu zarządzane w ramach systemu kompilacji. Są one zorganizowane w formie folderów, których nazwa domyślnie reprezentuje nazwę komponentu. Każdy komponent ma swój własny skrypt kompilacji, który 48 ESP32-C3 Wireless Adventure: kompleksowy przewodnik po IoT

określa parametry kompilacji i zależności. Podczas procesu kompilacji komponenty są kompilowane do oddzielnych bibliotek statycznych (.a files) i ostatecznie łączony z innymi komponentami w celu utworzenia programu aplikacyjnego.
ESP-IDF zapewnia podstawowe funkcje, takie jak system operacyjny, sterowniki urządzeń peryferyjnych i stos protokołów sieciowych, w formie komponentów. Komponenty te są przechowywane w katalogu komponentów znajdującym się w katalogu głównym ESP-IDF. Programiści nie muszą kopiować tych komponentów do katalogu komponentów myProject. Zamiast tego muszą jedynie określić relacje zależności tych komponentów w pliku CMakeLists.txt projektu file przy użyciu dyrektyw REQUIRES lub PRIV_REQUIRES. System kompilacji automatycznie zlokalizuje i skompiluje wymagane komponenty.
Dlatego katalog komponentów w myProject nie jest konieczny. Służy tylko do dołączania niektórych niestandardowych komponentów projektu, którymi mogą być biblioteki stron trzecich lub kod zdefiniowany przez użytkownika. Ponadto komponenty mogą pochodzić z dowolnego katalogu innego niż ESP-IDF lub bieżącego projektu, na przykład z projektu open source zapisanego w innym katalogu. W takim przypadku wystarczy dodać ścieżkę komponentu poprzez ustawienie zmiennej EXTRA_COMPONENT_DIRS w pliku CMakeLists.txt w katalogu głównym. Ten katalog zastąpi każdy komponent ESP-IDF o tej samej nazwie, zapewniając użycie prawidłowego komponentu.
Program wejściowy main Główny katalog w projekcie wygląda tak samo file strukturę jak inne komponenty (np. komponent1). Ma on jednak szczególne znaczenie, gdyż jest obowiązkowym elementem, który musi występować w każdym projekcie. Katalog główny zawiera kod źródłowy projektu i punkt wejścia programu użytkownika, zwykle o nazwie app_main. Domyślnie wykonywanie programu użytkownika rozpoczyna się od tego punktu wejścia. Główny komponent różni się również tym, że automatycznie zależy od wszystkich komponentów w ścieżce wyszukiwania. Dlatego nie ma potrzeby jawnego wskazywania zależności przy użyciu dyrektyw REQUIRES lub PRIV_REQUIRES w pliku CMakeLists.txt file.
Konfiguracja file Katalog główny projektu zawiera konfigurację file o nazwie sdkconfig, który zawiera parametry konfiguracyjne wszystkich komponentów projektu. Konfiguracja sdk file jest automatycznie generowany przez system kompilacji i można go modyfikować i ponownie generować za pomocą polecenia idf.py menuconfig. Opcje menuconfig pochodzą głównie z Kconfig.projbuild projektu i Kconfig komponentów. Twórcy komponentów zazwyczaj dodają elementy konfiguracyjne w Kconfig, aby uczynić komponent elastycznym i konfigurowalnym.
Katalog kompilacji Domyślnie katalog kompilacji w projekcie przechowuje pliki pośrednie filei fi-
Rozdział 4. Konfigurowanie środowiska programistycznego 49

nal programy wykonywalne wygenerowane przez polecenie kompilacji idf.py. Ogólnie rzecz biorąc, bezpośredni dostęp do zawartości katalogu kompilacji nie jest konieczny. ESP-IDF udostępnia predefiniowane polecenia umożliwiające interakcję z katalogiem, takie jak użycie polecenia flash idf.py w celu automatycznego zlokalizowania skompilowanego pliku binarnego file i flashuj go na podany adres flash lub użyj polecenia idf.py fullclean, aby wyczyścić cały katalog kompilacji.
Tablica partycji (partitions.csv) Każdy projekt wymaga tablicy partycji w celu podzielenia przestrzeni flash oraz określenia rozmiaru i adresu początkowego programu wykonywalnego oraz przestrzeni danych użytkownika. Polecenie idf.py flash lub program aktualizacyjny OTA zaktualizuje oprogramowanie sprzętowe na odpowiedni adres zgodnie z tą tabelą. ESP-IDF udostępnia kilka domyślnych tablic partycji w komponentach/tabela_partycji, takich jak partycje_singleapp.csv i partycje_dwa_ota.csv, które można wybrać w menuconfig.
Jeśli domyślna tablica partycji systemu nie spełnia wymagań projektu, można dodać niestandardowy plik partycji.csv do katalogu projektu i wybrać go w menuconfig.
4.3.3 Domyślne reguły kompilacji systemu kompilacji
Reguły zastępowania komponentów o tej samej nazwie Podczas procesu wyszukiwania komponentów system kompilacji kieruje się określoną kolejnością. Najpierw wyszukuje wewnętrzne komponenty ESP-IDF, następnie szuka komponentów projektu użytkownika, a na koniec wyszukuje komponenty w EXTRA_COMPONENT_DIRS. W przypadku, gdy wiele katalogów zawiera komponenty o tej samej nazwie, komponent znaleziony w ostatnim katalogu zastępuje wszystkie poprzednie komponenty o tej samej nazwie. Ta reguła pozwala na dostosowywanie komponentów ESP-IDF w ramach projektu użytkownika, przy jednoczesnym zachowaniu nienaruszonego oryginalnego kodu ESP-IDF.
Reguły domyślnego dołączania wspólnych komponentów Jak wspomniano w sekcji 4.3.2, komponenty muszą jawnie określić swoje zależności od innych komponentów w pliku CMakeLists.txt. Jednak typowe komponenty, takie jak freertos, są domyślnie automatycznie dołączane do systemu kompilacji, nawet jeśli ich relacje zależności nie są jawnie zdefiniowane w skrypcie kompilacji. Typowe komponenty ESP-IDF obejmują freertos, Newlib, stertę, log, soc, esp_rom, esp_common, xtensa/riscv i cxx. Używanie tych wspólnych komponentów pozwala uniknąć powtarzalnej pracy podczas pisania pliku CMakeLists.txt i sprawia, że ​​jest on bardziej zwięzły.
Reguły zastępowania elementów konfiguracji Programiści mogą dodawać domyślne parametry konfiguracyjne, dodając konfigurację domyślną file o nazwie sdkconfig.defaults do projektu. Na przykładample, dodając CONFIG_LOG_
50 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

DEFAULT_LEVEL_NONE = y możesz skonfigurować interfejs UART tak, aby domyślnie nie drukował danych dziennika. Ponadto, jeśli dla konkretnego celu konieczne jest ustawienie określonych parametrów, konfiguracja file można dodać o nazwie sdkconfig.defaults.TARGET_NAME, gdzie TARGET_NAME może oznaczać esp32s2, esp32c3 itd. Te konfiguracje files są importowane do sdkconfig podczas kompilacji, z ogólną konfiguracją domyślną file Najpierw importowany jest plik sdkconfig.defaults, a następnie konfiguracja specyficzna dla obiektu docelowego file, na przykład sdkconfig.defaults.esp32c3. W przypadkach, gdy istnieją elementy konfiguracji o tej samej nazwie, ta ostatnia konfiguracja file zastąpi poprzednie.
4.3.4 Wprowadzenie do skryptu kompilacji
Tworząc projekt przy użyciu ESP-IDF, programiści muszą nie tylko napisać kod źródłowy, ale także napisać plik CMakeLists.txt dla projektu i komponentów. Plik CMakeLists.txt jest tekstem file, znany również jako skrypt kompilacji, który definiuje serię obiektów kompilacji, elementów konfiguracji kompilacji i poleceń sterujących procesem kompilacji kodu źródłowego. System kompilacji ESP-IDF v4.3.2 oparty jest na CMake. Oprócz obsługi natywnych funkcji i poleceń CMake, definiuje także szereg funkcji niestandardowych, co znacznie ułatwia pisanie skryptów kompilacji.
Skrypty kompilacji w ESP-IDF obejmują głównie skrypt kompilacji projektu i skrypty kompilacji komponentów. Plik CMakeLists.txt znajdujący się w katalogu głównym projektu nazywany jest skryptem kompilacji projektu, który kieruje procesem kompilacji całego projektu. Podstawowy skrypt kompilacji projektu zazwyczaj zawiera następujące trzy linie:
1. cmake_minimum_required (WERSJA 3.5) 2. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 3. projekt(myProject)
Wśród nich w pierwszej linii należy umieścić cmake_minimum_required (WERSJA 3.5), który służy do wskazania minimalnego numeru wersji CMake wymaganego przez projekt. Nowsze wersje CMake są ogólnie kompatybilne wstecz ze starszymi wersjami, dlatego w przypadku korzystania z nowszych poleceń CMake należy odpowiednio dostosować numer wersji, aby zapewnić kompatybilność.
include($ENV {IDF_PATH}/tools/cmake/project.cmake) importuje predefiniowane elementy konfiguracji i polecenia systemu kompilacji ESP-IDF, w tym domyślne reguły kompilacji systemu kompilacji opisane w Sekcji 4.3.3. projekt(myProject) tworzy sam projekt i określa jego nazwę. Ta nazwa będzie używana jako końcowy plik binarny wyjściowy file nazwę, tj. mójProjekt.elf i mójProjekt.bin.
Projekt może składać się z wielu komponentów, łącznie z komponentem głównym. Katalog najwyższego poziomu każdego komponentu zawiera plik CMakeLists.txt file, który jest nazywany skryptem kompilacji komponentów. Skrypty kompilacji komponentów służą głównie do określania zależności komponentów, parametrów konfiguracyjnych i kodu źródłowego files i dołączony nagłówek files dla
Rozdział 4. Konfigurowanie środowiska programistycznego 51

kompilacja. W przypadku niestandardowej funkcji idf_component_register protokołu ESP-IDF minimalny wymagany kod skryptu kompilacji komponentów jest następujący:

1. idf_component_register(SRCS „src1.c”

2.

INCLUDE_DIRS „uwzględnij”

3.

WYMAGA komponentu1)

Parametr SRCS udostępnia listę źródeł files w komponencie, oddzielone spacjami, jeśli jest ich wiele fileS. Parametr INCLUDE_DIRS udostępnia listę publicznych nagłówków file katalogi dla komponentu, które zostaną dodane do ścieżki wyszukiwania innych komponentów zależnych od bieżącego komponentu. Parametr REQUIRES identyfikuje zależności komponentu publicznego dla bieżącego komponentu. Konieczne jest, aby komponenty wyraźnie określały, od których komponentów zależą, np. komponent2 w zależności od komponentu1. Jednakże dla głównego komponentu, który domyślnie zależy od wszystkich komponentów, parametr REQUIRES można pominąć.

Ponadto w skrypcie kompilacji można również używać natywnych poleceń CMake. Na przykładample, użyj polecenia set, aby ustawić zmienne, takie jak set(ZMIENNA „WARTOŚĆ”).

4.3.5 Wprowadzenie do typowych poleceń
ESP-IDF wykorzystuje CMake (narzędzie do konfiguracji projektu), Ninja (narzędzie do budowania projektów) i esptool (narzędzie Flash) w procesie kompilacji kodu. Każde narzędzie odgrywa inną rolę w procesie kompilacji, budowania i flashowania, a także obsługuje różne polecenia operacyjne. Aby ułatwić użytkownikowi obsługę, ESP-IDF dodaje ujednolicony interfejs idf.py, który umożliwia szybkie wywoływanie powyższych poleceń.
Przed użyciem idf.py upewnij się, że:
· Do bieżącego terminala dodano zmienną środowiskową IDF_PATH protokołu ESP-IDF. · Katalog wykonywania poleceń jest katalogiem głównym projektu, który zawiera plik
skrypt kompilacji projektu CMakeLists.txt.
Typowe polecenia idf.py są następujące:
· idf.py –help: wyświetlanie listy poleceń i instrukcji ich użycia. · idf.py ustawiony cel : ustawienie kompilacji taidf.py fullcleanrget, np
jako zamiennik z esp32c3. · idf.py menuconfig: uruchomienie menuconfig, graficznej konfiguracji terminala
narzędzie, za pomocą którego można wybierać lub modyfikować opcje konfiguracyjne, a wyniki konfiguracji zapisywane są w pliku sdkconfig file. · idf.py build: inicjowanie kompilacji kodu. Półprodukt files, a końcowy program wykonywalny wygenerowany w wyniku kompilacji zostanie domyślnie zapisany w katalogu kompilacji projektu. Proces kompilacji jest przyrostowy, co oznacza, że ​​tylko z jednego źródła file jest modyfikowany, tylko modyfikowany file zostanie skompilowany następnym razem.

52 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

· if.py clean: czyszczenie półproduktu files generowane przez kompilację projektu. Cały projekt zostanie zmuszony do skompilowania w następnej kompilacji. Należy pamiętać, że konfiguracja CMake i modyfikacje konfiguracji dokonane przez menuconfig nie zostaną usunięte podczas czyszczenia.
· idf.py fullclean: usuwanie całego katalogu kompilacji, w tym wszystkich danych wyjściowych konfiguracji CMake fileS. Podczas ponownego budowania projektu CMake skonfiguruje projekt od zera. Pamiętaj, że to polecenie rekurencyjnie usunie wszystko files w katalogu kompilacji, więc używaj go ostrożnie i konfiguracji projektu file nie zostaną usunięte.
· idf.py flash: flashowanie binarnego programu wykonywalnego file wygenerowane przez kompilację do docelowego ESP32-C3. Opcje -str i -b służą do ustawienia odpowiednio nazwy urządzenia portu szeregowego i szybkości transmisji flashowania. Jeśli te dwie opcje nie zostaną określone, port szeregowy zostanie wykryty automatycznie i zostanie użyta domyślna prędkość transmisji.
· Monitor idf.py: wyświetlanie wyjścia portu szeregowego docelowego ESP32-C3. Opcji -p można użyć do określenia nazwy urządzenia portu szeregowego po stronie hosta. Podczas drukowania przez port szeregowy naciśnij kombinację klawiszy Ctrl+], aby wyjść z monitora.
Powyższe polecenia można również łączyć w zależności od potrzeb. Na przykładample, polecenie idf.py build flash monitor wykona po kolei kompilację kodu, flashowanie i otwarcie monitora portu szeregowego.
Możesz odwiedzić https://bookc3.espressif.com/build-system, aby dowiedzieć się więcej o systemie kompilacji ESP-IDF.
4.4 Przećwicz: Kompilowanie przykładuample Program „Miganie”
4.4.1ample Analiza
W tej sekcji program Blink będzie przykłademample do analizy file szczegółowo strukturę i zasady kodowania rzeczywistego projektu. Program Blink implementuje efekt mrugania diodą LED, a projekt znajduje się w katalogu examples/get-started/blink, który zawiera źródło file, konfiguracja files i kilka skryptów kompilacyjnych.
Projekt inteligentnego oświetlenia przedstawiony w tej książce opiera się na tym przykładzieample program. Funkcje będą stopniowo dodawane w późniejszych rozdziałach, aby w końcu je ukończyć.
Kod źródłowy Aby zademonstrować cały proces rozwoju, program Blink został skopiowany do esp32c3-iot-projects/device firmware/1 Blink.
Struktura katalogów projektu Blink files pokazano na rysunku 4.15.
Projekt Blink zawiera tylko jeden katalog główny, który jest specjalnym komponentem
Rozdział 4. Konfigurowanie środowiska programistycznego 53

Rysunek 4.15. File struktura katalogów projektu Blink

należy uwzględnić zgodnie z opisem w sekcji 4.3.2. Katalog główny służy głównie do przechowywania implementacji funkcji app_main(), która jest punktem wejścia do programu użytkownika. Projekt Blink nie zawiera katalogu komponentów, ponieważ jest to np.ampPlik wymaga jedynie użycia komponentów dostarczonych z ESP-IDF i nie wymaga dodatkowych komponentów. Plik CMakeLists.txt zawarty w projekcie Blink służy do kierowania procesem kompilacji, natomiast plik Kconfig.projbuild służy do dodawania elementów konfiguracji dla tego przykładuampplik programu w menuconfig. Inne niepotrzebne files nie będą miały wpływu na kompilację kodu, więc nie będą tutaj omawiane. Szczegółowe wprowadzenie do projektu Blink filejest następująca.

1. /*blink.c zawiera następujący nagłówek fileS*/

2. #uwzględnij

//Nagłówek standardowej biblioteki C file

3. #include „freertos/freeRTOS.h” //główny nagłówek FreeRTOS file

4. #include „freertos/zadanie.h”

//Nagłówek zadania FreeRTOS file

5. #include „sdkconfig.h”

//Nagłówek konfiguracji file wygenerowany przez kconfig

6. #include „sterownik/gpio.h”

//Nagłówek sterownika GPIO file

Źródło file Blink.c zawiera serię nagłówków files odpowiadający deklaracji funkcji

cje. ESP-IDF ogólnie przestrzega kolejności włączania nagłówka standardowej biblioteki files, FreeR-

Nagłówek Warunków korzystania files, nagłówek sterownika files, nagłówek innego komponentu files i nagłówek projektu files.

Kolejność, w jakiej nagłówek files mogą mieć wpływ na końcowy wynik kompilacji, więc spróbuj

postępuj zgodnie z domyślnymi zasadami. Należy zauważyć, że sdkconfig.h jest generowany automatycznie

przez kconfig i można go skonfigurować wyłącznie za pomocą polecenia idf.py menuconfig.

Bezpośrednia modyfikacja tego nagłówka file zostanie nadpisany.

1. /*Możesz wybrać GPIO odpowiadające diodzie LED w idf.py menuconfig, a wynikiem modyfikacji menuconfig jest to, że wartość CONFIG_BLINK

_GPIO zostanie zmienione. Można także bezpośrednio modyfikować definicję makra

tutaj i zmień CONFIG_BLINK_GPIO na stałą wartość.*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO

3. unieważnij aplikację_main(void)

4. {

5.

/* Skonfiguruj IO jako domyślną funkcję GPIO, włącz tryb pull-up i

6.

wyłącz tryby wejścia i wyjścia*/

7.

gpio_reset_pin(BLINK_GPIO);

54 Bezprzewodowa przygoda ESP32-C3: kompleksowy przewodnik po IoT

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

/*Ustaw GPIO w tryb wyjściowy*/ gpio_set_direction(BLINK_GPIO, GPIO_MODE_OUTPUT); podczas gdy(1) {
/*Drukuj log*/ printf(“Wyłączanie diody LEDn”); /*Wyłącz diodę LED (niski poziom wyjściowy)*/ gpio_set_level(BLINK_GPIO, 0); /*Opóźnienie (1000 ms)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf(“Włączenie diody LEDn”); /*Włącz diodę LED (wysoki poziom wyjściowy)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay(1000 / portTICK_PERIOD_MS); }

Funkcja app_main() w przykładzie BlinkampProgram ten służy jako punkt wejścia dla programów użytkownika. Jest to prosta funkcja bez parametrów i wartości zwracanej. Ta funkcja jest wywoływana po zakończeniu inicjalizacji systemu, która obejmuje takie zadania, jak inicjowanie portu szeregowego dziennika, konfigurowanie jednego/dwurdzeniowych rdzeni i konfigurowanie watchdoga.

Funkcja app_main() działa w kontekście zadania o nazwie main. Rozmiar stosu i priorytet tego zadania można dostosować w menuconfig Componentconfig Common związane z ESP.

W przypadku prostych zadań, takich jak miganie diody LED, cały niezbędny kod można zaimplementować bezpośrednio w funkcji app_main(). Zwykle obejmuje to inicjowanie GPIO odpowiadającego diodzie LED i użycie pętli while(1) do włączania i wyłączania diody LED. Alternatywnie możesz użyć FreeRTOS API, aby utworzyć nowe zadanie obsługujące miganie diody LED. Po pomyślnym utworzeniu nowego zadania możesz wyjść z funkcji app_main().

Zawartość pliku main/CMakeLists.txt file, który kieruje procesem kompilacji głównego komponentu, wygląda następująco:

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

Wśród nich plik main/CMakeLists.txt wywołuje tylko jedną funkcję systemu kompilacji, czyli idf_component_register. Podobnie jak plik CMakeLists.txt w przypadku większości innych komponentów, plik Blink.c jest dodawany do SRCS, a źródło files dodane do SRCS zostaną skompilowane. Jednocześnie „.”, które reprezentuje ścieżkę, w której znajduje się plik CMakeLists.txt, należy dodać do INCLUDE_DIRS jako katalogi wyszukiwania dla nagłówka fileS. Zawartość pliku CMakeLists.txt jest następująca:
1. #Określ wersję 3.5 jako najstarszą wersję CMake obsługiwaną przez bieżący projekt 2. #Wersje starsze niż v3.5 muszą zostać zaktualizowane przed kontynuacją kompilacji 3. cmake_minimum_required(WERSJA 3.5) 4. #Dołącz domyślną konfigurację CMake ESP -System kompilacji IDF

Rozdział 4. Konfigurowanie środowiska programistycznego 55

5. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 6. #Utwórz projekt o nazwie „blink” 7. projekt(myProject)
Wśród nich plik CMakeLists.txt w katalogu głównym zawiera głównie $ENV{IDF_ PATH}/tools/cmake/project.cmake, który jest główną konfiguracją CMake file dostarczane przez ESP-IDF. Służy do kon

Dokumenty / Zasoby

Bezprzewodowa przygoda Espressif Systems ESP32-C3 [plik PDF] Instrukcja użytkownika
ESP32-C3 bezprzewodowa przygoda, ESP32-C3, bezprzewodowa przygoda, przygoda

Odniesienia

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *