Espressif Systems ESP32-C3 Wireless Adventure brugervejledning

Før du bruger ESP32-C3 Wireless Adventure, skal du sikre dig, at du er det
bekendt med koncepterne og arkitekturen bag IoT. Dette vil hjælpe
du forstår, hvordan enheden passer ind i det større IoT-økosystem
og dets potentielle anvendelser i smarte hjem.

Introduktion og praktisering af IoT-projekter

I dette afsnit lærer du om typiske IoT-projekter,
herunder basismodulerne til almindelige IoT-enheder, basismoduler
af klientapplikationer og almindelige IoT-cloudplatforme. Dette vil
give dig et grundlag for at forstå og skabe din
egne IoT-projekter.

Praksis: Smart Light Project

I dette praksisprojekt lærer du, hvordan du skaber en smart
lys ved hjælp af ESP32-C3 Wireless Adventure. Projektets struktur,
funktioner, hardwareforberedelse og udviklingsprocessen vil være
forklaret i detaljer.

Projektets struktur

Projektet består af flere komponenter, herunder
ESP32-C3 Wireless Adventure, LED'er, sensorer og en sky
backend.

Projekt funktioner

Det smarte lysprojekt giver dig mulighed for at styre lysstyrken og
farven på lysdioderne eksternt via en mobilapp eller web
interface.

Forberedelse af hardware

For at forberede dig til projektet skal du samle
nødvendige hardwarekomponenter, såsom ESP32-C3 Wireless
Adventure board, LED'er, modstande og en strømforsyning.

Udviklingsproces

Udviklingsprocessen involverer at sætte udviklingen op
miljø, skrive kode til at styre LED'erne, oprette forbindelse til
cloud-backend, og test af smartens funktionalitet
lys.

Introduktion til ESP RainMaker

ESP RainMaker er en kraftfuld ramme til udvikling af IoT
enheder. I dette afsnit lærer du, hvad ESP RainMaker er og
hvordan det kan implementeres i dine projekter.

Hvad er ESP RainMaker?

ESP RainMaker er en cloud-baseret platform, der giver et sæt af
værktøjer og tjenester til at bygge og administrere IoT-enheder.

Implementeringen af ESP RainMaker

Dette afsnit forklarer de forskellige komponenter, der er involveret i
implementering af ESP RainMaker, inklusive kravtjenesten,
RainMaker Agent, cloud-backend og RainMaker Client.

Praksis: Nøglepunkter for udvikling med ESP RainMaker

I dette praksisafsnit lærer du om de vigtigste punkter
overveje, når du udvikler med ESP RainMaker. Dette inkluderer enheden
krav, datasynkronisering og brugeradministration.

Funktioner i ESP RainMaker

ESP RainMaker tilbyder forskellige funktioner til brugerstyring, slut
brugere og administratorer. Disse funktioner giver mulighed for nem enhed
opsætning, fjernbetjening og overvågning.

Opsætning af udviklingsmiljø

Dette afsnit giver en overview af ESP-IDF (Espressif IoT
Development Framework), som er den officielle udviklingsramme
til ESP32-baserede enheder. Det forklarer de forskellige versioner af
ESP-IDF og hvordan man opsætter udviklingsmiljøet.

Hardware og driverudvikling

Hardwaredesign af Smart Light-produkter baseret på ESP32-C3

Dette afsnit fokuserer på hardwaredesignet af smart lys
produkter baseret på ESP32-C3 Wireless Adventure. Det dækker
funktioner og sammensætning af smart light-produkter, samt
hardwaredesign af ESP32-C3 kernesystemet.

Funktioner og sammensætning af Smart Light-produkter

Dette underafsnit forklarer de funktioner og komponenter, der gør
op smart light-produkter. Den diskuterer de forskellige funktionaliteter
og designovervejelser for at skabe smarte lys.

Hardwaredesign af ESP32-C3 Core System

Hardwaredesignet i ESP32-C3-kernesystemet inkluderer strøm
forsyning, startsekvens, systemnulstilling, SPI-flash, urkilde,
og RF- og antenneovervejelser. Dette underafsnit giver
detaljerede oplysninger om disse aspekter.

FAQ

Q: Hvad er ESP RainMaker?

A: ESP RainMaker er en cloud-baseret platform, der leverer værktøjer
og tjenester til at bygge og administrere IoT-enheder. Det forenkler
udviklingsprocessen og giver mulighed for nem enhedsopsætning, fjernbetjening
kontrol og overvågning.

Q: Hvordan kan jeg konfigurere udviklingsmiljøet til
ESP32-C3?

A: For at konfigurere udviklingsmiljøet for ESP32-C3, skal du bruge
at installere ESP-IDF (Espressif IoT Development Framework) og
konfigurer den i henhold til de medfølgende instruktioner. ESP-IDF er
officielle udviklingsramme for ESP32-baserede enheder.

Q: Hvad er funktionerne i ESP RainMaker?

A: ESP RainMaker tilbyder forskellige funktioner, herunder bruger
administration, slutbrugerfunktioner og adminfunktioner. Brugerstyring
giver mulighed for nem enhedskrav og datasynkronisering. Slutbruger
funktioner muliggør fjernstyring af enheder via en mobilapp eller
web interface. Admin-funktioner giver værktøjer til enhedsovervågning
og ledelse.

View Fullscreen

ESP32-C3 trådløst eventyr
En omfattende guide til IoT
Espressif Systems 12. juni 2023

Indhold

I Forberedelse

1 Introduktion til IoT

1.1 Arkitektur af IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 IoT-applikation i smarte hjem. . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Introduktion og praksis af IoT-projekter

2.1 Introduktion til typiske IoT-projekter . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Grundlæggende moduler til almindelige IoT-enheder . . . . . . . . . . . . . . . . . 9

2.1.2 Grundlæggende moduler af klientapplikationer . . . . . . . . . . . . . . . . . . . 10

2.1.3 Introduktion til almindelige IoT-cloudplatforme . . . . . . . . . . . . . . 11

2.2 Praksis: Smart Light Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Projektets struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Projektfunktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Hardwareforberedelse . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Udviklingsproces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Introduktion til ESP RainMaker

3.1 Hvad er ESP RainMaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Implementeringen af ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Reklamationsservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 RainMaker Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 Cloud Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.4 RainMaker Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Praksis: Nøglepunkter for udvikling med ESP RainMaker . . . . . . . . . . . . 25

3.4 Funktioner i ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 Brugerstyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 Slutbrugerfunktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.3 Adminfunktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Opsætning af udviklingsmiljø

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

4.1.1 ESP-IDF-versioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 ESP-IDF Git Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 Valg af en passende version . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4 Overview af ESP-IDF SDK Directory . . . . . . . . . . . . . . . . . . . . 34 4.2 Opsætning af ESP-IDF udviklingsmiljø . . . . . . . . . . . . . . . . . 38 4.2.1 Opsætning af ESP-IDF udviklingsmiljø på Linux . . . . . . . . 38 4.2.2 Opsætning af ESP-IDF udviklingsmiljø på Windows . . . . . . 40 4.2.3 Opsætning af ESP-IDF udviklingsmiljø på Mac . . . . . . . . . 45 4.2.4 Installation af VS-kode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 Introduktion til tredjepartsudviklingsmiljøer . . . . . . . . 46 4.3 ESP-IDF kompileringssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 Grundlæggende begreber for kompileringssystem . . . . . . . . . . . . . . . . . . 47 4.3.2 Projekt File Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 Standard opbygningsregler for kompileringssystemet . . . . . . . . . . . . . 50 4.3.4 Introduktion til kompileringsscriptet . . . . . . . . . . . . . . . . . . 51 4.3.5 Introduktion til almindelige kommandoer . . . . . . . . . . . . . . . . . . . 52 4.4 Praksis: Udarbejdelse af Exampprogrammet "Blink". . . . . . . . . . . . . . . . . . 53 4.4.1 Eksample Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2 Kompilering af Blink-programmet . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 Blinkning af blinkprogrammet . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Seriel portloganalyse af blinkeprogrammet . . . . . . . . . . . . . . 60 4.5 Sammenfatning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

II Hardware- og driverudvikling

5 Hardwaredesign af Smart Light-produkter baseret på ESP32-C3

5.1 Funktioner og sammensætning af Smart Light-produkter . . . . . . . . . . . . . . . 67

5.2 Hardwaredesign af ESP32-C3 Core System . . . . . . . . . . . . . . . . . . . 70

5.2.1 Strømforsyning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2 Startsekvens og systemnulstilling . . . . . . . . . . . . . . . . . . 74

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

5.2.4 Urkilde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.5 RF og antenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.6 Strapningsstifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2.7 GPIO- og PWM-controller . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Praksis: Opbygning af et smart lyssystem med ESP32-C3 . . . . . . . . . . . . . 80

5.3.1 Valg af moduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3.2 Konfiguration af GPIO'er for PWM-signaler . . . . . . . . . . . . . . . . . . . . 82

5.3.3 Download af firmware og fejlfindingsgrænseflade . . . . . . . . . . . . 82

5.3.4 Retningslinjer for RF-design . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 Retningslinjer for strømforsyningsdesign . . . . . . . . . . . . . . . . . . . 86 5.4 Sammenfatning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Driverudvikling

6.1 Driverudviklingsproces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 ESP32-C3 perifere applikationer . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Grundlæggende om LED-driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.1 Farverum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2 LED-driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.3 LED-dæmpning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.4 Introduktion til PWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.4 LED-dæmpningsdriverudvikling . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 Ikke-flygtig opbevaring (NVS) . . . . . . . . . . . . . . . . . . . . . . . . 97

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

6.4.3 LED PWM-programmering . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 Øvelse: Tilføjelse af drivere til Smart Light Project . . . . . . . . . . . . . . . . . 103

6.5.1 Knapdriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5.2 LED-dæmpningsdriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.6 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

III Trådløs kommunikation og kontrol

109

7 Wi-Fi-konfiguration og -forbindelse

111

7.1 Grundlæggende om Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.1 Introduktion til Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.2 Udvikling af IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.3 Wi-Fi-koncepter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.1.4 Wi-Fi-forbindelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2 Grundlæggende om Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.2.1 Introduktion til Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.2 Bluetooth-koncepter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.2.3 Bluetooth-forbindelse . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Wi-Fi-netværkskonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.3.1 Wi-Fi-netværkskonfigurationsvejledning . . . . . . . . . . . . . . . . . . . . 131

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

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

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

7.3.5 Andre metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.4 Wi-Fi-programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 Wi-Fi-komponenter i ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 Øvelse: Wi-Fi-forbindelse . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 Øvelse: Smart Wi-Fi-forbindelse . . . . . . . . . . . . . . . . . . . . . 145
7.5 Øvelse: Wi-Fi-konfiguration i Smart Light Project . . . . . . . . . . . . . . . 156 7.5.1 Wi-Fi-forbindelse i Smart Light Project . . . . . . . . . . . . . . . . . 156 7.5.2 Smart Wi-Fi-konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8 Lokal kontrol

159

8.1 Introduktion til lokal kontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1.1 Anvendelse af lokal kontrol . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.2 Advantages af lokal kontrol. . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.3 Opdagelse af kontrollerede enheder via smartphones . . . . . . . . . . 161

8.1.4 Datakommunikation mellem smartphones og enheder . . . . . . . . 162

8.2 Almindelige lokale opdagelsesmetoder . . . . . . . . . . . . . . . . . . . . . . . . 162

8.2.1 Udsendelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

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

8.2.3 Sammenligning mellem broadcast og multicast . . . . . . . . . . . . . . 176

8.2.4 Multicast Application Protocol mDNS til lokal opdagelse . . . . . . . . 176

8.3 Fælles kommunikationsprotokoller for lokale data . . . . . . . . . . . . . . . 179

8.3.1 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . . . . . 179

8.3.2 HyperText Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . 185

8.3.3 Bruger Datagram-protokol (UDP). . . . . . . . . . . . . . . . . . . . . . 189

8.3.4 Constrained Application Protocol (CoAP) . . . . . . . . . . . . . . . . 192

8.3.5 Bluetooth-protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.3.6 Resumé af datakommunikationsprotokoller . . . . . . . . . . . . . . . 203

8.4 Garanti for datasikkerhed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

8.4.1 Introduktion til Transport Layer Security (TLS) . . . . . . . . . . . . . 207

8.4.2 Introduktion til Datagram Transport Layer Security (DTLS) . . . . . . . 213

8.5 Praksis: Lokal kontrol i Smart Light-projekt . . . . . . . . . . . . . . . . . . 217

8.5.1 Oprettelse af en Wi-Fi-baseret lokal kontrolserver . . . . . . . . . . . . . . . 217

8.5.2 Verifikation af lokal kontrolfunktionalitet ved hjælp af scripts . . . . . . . . . . . 221

8.5.3 Oprettelse af en Bluetooth-baseret lokal kontrolserver . . . . . . . . . . . . 222

8.6 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 Skykontrol

225

9.1 Introduktion til fjernbetjening . . . . . . . . . . . . . . . . . . . . . . . . . . 225

9.2 Cloud Data Communication Protocols . . . . . . . . . . . . . . . . . . . . . . 226

9.2.1 MQTT Introduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 9.2.2 MQTT-principper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.3 MQTT-meddelelsesformat . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.4 Protokolsammenligning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5 Opsætning af MQTT Broker på Linux og Windows . . . . . . . . . . . . 233 9.2.6 Opsætning af MQTT-klient baseret på ESP-IDF . . . . . . . . . . . . . . . . 235 9.3 Sikring af MQTT-datasikkerhed . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.1 Betydning og funktion af certifikater . . . . . . . . . . . . . . . . . . . 237 9.3.2 Generering af certifikater lokalt . . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 Konfiguration af MQTT Broker . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 Konfiguration af MQTT-klient . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.4 Øvelse: Fjernbetjening via ESP RainMaker . . . . . . . . . . . . . . . . 243 9.4.1 ESP RainMaker Grundlæggende . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.2 Node og Cloud Backend Communication Protocol . . . . . . . . . . . 244 9.4.3 Kommunikation mellem klient og Cloud Backend . . . . . . . . . . . 249 9.4.4 Brugerroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 Basistjenester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.4.6 Smart Light Eksample . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.7 RainMaker App og tredjepartsintegrationer . . . . . . . . . . . . . . . 262 9.5 Sammenfatning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

10 Udvikling af smartphone-apps

269

10.1 Introduktion til udvikling af smartphone-apps . . . . . . . . . . . . . . . . . . 269

10.1.1 Overview af smartphone app udvikling. . . . . . . . . . . . . . . 270

10.1.2 Android-projektets struktur . . . . . . . . . . . . . . . . . . . . . . 270

10.1.3 iOS-projektets struktur . . . . . . . . . . . . . . . . . . . . . . . . 271

10.1.4 Livscyklus for en Android-aktivitet . . . . . . . . . . . . . . . . . . . . . . 272

10.1.5 Livscyklus for iOS ViewController . . . . . . . . . . . . . . . . . . . . . . 273

10.2 Oprettelse af et nyt smartphone-app-projekt . . . . . . . . . . . . . . . . . . . . . 275

10.2.1 Forberedelse til Android-udvikling . . . . . . . . . . . . . . . . . . . 275

10.2.2 Oprettelse af et nyt Android-projekt . . . . . . . . . . . . . . . . . . . . . . 275

10.2.3 Tilføjelse af afhængigheder til MyRainmaker . . . . . . . . . . . . . . . . . 276

10.2.4 Tilladelsesanmodning i Android . . . . . . . . . . . . . . . . . . . . . . 277

10.2.5 Forberedelse til iOS-udvikling . . . . . . . . . . . . . . . . . . . . . . 277

10.2.6 Oprettelse af et nyt iOS-projekt . . . . . . . . . . . . . . . . . . . . . . . . 278

10.2.7 Tilføjelse af afhængigheder til MyRainmaker . . . . . . . . . . . . . . . . . 279

10.2.8 Tilladelsesanmodning i iOS . . . . . . . . . . . . . . . . . . . . . . . . . 280

10.3 Analyse af Appens funktionelle krav . . . . . . . . . . . . . . . . . . 281

10.3.1 Analyse af projektets funktionelle krav . . . . . . . . . . . . 282

10.3.2 Analyse af brugerstyringskrav . . . . . . . . . . . . . . . 282 10.3.3 Analyse af enhedsforsynings- og bindingskrav . . . . . . . 283 10.3.4 Analyse af fjernbetjeningskrav . . . . . . . . . . . . . . . . 283 10.3.5 Analyse af planlægningskrav . . . . . . . . . . . . . . . . . . . 284 10.3.6 Analyse af brugercenterkrav . . . . . . . . . . . . . . . . . . 285 10.4 Udvikling af brugerstyring . . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.1 Introduktion til RainMaker API'er . . . . . . . . . . . . . . . . . . . . . . 285 10.4.2 Initiering af kommunikation via smartphone . . . . . . . . . . . . . . . . 286 10.4.3 Kontoregistrering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 10.4.4 Kontologin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 10.5 Udvikling af enhedsforsyning . . . . . . . . . . . . . . . . . . . . . . . 292 10.5.1 Scanningsenheder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 10.5.2 Tilslutning af enheder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.5.3 Generering af hemmelige nøgler . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.4 Hentning af node-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.5 Klargøringsenheder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 10.6 Udvikling af enhedskontrol . . . . . . . . . . . . . . . . . . . . . . . . . . 302 10.6.1 Binding af enheder til skykonti . . . . . . . . . . . . . . . . . . . . 303 10.6.2 Få en liste over enheder . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.6.3 Hentning af enhedsstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 10.6.4 Ændring af enhedsstatus . . . . . . . . . . . . . . . . . . . . . . . . . . 310 10.7 Udvikling af planlægning og brugercenter . . . . . . . . . . . . . . . . . . . 313 10.7.1 Implementering af planlægningsfunktion . . . . . . . . . . . . . . . . . . . . 313 10.7.2 Implementering af brugercenter . . . . . . . . . . . . . . . . . . . . . . . . . 315 10.7.3 Flere Cloud API'er . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.8 Sammenfatning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

11 Firmwareopgradering og versionsstyring

321

11.1 Firmwareopgradering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

11.1.1 Overview af partitionstabeller. . . . . . . . . . . . . . . . . . . . . . . . 322

11.1.2 Firmwarestartproces . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

11.1.3 Overview af OTA-mekanismen. . . . . . . . . . . . . . . . . . . . . 326

11.2 Styring af firmwareversion . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.1 Firmware-mærkning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.2 Tilbageføring og Anti-tilbageføring . . . . . . . . . . . . . . . . . . . . . . . . 331

11.3 Praksis: Over-the-air (OTA) Eksample . . . . . . . . . . . . . . . . . . . . . . . 332

11.3.1 Opgrader firmware via en lokal vært . . . . . . . . . . . . . . . . . 332

11.3.2 Opgrader firmware gennem ESP RainMaker . . . . . . . . . . . . . . . 335

11.4 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

IV optimering og masseproduktion

343

12 Strømstyring og lavenergioptimering

345

12.1 ESP32-C3 Strømstyring . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

12.1.1 Dynamisk frekvensskalering . . . . . . . . . . . . . . . . . . . . . . . . 346

12.1.2 Strømstyringskonfiguration . . . . . . . . . . . . . . . . . . . . 348

12.2 ESP32-C3 Laveffekttilstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

12.2.1 Modem-dvaletilstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

12.2.2 Let dvaletilstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

12.2.3 Dyb dvaletilstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

12.2.4 Strømforbrug i forskellige strømtilstande . . . . . . . . . . . . . 358

12.3 Strømstyring og laveffektsfejlfinding . . . . . . . . . . . . . . . . . 359

12.3.1 Log Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

12.3.2 GPIO-fejlfinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

12.4 Praksis: Strømstyring i Smart Light-projekt . . . . . . . . . . . . . . . 363

12.4.1 Konfiguration af strømstyringsfunktion . . . . . . . . . . . . . . . . . 364

12.4.2 Brug strømstyringslåse . . . . . . . . . . . . . . . . . . . . . . 365

12.4.3 Bekræftelse af strømforbrug . . . . . . . . . . . . . . . . . . . . . . . 366

12.5 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

13 Forbedrede enhedssikkerhedsfunktioner

369

13.1 Overview af IoT-enhedsdatasikkerhed. . . . . . . . . . . . . . . . . . . . . . . 369

13.1.1 Hvorfor sikre IoT-enhedsdata? . . . . . . . . . . . . . . . . . . . . . . 370

13.1.2 Grundlæggende krav til IoT-enhedsdatasikkerhed . . . . . . . . . . . . 371

13.2 Dataintegritetsbeskyttelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

13.2.1 Introduktion til metode til integritetsverifikation . . . . . . . . . . . . . . 372

13.2.2 Integritetsbekræftelse af firmwaredata . . . . . . . . . . . . . . . . . . 373

13.2.3 Eksample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3 Datafortrolighedsbeskyttelse . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.1 Introduktion til datakryptering . . . . . . . . . . . . . . . . . . . . . . 374

13.3.2 Introduktion til Flash-krypteringsskema . . . . . . . . . . . . . . . . . 376

13.3.3 Flash-krypteringsnøglelagring . . . . . . . . . . . . . . . . . . . . . . . 379

13.3.4 Arbejdstilstand for Flash-kryptering . . . . . . . . . . . . . . . . . . . . 380

13.3.5 Flash-krypteringsproces . . . . . . . . . . . . . . . . . . . . . . . . . . 381

13.3.6 Introduktion til NVS-kryptering . . . . . . . . . . . . . . . . . . . . . . 383

13.3.7 Eksamples af Flash-kryptering og NVS-kryptering. . . . . . . . . . . 384

13.4 Beskyttelse af datalegitimitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.1 Introduktion til digital signatur . . . . . . . . . . . . . . . . . . . . . 386

13.4.2 Overview af Secure Boot Scheme . . . . . . . . . . . . . . . . . . . . . 388

13.4.3 Introduktion til Software Secure Boot . . . . . . . . . . . . . . . . . . . 388 13.4.4 Introduktion til sikker hardwarestart . . . . . . . . . . . . . . . . . . 390 13.4.5 Eksamples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 13.5 Praksis: Sikkerhedsfunktioner i masseproduktion . . . . . . . . . . . . . . . . . . 396 13.5.1 Flash-kryptering og sikker opstart . . . . . . . . . . . . . . . . . . . . . 396 13.5.2 Aktivering af Flash-kryptering og sikker opstart med Batch Flash-værktøjer . . 397 13.5.3 Aktivering af Flash-kryptering og sikker opstart i Smart Light Project . . . 398 13.6 Sammenfatning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

14 Firmwarebrænding og -test til masseproduktion

399

14.1 Firmwarebrænding i masseproduktion . . . . . . . . . . . . . . . . . . . . . . 399

14.1.1 Definering af datapartitioner . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.2 Firmwarebrænding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

14.2 Masseproduktionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

14.3 Praksis: Masseproduktionsdata i Smart Light-projekt . . . . . . . . . . . . . 404

14.4 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

15 ESP Insights: Fjernovervågningsplatform

405

15.1 Introduktion til ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

15.2 Kom godt i gang med ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . 409

15.2.1 Kom godt i gang med ESP Insights i esp-insights-projektet . . . . . . 409

15.2.2 Løbende Example i esp-insights Project . . . . . . . . . . . . . . . 411

15.2.3 Rapportering af Coredump-oplysninger . . . . . . . . . . . . . . . . . . . . . 411

15.2.4 Tilpasning af interesselogge . . . . . . . . . . . . . . . . . . . . . . . . 412

15.2.5 Rapportering af årsag til genstart . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.2.6 Rapportering af tilpassede metrics . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.3 Øvelse: Brug af ESP-indsigt i Smart Light-projekt . . . . . . . . . . . . . . . 416

15.4 Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Indledning
ESP32-C3 er en single-core Wi-Fi og Bluetooth 5 (LE) mikrocontroller SoC, baseret på open source RISC-V arkitekturen. Den opnår den rette balance mellem strøm, I/O-kapacitet og sikkerhed, og tilbyder dermed den optimale omkostningseffektive løsning til tilsluttede enheder. For at vise forskellige anvendelser af ESP32-C3-familien, vil denne bog af Espressif tage dig med på en interessant rejse gennem AIoT, startende fra det grundlæggende i IoT-projektudvikling og miljøopsætning til praktiske f.amples. De første fire kapitler taler om IoT, ESP RainMaker og ESP-IDF. Kapitel 5 og 6 kort om hardwaredesign og driverudvikling. Efterhånden som du skrider frem, vil du opdage, hvordan du konfigurerer dit projekt via Wi-Fi-netværk og mobilapps. Til sidst lærer du at optimere dit projekt og sætte det i masseproduktion.
Hvis du er en ingeniør inden for relaterede områder, en softwarearkitekt, en lærer, en studerende eller enhver, der har en interesse i IoT, er denne bog noget for dig.
Du kan downloade koden f.eksample brugt i denne bog fra Espressifs websted på GitHub. For seneste information om IoT-udvikling, følg venligst vores officielle konto.

Forord
En oplysende verden
Som følge af internettets bølge fik Internet of Things (IoT) sin store debut for at blive en ny type infrastruktur i den digitale økonomi. For at bringe teknologien tættere på offentligheden arbejder Espressif Systems for visionen om, at udviklere fra alle samfundslag kan bruge IoT til at løse nogle af de mest presserende problemer i vores tid. En verden af "Intelligent Network of All Things" er, hvad vi forventer af fremtiden.
At designe vores egne chips er en kritisk komponent i denne vision. Det skal være et maraton, der kræver konstante gennembrud mod teknologiske grænser. Fra "Game Changer" ESP8266 til ESP32-serien, der integrerer Wi-Fi og Bluetoothr (LE)-forbindelse, efterfulgt af ESP32-S3 udstyret med AI-acceleration, stopper Espressif aldrig med at forske i og udvikle produkter til AIoT-løsninger. Med vores open source-software, såsom IoT Development Framework ESP-IDF, Mesh Development Framework ESP-MDF og Device Connectivity Platform ESP RainMaker, har vi skabt en uafhængig ramme til opbygning af AIoT-applikationer.
Fra juli 2022 har de kumulative forsendelser af Espressifs IoT-chipsæt oversteget 800 millioner, hvilket er førende på Wi-Fi MCU-markedet og forsyner et stort antal tilsluttede enheder på verdensplan. Udøvelse af ekspertise gør hvert Espressif-produkt til et stort hit for dets høje integrationsniveau og omkostningseffektivitet. Frigivelsen af ESP32-C3 markerer en væsentlig milepæl for Espressifs egenudviklede teknologi. Det er en single-core, 32-bit, RISC-V-baseret MCU med 400KB SRAM, som kan køre ved 160MHz. Den har integreret 2.4 GHz Wi-Fi og Bluetooth 5 (LE) med lang rækkevidde. Den har en fin balance mellem strøm, I/O-kapacitet og sikkerhed, og tilbyder dermed den optimale omkostningseffektive løsning til tilsluttede enheder. Baseret på en så kraftfuld ESP32-C3, er denne bog beregnet til at hjælpe læserne med at forstå IoT-relateret viden med detaljeret illustration og praktiske eks.amples.
Hvorfor skrev vi denne bog?
Espressif Systems er mere end en halvledervirksomhed. Det er også en IoT platform virksomhed, som altid stræber efter gennembrud og innovationer inden for teknologi. Samtidig har Espressif åbnet og delt sit egenudviklede operativsystem og softwareramme med fællesskabet, hvilket danner et unikt økosystem. Ingeniører, producenter og teknologientusiaster udvikler aktivt nye softwareapplikationer baseret på Espressifs produkter, kommunikerer frit og deler deres erfaringer. Du kan hele tiden se udvikleres fascinerende ideer på forskellige platforme, såsom YouTube og GitHub. Populariteten af Espressifs produkter har stimuleret et stigende antal forfattere, som har produceret over 100 bøger baseret på Espressif-chipsæt på mere end ti sprog, herunder engelsk, kinesisk, tysk, fransk og japansk.

Det er støtten og tilliden fra fællesskabspartnere, der tilskynder til Espressifs kontinuerlige innovation. “Vi stræber efter at gøre vores chips, operativsystemer, rammer, løsninger, Cloud, forretningspraksis, værktøjer, dokumentation, skrifter, ideer osv. mere relevante for de svar, folk har brug for i nutidens mest presserende problemer. Dette er Espressifs højeste ambition og moralske kompas.” sagde Mr. Teo Swee Ann, grundlægger og administrerende direktør for Espressif.
Espressif værdsætter læsning og ideer. Da den løbende opgradering af IoT-teknologi stiller højere krav til ingeniører, hvordan kan vi så hjælpe flere mennesker til hurtigt at mestre IoT-chips, operativsystemer, softwarerammer, applikationsskemaer og cloudserviceprodukter? Som man siger, er det bedre at lære en mand at fiske end at give ham fisk. I en brainstormsession gik det op for os, at vi kunne skrive en bog for systematisk at sortere nøgleviden om IoT-udvikling. Vi slog til, samlede hurtigt en gruppe senioringeniører og kombinerede det tekniske teams erfaring med indlejret programmering, IoT-hardware og softwareudvikling, alt sammen medvirkende til udgivelsen af denne bog. I processen med at skrive forsøgte vi vores bedste for at være objektive og retfærdige, frataget kokonen og bruge kortfattede udtryk til at fortælle kompleksiteten og charmen ved Internet of Things. Vi opsummerede omhyggeligt de almindelige spørgsmål, henviste til feedback og forslag fra fællesskabet for klart at kunne besvare de spørgsmål, vi stødte på i udviklingsprocessen, og give praktiske retningslinjer for IoT-udvikling til relevante teknikere og beslutningstagere.
Bogens struktur
Denne bog tager et ingeniør-centreret perspektiv og forklarer den nødvendige viden til IoT-projektudvikling trin for trin. Den er sammensat af fire dele, som følger:
· Forberedelse (kapitel 1): Denne del introducerer arkitekturen for IoT, typisk IoT-projektramme, ESP RainMakerr-skyplatformen og udviklingsmiljøet ESP-IDF for at lægge et solidt fundament for IoT-projektudvikling.
· Hardware- og driverudvikling (kapitel 5): Baseret på ESP6-C32-chipsættet, uddyber denne del minimum hardwaresystem- og driverudvikling og implementerer styring af dæmpning, farvegradering og trådløs kommunikation.
· Trådløs kommunikation og kontrol (kapitel 7): Denne del forklarer det intelligente Wi-Fi-konfigurationsskema baseret på ESP11-C32-chip, lokale og skykontrolprotokoller og lokal- og fjernstyring af enheder. Det giver også ordninger til udvikling af smartphone-apps, firmwareopgradering og versionsstyring.
· Optimering og masseproduktion (kapitel 12-15): Denne del er beregnet til avancerede IoT-applikationer med fokus på optimering af produkter inden for strømstyring, optimering med lavt strømforbrug og forbedret sikkerhed. Den introducerer også firmwarebrænding og -test i masseproduktion, og hvordan man diagnosticerer kørestatus og logfiler for enhedsfirmware gennem fjernovervågningsplatformen ESP Insights.

Om kildekoden
Læsere kan køre exampprogrammerne i denne bog, enten ved at indtaste koden manuelt eller ved at bruge kildekoden, der følger med bogen. Vi lægger vægt på kombinationen af teori og praksis, og sætter således et Praksis-afsnit baseret på Smart Light-projektet i næsten hvert kapitel. Alle koder er open source. Læsere er velkomne til at downloade kildekoden og diskutere den i sektionerne relateret til denne bog på GitHub og vores officielle forum esp32.com. Denne bogs open source-kode er underlagt vilkårene i Apache License 2.0.
Forfatterens note
Denne bog er officielt produceret af Espressif Systems og er skrevet af virksomhedens senioringeniører. Det er velegnet til ledere og F&U-personale i IoT-relaterede industrier, lærere og studerende fra relaterede hovedfag og entusiaster inden for Internet of Things. Vi håber, at denne bog kan tjene som en arbejdsmanual, en opslagsbog og en sengebog for at være som en god vejleder og ven.
Mens vi kompilerede denne bog, henviste vi til nogle relevante forskningsresultater fra eksperter, forskere og teknikere i ind- og udland, og vi gjorde vores bedste for at citere dem i henhold til akademiske normer. Det kan dog ikke undgås, at der skulle være nogle udeladelser, så her vil vi gerne udtrykke vores dybe respekt og taknemmelighed til alle relevante forfattere. Derudover har vi citeret information fra internettet, så vi vil gerne takke de originale forfattere og udgivere og undskylde, at vi ikke kan angive kilden til hver enkelt information.
For at producere en bog af høj kvalitet har vi organiseret runder med interne diskussioner og lært af forslag og feedback fra prøvelæsere og forlagsredaktører. Her vil vi gerne igen takke dig for din hjælp, som alle har bidraget til dette succesfulde arbejde.
Sidst, men det vigtigste, tak til alle hos Espressif, som har arbejdet så hårdt for fødslen og populariseringen af vores produkter.
Udviklingen af IoT-projekter involverer en bred vifte af viden. Begrænset til bogens længde samt forfatterens niveau og erfaring er udeladelser uundgåelige. Derfor beder vi venligst eksperter og læsere om at kritisere og rette vores fejl. Hvis du har forslag til denne bog, bedes du kontakte os på book@espressif.com. Vi ser frem til din feedback.

Hvordan bruger man denne bog?
Koden til projekterne i denne bog har været open source. Du kan downloade det fra vores GitHub-lager og dele dine tanker og spørgsmål på vores officielle forum. GitHub: https://github.com/espressif/book-esp32c3-iot-projects Forum: https://www.esp32.com/bookc3 Gennem hele bogen vil der være dele fremhævet som vist nedenfor.
Kildekode I denne bog lægger vi vægt på kombinationen af teori og praksis, og sætter således et Praksis-afsnit om Smart Light-projektet i næsten hvert kapitel. Tilsvarende trin og kildeside vil blive markeret mellem to linjer, der begynder med tag Kildekode.
BEMÆRK/TIPS Det er her, du kan finde nogle vigtige oplysninger og påmindelser om succesfuld fejlretning af dit program. De vil blive markeret mellem to tykke linjer, der begynder med tag BEMÆRK eller TIPS.
De fleste af kommandoerne i denne bog udføres under Linux, bedt om af tegnet "$". Hvis kommandoen kræver superbrugerrettigheder for at udføre, vil prompten blive erstattet af "#". Kommandoprompten på Mac-systemer er "%", som brugt i Afsnit 4.2.3 Installation af ESP-IDF på Mac.
Brødteksten i denne bog vil blive trykt i Charter, mens koden examples, komponenter, funktioner, variabler, kode file navne, kodemapper og strenge vil være i Courier New.
Kommandoer eller tekster, der skal indtastes af brugeren, og kommandoer, der kan indtastes ved at trykke på "Enter"-tasten, vil blive udskrevet med Courier New fed. Logfiler og kodeblokke vil blive præsenteret i lyseblå bokse.
Exampdet:
For det andet skal du bruge esp-idf/components/nvs flash/nvs partition generator/nvs partition gen.py til at generere NVS partition binær file på udviklingsværten med følgende kommando:
$ python $IDF PATH/components/nvs flash/nvs partitionsgenerator/nvs partition gen.py –input masse prod.csv –output masse prod.bin –størrelse NVS PARTITIONSSTØRRELSE

Kapitel 1

Indledning

til

IoT

I slutningen af det 20. århundrede, med fremkomsten af computernetværk og kommunikationsteknologier, blev internettet hurtigt integreret i folks liv. Efterhånden som internetteknologien fortsætter med at modnes, blev ideen om Internet of Things (IoT) født. Bogstaveligt talt betyder IoT et internet, hvor tingene er forbundet. Mens det originale internet bryder grænserne for rum og tid og indsnævrer afstanden mellem "person og person", gør IoT "ting" til en vigtig deltager, der bringer "mennesker" og "ting" tættere sammen. Inden for en overskuelig fremtid vil IoT blive informationsindustriens drivkraft.
Så hvad er tingenes internet?
Det er svært præcist at definere tingenes internet, da dets betydning og omfang er i konstant udvikling. I 1995 bragte Bill Gates første gang ideen om IoT op i sin bog The Road Ahead. Kort sagt gør IoT det muligt for objekter at udveksle information med hinanden via internettet. Dets ultimative mål er at etablere et "Internet of Everything". Dette er en tidlig fortolkning af IoT, såvel som en fantasi om fremtidig teknologi. Tredive år senere, med den hurtige udvikling af økonomi og teknologi, er fantasien ved at blive til virkelighed. Fra smarte enheder, smarte hjem, smarte byer, Internet of Vehicles og bærbare enheder til "metaverset", der understøttes af IoT-teknologier, dukker nye koncepter konstant op. I dette kapitel vil vi begynde med en forklaring af arkitekturen bag Internet of Things og derefter introducere den mest almindelige IoT-applikation, det smarte hjem, for at hjælpe dig med at få en klar forståelse af IoT.
1.1 Arkitektur af IoT
Internet of Things involverer flere teknologier, som har forskellige applikationsbehov og -former i forskellige brancher. For at sortere strukturen, nøgleteknologierne og applikationsegenskaberne ved IoT er det nødvendigt at etablere en samlet arkitektur og et standard teknisk system. I denne bog er IoT-arkitekturen simpelthen opdelt i fire lag: perception & control layer, network layer, platform layer og application layer.
Perception & Control Layer Som det mest grundlæggende element i IoT-arkitekturen er perception & control-laget kernen til at realisere den omfattende sansning af IoT. Dens hovedfunktion er at indsamle, identificere og kontrollere information. Den består af en række forskellige enheder med evnen til perception,
3

identifikation, kontrol og udførelse, og er ansvarlig for at hente og analysere data såsom materialeegenskaber, adfærdstendenser og enhedsstatus. På denne måde får IoT genkendt den virkelige fysiske verden. Desuden er laget også i stand til at kontrollere enhedens status.
De mest almindelige enheder i dette lag er forskellige sensorer, som spiller en vigtig rolle i informationsindsamling og identifikation. Sensorer er som menneskelige sanseorganer, såsom lysfølsomme sensorer svarende til syn, akustiske sensorer til hørelse, gassensorer til lugte og tryk- og temperaturfølsomme sensorer til berøring. Med alle disse "sanseorganer" bliver objekter "levende" og i stand til intelligent perception, genkendelse og manipulation af den fysiske verden.
Netværkslag Netværkslagets hovedfunktion er at transmittere information, inklusive data opnået fra perceptions- og kontrollaget til specificeret mål, såvel som kommandoer udstedt fra applikationslaget tilbage til perceptions- og kontrollaget. Det fungerer som en vigtig kommunikationsbro, der forbinder forskellige lag af et IoT-system. For at opsætte en grundlæggende model af Internet of Things, involverer det to trin at integrere objekter i et netværk: adgang til internettet og transmission via internettet.
Adgang til internet Internettet muliggør sammenkobling mellem person og person, men undlader at inkludere ting i den store familie. Før fremkomsten af IoT var de fleste ting ikke "netværksdygtige". Takket være den kontinuerlige udvikling af teknologi, formår IoT at forbinde ting med internettet, og dermed realisere sammenkobling mellem "mennesker og ting", og "ting og ting". Der er to almindelige måder at implementere internetforbindelse på: kablet netværksadgang og trådløs netværksadgang.
Kablet netværksadgangsmetoder omfatter Ethernet, seriel kommunikation (f.eks. RS-232, RS-485) og USB, mens trådløs netværksadgang afhænger af trådløs kommunikation, som yderligere kan opdeles i kortdistance trådløs kommunikation og langdistance trådløs kommunikation.
Kortdistance trådløs kommunikation omfatter ZigBee, Bluetoothr, Wi-Fi, Near-Field Communication (NFC) og Radio Frequency Identification (RFID). Langrækkende trådløs kommunikation inkluderer Enhanced Machine Type Communication (eMTC), LoRa, Narrow Band Internet of Things (NB-IoT), 2G, 3G, 4G, 5G osv.
Transmission via internettet Forskellige metoder til internetadgang fører til tilsvarende fysisk transmissionsforbindelse af data. Den næste ting er at beslutte, hvilken kommunikationsprotokol der skal bruges til at overføre dataene. Sammenlignet med internetterminaler har de fleste IoT-terminaler i øjeblikket færre
4 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

tilgængelige ressourcer, såsom behandlingsydelse, lagerkapacitet, netværkshastighed osv., så det er nødvendigt at vælge en kommunikationsprotokol, der optager færre ressourcer i IoT-applikationer. Der er to kommunikationsprotokoller, der er meget udbredt i dag: Message Queuing Telemetry Transport (MQTT) og Constrained Application Protocol (CoAP).
Platformlag Platformlaget refererer hovedsageligt til IoT-skyplatforme. Når alle IoT-terminaler er forbundet i netværk, skal deres data aggregeres på en IoT-cloudplatform for at blive beregnet og gemt. Platformlaget understøtter hovedsageligt IoT-applikationer til at lette adgang og administration af massive enheder. Den forbinder IoT-terminaler til cloud-platformen, indsamler terminaldata og udsteder kommandoer til terminaler for at implementere fjernstyring. Som en mellemtjeneste til at tildele udstyr til industriapplikationer spiller platformlaget en forbindelsesrolle i hele IoT-arkitekturen, der bærer abstrakt forretningslogik og standardiseret kernedatamodel, som ikke kun kan realisere hurtig adgang til enheder, men også giver kraftfulde modulære muligheder for at imødekomme forskellige behov i brancheapplikationsscenarier. Platformlaget omfatter hovedsageligt funktionelle moduler såsom enhedsadgang, enhedsadministration, sikkerhedsstyring, meddelelseskommunikation, overvågning af drift og vedligeholdelse og dataapplikationer.
· Enhedsadgang, realisering af forbindelsen og kommunikationen mellem terminaler og IoT-cloudplatforme.
· Enhedsstyring, herunder funktioner såsom oprettelse af enhed, vedligeholdelse af enheder, datakonvertering, datasynkronisering og enhedsdistribution.
· Sikkerhedsstyring, der sikrer sikkerheden af IoT-datatransmission ud fra perspektiverne af sikkerhedsgodkendelse og kommunikationssikkerhed.
· Beskedkommunikation, herunder tre transmissionsretninger, det vil sige, at terminalen sender data til IoT-skyplatformen, IoT-skyplatformen sender data til serversiden eller andre IoT-skyplatforme, og serversiden fjernstyrer IoT-enheder.
· Overvågning af O&M, der involverer overvågning og diagnose, firmwareopgradering, online debugging, logtjenester mv.
· Dataapplikationer, der involverer lagring, analyse og anvendelse af data.
Applikationslag Applikationslaget bruger dataene fra platformslaget til at styre applikationen, filtrere og behandle dem med værktøjer som databaser og analysesoftware. De resulterende data kan bruges til IoT-applikationer i den virkelige verden, såsom smart sundhedspleje, smart landbrug, smarte hjem og smarte byer.
Selvfølgelig kan IoT-arkitekturen opdeles i flere lag, men uanset hvor mange lag den består af, forbliver det underliggende princip stort set det samme. Læring
Kapitel 1. Introduktion til IoT 5

om IoT-arkitekturen hjælper med at uddybe vores forståelse af IoT-teknologier og opbygge fuldt funktionelle IoT-projekter.
1.2 IoT-applikation i smarte hjem
IoT er trængt ind i alle samfundslag, og den mest beslægtede IoT-applikation for os er det smarte hjem. Mange traditionelle apparater er nu udstyret med en eller flere IoT-enheder, og mange nybyggede huse er designet med IoT-teknologier fra starten. Figur 1.1 viser nogle almindelige smart home-enheder.
Figur 1.1. Almindelige smart home-enheder Udviklingen af smart home kan ganske enkelt opdeles i smarte produktertage, scenesammenkobling stage og intelligent stage, som vist i figur 1.2.
Figur 1.2. Udvikling stage of smart home 6 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

De første stage handler om smarte produkter. Til forskel fra traditionelle hjem, i smarte hjem, modtager IoT-enheder signaler med sensorer og er forbundet via trådløse kommunikationsteknologier såsom Wi-Fi, Bluetooth LE og ZigBee. Brugere kan styre smarte produkter på en række forskellige måder, såsom smartphone-apps, stemmeassistenter, smart højttalerkontrol osv. Den anden stage fokuserer på sammenkobling af scener. I dette stage, udviklere overvejer ikke længere at kontrollere et enkelt smart produkt, men at forbinde to eller flere smarte produkter sammen, automatisere til en vis grad og til sidst danne en tilpasset scenetilstand. F.eksampNår brugeren trykker på en vilkårlig scenetilstandsknap, vil lys, gardiner og klimaanlæg automatisk blive tilpasset til forudindstillingerne. Naturligvis er der en forudsætning, at koblingslogikken er let opsat, inklusive triggerbetingelser og udførelseshandlinger. Forestil dig, at aircondition-opvarmningstilstanden udløses, når indendørstemperaturen falder til under 10°C; at der klokken 7 om morgenen spilles musik for at vække brugeren, smarte gardiner åbnes, og riskogeren eller brødristeren starter gennem en smart stikkontakt; efterhånden som brugeren står op og er færdig med at vaske, er morgenmaden allerede serveret, så der ikke bliver nogen forsinkelse i at gå på arbejde. Hvor er vores liv blevet bekvemt! Den tredje stage går til intelligens stage. Efterhånden som der er adgang til flere smarte hjemmeenheder, vil de genererede datatyper også blive det. Ved hjælp af cloud computing, big data og kunstig intelligens er det som om, der er plantet en "smartere hjerne" ind i smarte hjem, som ikke længere kræver hyppige kommandoer fra brugeren. De indsamler data fra tidligere interaktioner og lærer brugerens adfærdsmønstre og præferencer for at automatisere aktiviteter, herunder give anbefalinger til beslutningstagning. I øjeblikket er de fleste smarte hjem på scenen sammenkobling stage. Efterhånden som smarte produkters penetrationshastighed og intelligens stiger, fjernes barrierer mellem kommunikationsprotokoller. I fremtiden er smarte hjem forpligtet til at blive rigtig "smarte", ligesom AI-systemet Jarvis i Iron Man, der ikke kun kan hjælpe brugeren med at styre forskellige enheder, håndtere daglige anliggender, men også har super computerkraft og tænkeevne. I den intelligente stage, mennesker vil modtage bedre tjenester både i kvantitet og kvalitet.
Kapitel 1. Introduktion til IoT 7

8 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Kapitel Introduktion og praksis af 2 IoT-projekter
I kapitel 1 introducerede vi IoT's arkitektur og rollerne og sammenhængen mellem perceptions- og kontrollaget, netværkslaget, platformslaget og applikationslaget, samt udviklingen af smart home. Men ligesom når vi lærer at male, er det langt fra nok at kende den teoretiske viden. Vi er nødt til at "få hænderne snavsede" for at omsætte IoT-projekter i praksis for virkelig at mestre teknologien. Derudover, når et projekt flytter til masseproduktionentage, det er nødvendigt at overveje flere faktorer såsom netværksforbindelse, konfiguration, interaktion med IoT-cloudplatformen, firmwarestyring og -opdateringer, masseproduktionsstyring og sikkerhedskonfiguration. Så hvad skal vi være opmærksomme på, når vi udvikler et komplet IoT-projekt? I kapitel 1 nævnte vi, at smart home er et af de mest almindelige IoT-applikationsscenarier, og smart lights er et af de mest basale og praktiske apparater, som kan bruges i hjem, hoteller, fitnesscentre, hospitaler osv. denne bog vil vi tage udgangspunkt i konstruktionen af et smart lys-projekt, forklare dets komponenter og funktioner og give vejledning om projektudvikling. Vi håber, at du kan drage slutninger fra denne sag for at skabe flere IoT-applikationer.
2.1 Introduktion til typiske IoT-projekter
Med hensyn til udvikling kan grundlæggende funktionelle moduler af IoT-projekter klassificeres i software- og hardwareudvikling af IoT-enheder, klientapplikationsudvikling og IoT-cloudplatformudvikling. Det er vigtigt at præcisere de grundlæggende funktionsmoduler, som vil blive yderligere beskrevet i dette afsnit.
2.1.1 Grundmoduler til almindelige IoT-enheder
Software- og hardwareudvikling af IoT-enheder omfatter følgende grundmoduler: Dataindsamling
Som det nederste lag af IoT-arkitekturen forbinder IoT-enhederne i perceptions- og kontrollaget sensorer og enheder gennem deres chips og periferiudstyr for at opnå dataindsamling og driftskontrol.
9

Kontobinding og indledende konfiguration For de fleste IoT-enheder fuldføres kontobinding og indledende konfiguration i én operationel proces, f.eks.ample, forbinder enheder med brugere ved at konfigurere Wi-Fi-netværk.
Interaktion med IoT-cloudplatforme For at overvåge og kontrollere IoT-enheder er det også nødvendigt at forbinde dem til IoT-cloudplatforme, for at give kommandoer og rapportere status gennem interaktion mellem hinanden.
Enhedskontrol Når de er forbundet med IoT-skyplatforme, kan enheder kommunikere med skyen og blive registreret, bundet eller kontrolleret. Brugere kan forespørge om produktstatus og udføre andre handlinger på smartphone-appen gennem IoT-cloudplatforme eller lokale kommunikationsprotokoller.
Firmwareopgradering IoT-enheder kan også opnå firmwareopgradering baseret på producenternes behov. Ved at modtage kommandoer sendt af skyen vil firmwareopgradering og versionsstyring blive realiseret. Med denne firmwareopgraderingsfunktion kan du løbende forbedre funktionerne i IoT-enheder, rette defekter og forbedre brugeroplevelsen.
2.1.2 Grundlæggende moduler af klientapplikationer
Klientapplikationer (f.eks. smartphone-apps) omfatter hovedsageligt følgende grundlæggende moduler:
Kontosystem og autorisation Det understøtter konto- og enhedsautorisation.
Enhedskontrol Smartphone-apps er normalt udstyret med styrefunktioner. Brugere kan nemt oprette forbindelse til IoT-enheder og administrere dem når som helst og hvor som helst via smartphone-apps. I et smart hjem i den virkelige verden styres enheder for det meste gennem smartphone-apps, hvilket ikke kun muliggør intelligent styring af enheder, men også sparer omkostningerne til arbejdskraft. Derfor er enhedskontrol et must for klientapplikationer, såsom enhedsfunktionsattributkontrol, scenekontrol, planlægning, fjernbetjening, enhedsforbindelse osv. Smart home-brugere kan også tilpasse scener efter personlige behov, styre belysning, husholdningsapparater, indgang osv., for at gøre hjemmet mere behageligt og bekvemt. De kan time klimaanlægget, slukke det på afstand, tænde for gangens lys automatisk, når døren er låst op, eller skifte til "teater"-tilstand med en enkelt knap.
Notification Client-applikationer opdaterer realtidsstatus for IoT-enheder og sender advarsler, når enheder bliver unormale.
10 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Kundeservice efter salg Smartphone-apps kan levere eftersalgsservice til produkter for at løse problemer relateret til IoT-enhedsfejl og tekniske operationer rettidigt.
Udvalgte funktioner For at imødekomme forskellige brugeres behov kan andre funktioner tilføjes, såsom Shake, NFC, GPS osv. GPS kan hjælpe med at indstille nøjagtigheden af sceneoperationer i henhold til placering og afstand, mens Shake-funktionen giver brugerne mulighed for at indstille kommandoer, der skal udføres for en bestemt enhed eller scene ved at ryste.
2.1.3 Introduktion til almindelige IoT Cloud-platforme
IoT cloud platform er en alt-i-en platform, der integrerer funktioner som enhedsadministration, datasikkerhedskommunikation og notifikationshåndtering. IoT-cloudplatforme kan efter deres målgruppe og tilgængelighed opdeles i offentlige IoT-cloudplatforme (herefter benævnt "public cloud") og private IoT-cloudplatforme (herefter benævnt "private cloud").
Offentlig sky angiver normalt delte IoT-cloudplatforme for virksomheder eller enkeltpersoner, drevet og vedligeholdt af platformudbydere og delt via internettet. Det kan være gratis eller billigt og leverer tjenester i hele det åbne offentlige netværk, såsom Alibaba Cloud, Tencent Cloud, Baidu Cloud, AWS IoT, Google IoT osv. Som en understøttende platform kan public cloud integrere upstream-tjenesteudbydere og downstream slutbrugere til at skabe en ny værdikæde og økosystem.
Private cloud er kun bygget til virksomhedsbrug og garanterer dermed den bedste kontrol over data, sikkerhed og servicekvalitet. Dets tjenester og infrastruktur vedligeholdes separat af virksomheder, og den understøttende hardware og software er også dedikeret til specifikke brugere. Virksomheder kan tilpasse cloud-tjenester til at opfylde deres virksomheds behov. På nuværende tidspunkt har nogle smart home-producenter allerede fået private IoT-cloudplatforme og udviklet smart home-applikationer baseret på dem.
Public cloud og private cloud har deres egen fordeltages, hvilket vil blive forklaret senere.
For at opnå kommunikationsforbindelse er det nødvendigt at gennemføre i det mindste indlejret udvikling på enhedssiden sammen med virksomhedsservere, IoT-cloudplatforme og smartphone-apps. Over for et så stort projekt leverer public cloud normalt softwareudviklingssæt til enhedsside- og smartphone-apps for at fremskynde processen. Både offentlig og privat sky leverer tjenester, herunder enhedsadgang, enhedsadministration, enhedsskygge og drift og vedligeholdelse.
Enhedsadgang IoT-skyplatforme skal ikke kun levere grænseflader til enhedsadgang ved hjælp af protokoller
Kapitel 2. Introduktion og praksis af IoT-projekter 11

såsom MQTT, CoAP, HTTPS og WebSocket, men også funktionen af enhedssikkerhedsgodkendelse til at blokere forfalskede og ulovlige enheder, hvilket effektivt reducerer risikoen for at blive kompromitteret. En sådan godkendelse understøtter normalt forskellige mekanismer, så når enheder masseproduceres, er det nødvendigt at forhåndstildele enhedscertifikatet i henhold til den valgte godkendelsesmekanisme og brænde det ind i enhederne.
Enhedsadministration Enhedsadministrationsfunktionen leveret af IoT-skyplatforme kan ikke kun hjælpe producenter med at overvåge aktiveringsstatus og onlinestatus for deres enheder i realtid, men tillader også muligheder såsom tilføjelse/fjernelse af enheder, hentning, tilføjelse/sletning af grupper, firmwareopgradering , og versionsstyring.
Device shadow IoT-skyplatforme kan skabe en vedvarende virtuel version (device shadow) for hver enhed, og status for enhedsskyggen kan synkroniseres og opnås af smartphone-app eller andre enheder gennem internettransmissionsprotokoller. Enhedsskygge gemmer den seneste rapporterede status og forventede status for hver enhed, og selvom enheden er offline, kan den stadig få status ved at kalde API'er. Device shadow giver altid aktive API'er, hvilket gør det nemmere at bygge smartphone-apps, der interagerer med enheder.
Drift og vedligeholdelse O&M-funktionen omfatter tre aspekter: · Demonstrering af statistisk information om IoT-enheder og notifikationer. · Logstyring giver mulighed for at hente oplysninger om enhedens adfærd, op/ned meddelelsesflow og meddelelsesindhold. · Enhedsfejlfinding understøtter kommandolevering, konfigurationsopdatering og kontrol af interaktionen mellem IoT-skyplatforme og enhedsmeddelelser.
2.2 Praksis: Smart Light Project
Efter den teoretiske introduktion i hvert kapitel vil du finde en praksissektion relateret til Smart Light-projektet for at hjælpe dig med at få praktisk erfaring. Projektet er baseret på Espressifs ESP32-C3-chip og ESP RainMaker IoT Cloud Platform og dækker trådløst modulhardware i smart light-produkter, indlejret software til smartenheder baseret på ESP32C3, smartphone-apps og ESP RainMaker-interaktion.
Kildekode For bedre læring og udvikling af erfaringer er projektet i denne bog blevet opensourcet. Du kan downloade kildekoden fra vores GitHub-lager på https://github. com/espressif/book-esp32c3-iot-projects.
12 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

2.2.1 Projektets struktur
Smart Light-projektet består af tre dele: i. Smart lysenheder baseret på ESP32-C3, ansvarlige for at interagere med IoT-skyplatforme og styre kontakten, lysstyrken og farvetemperaturen på LED lamp perler. ii. Smartphone-apps (inklusive tablet-apps, der kører på Android og iOS), ansvarlige for netværkskonfiguration af smart light-produkter samt forespørgsel og styring af deres status.
iii. En IoT cloud platform baseret på ESP RainMaker. For forenklings skyld betragter vi IoT-cloudplatformen og forretningsserveren som en helhed i denne bog. Detaljer om ESP RainMaker vil blive givet i kapitel 3.
Overensstemmelsen mellem Smart Light-projektets struktur og IoT-arkitekturen er vist i figur 2.1.
Figur 2.1. Struktur af smart lysprojekt
2.2.2 Projektfunktioner
Opdelt i henhold til strukturen er funktionerne for hver del som følger. Smarte lysenheder
· Netværkskonfiguration og -forbindelse. · LED PWM-styring, såsom kontakt, lysstyrke, farvetemperatur osv. · Automatisering eller scenestyring, f.eks. ur. · Kryptering og sikker opstart af Flash. · Firmwareopgradering og versionsstyring.
Kapitel 2. Introduktion og praksis af IoT-projekter 13

Smartphone apps · Netværkskonfiguration og enhedsbinding. · Smart lys produktkontrol, såsom kontakt, lysstyrke, farvetemperatur osv. · Automatisering eller sceneindstillinger, f.eks. tidskontakt. · Lokal/fjernbetjening. · Brugerregistrering, login mv.
ESP RainMaker IoT cloud platform · Muliggør IoT-enhedsadgang. · Levering af enhedsbetjenings-API'er, der er tilgængelige for smartphone-apps. · Firmwareopgradering og versionsstyring.
2.2.3 Hardwareforberedelse
Hvis du er interesseret i at føre projektet ud i livet, skal du også bruge følgende hardware: smarte lys, smartphones, Wi-Fi-routere og en computer, der opfylder installationskravene i udviklingsmiljøet. Smart lys
Smart lys er en ny type pærer, hvis form er den samme som den almindelige glødepære. Et smart lys er sammensat af kondensator-trinsreguleret strømforsyning, trådløst modul (med indbygget ESP32-C3), LED-controller og RGB LED-matrix. Når den er tilsluttet strøm, vil 15 V DC voltagUdgangen efter kondensatornedtrapning, diodeensretning og regulering giver energi til LED-controlleren og LED-matrixen. LED-controlleren kan automatisk sende høje og lave niveauer med bestemte intervaller, og skifte RGB LED-matrix mellem lukket (lys tændt) og åben (lys slukket), så den kan udsende cyan, gul, grøn, lilla, blå, rød og hvidt lys. Det trådløse modul er ansvarlig for at oprette forbindelse til Wi-Fi-routeren, modtage og rapportere status for smarte lys og sende kommandoer til at styre LED'en.
Figur 2.2. Et simuleret smart lys
I den tidlige udvikling stage, du kan simulere et smart lys ved hjælp af ESP32-C3DevKitM-1-kortet forbundet med RGB LED lamp perler (se figur 2.2). Men det burde du
14 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

bemærk, at dette ikke er den eneste måde at samle et smart lys på. Hardwaredesignet af projektet i denne bog indeholder kun et trådløst modul (med indbygget ESP32-C3), men ikke et komplet smart light hardwaredesign. Derudover producerer Espressif også et ESP32-C3-baseret lydudviklingskort ESP32C3-Lyra til styring af lys med lyd. Tavlen har interfaces til mikrofoner og højttalere og kan styre LED-strips. Det kan bruges til at udvikle ultra-lave omkostninger, højtydende audio-udsendere og rytmelysstrimler. Figur 2.3 viser et ESP32-C3Lyra-kort forbundet med en stribe med 40 LED-lys.
Figur 2.3. ESP32-C3-Lyra forbundet med en stribe med 40 LED-lys
Smartphones (Android/iOS) Smart Light-projektet involverer udvikling af en smartphone-app til opsætning og styring af smart light-produkter.
Wi-Fi-routere Wi-Fi-routere konverterer kablede netværkssignaler og mobilnetværkssignaler til trådløse netværkssignaler, så computere, smartphones, tablets og andre trådløse enheder kan oprette forbindelse til netværket. F.eksample, bredbånd i hjemmet behøver kun at være forbundet til en Wi-Fi-router for at opnå trådløst netværk af Wi-Fi-enheder. Den almindelige protokolstandard, der understøttes af Wi-Fi-routere, er IEEE 802.11n, med en gennemsnitlig TxRate på 300 Mbps eller maksimalt 600 Mbps. De er bagudkompatible med IEEE 802.11b og IEEE 802.11g. ESP32-C3-chippen fra Espressif understøtter IEEE 802.11b/g/n, så du kan vælge en enkeltbånds (2.4 GHz) eller dual-band (2.4 GHz og 5 GHz) Wi-Fi-router.
Et computer (Linux/macOS/Windows) udviklingsmiljø vil blive introduceret i kapitel 4. Kapitel 2. Introduktion og praksis af IoT-projekter 15

2.2.4 Udviklingsproces
Figur 2.4. Trin til udvikling af Smart Light-projektet
Hardwaredesign Hardwaredesign af IoT-enheder er afgørende for et IoT-projekt. Et komplet smart lys-projekt er beregnet til at producere alamp arbejder under netforsyning. Forskellige producenter producerer lamps af forskellige stilarter og drivertyper, men deres trådløse moduler har normalt samme funktion. For at forenkle udviklingsprocessen af Smart Ligh-projektet, dækker denne bog kun hardwaredesign og softwareudvikling af trådløse moduler.
Konfiguration af IoT cloud platform For at bruge IoT cloud platforme skal du konfigurere projekter på backend, såsom oprettelse af produkter, oprettelse af enheder, indstilling af enhedsegenskaber osv.
Indlejret softwareudvikling til IoT-enheder Implementer forventede funktioner med ESP-IDF, Espressifs enhedsside-SDK, herunder tilslutning til IoT-cloudplatforme, udvikling af LED-drivere og opgradering af firmware.
Smartphone app udvikling Udvikle smartphone apps til Android og iOS systemer for at realisere brugerregistrering og login, enhedskontrol og andre funktioner.
IoT-enhedsoptimering Når den grundlæggende udvikling af IoT-enhedsfunktioner er afsluttet, kan du vende dig til optimeringsopgaver, såsom strømoptimering.
Masseproduktionstest Udfør masseproduktionstest i henhold til relaterede standarder, såsom udstyrsfunktionstest, ældningstest, RF-test osv.
På trods af ovenstående trin er et Smart Light-projekt ikke nødvendigvis underlagt en sådan procedure, da forskellige opgaver også kan udføres på samme tid. F.eksample, indlejret software og smartphone-apps kan udvikles parallelt. Nogle trin skal muligvis også gentages, såsom IoT-enhedsoptimering og masseproduktionstest.
16 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

2.3 Sammenfatning
I dette kapitel redegjorde vi først for de grundlæggende komponenter og funktionelle moduler i et IoT-projekt, og introducerede derefter Smart Light-casen til praksis, med henvisning til dens struktur, funktioner, hardwareforberedelse og udviklingsproces. Læsere kan drage slutninger fra praksis og blive sikre på at udføre IoT-projekter med et minimum af fejl i fremtiden.
Kapitel 2. Introduktion og praksis af IoT-projekter 17

18 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Kapitel 3

Indledning

til

ESP

RainMaker

Internet of Things (IoT) tilbyder uendelige muligheder for at ændre den måde, mennesker lever på, men udviklingen af IoT-teknik er fuld af udfordringer. Med offentlige skyer kan terminalproducenter implementere produktfunktionalitet gennem følgende løsninger:
Baseret på løsningsudbyderes cloud-platforme På denne måde behøver terminalproducenter kun at designe produkthardwaren, derefter forbinde hardwaren til skyen ved hjælp af det medfølgende kommunikationsmodul og konfigurere produktfunktionerne efter retningslinjerne. Dette er en effektiv tilgang, da den eliminerer behovet for udvikling på server- og applikationssiden samt drift og vedligeholdelse (O&M). Det giver terminalproducenter mulighed for at fokusere på hardwaredesign uden at skulle overveje cloudimplementering. Sådanne løsninger (f.eks. enhedsfirmware og app) er dog generelt ikke open source, så produktfunktionerne vil være begrænset af udbyderens cloud-platform, som ikke kan tilpasses. I mellemtiden tilhører bruger- og enhedsdata også cloud-platformen.
Baseret på cloud-produkter I denne løsning skal terminalproducenter efter færdiggørelse af hardwaredesignet ikke kun implementere cloud-funktioner ved hjælp af et eller flere cloud-produkter leveret af den offentlige cloud, men også at forbinde hardwaren med skyen. F.eksample, for at oprette forbindelse til Amazon Web Services (AWS), terminalproducenter skal bruge AWS-produkter såsom Amazon API Gateway, AWS IoT Core og AWS Lambda for at muliggøre enhedsadgang, fjernbetjening, datalagring, brugeradministration og andre grundlæggende funktioner. Det beder ikke kun terminalproducenter om fleksibelt at bruge og konfigurere cloud-produkter med dybdegående forståelse og rig erfaring, men det kræver også, at de overvejer konstruktions- og vedligeholdelsesomkostningerne for indledende og senere s.tagDet stiller store udfordringer for virksomhedens energi og ressourcer.
Sammenlignet med offentlige skyer er private skyer normalt bygget til specifikke projekter og produkter. Private cloud-udviklere får det højeste niveau af frihed i protokoldesign og implementering af forretningslogik. Terminalproducenter kan lave produkter og designskemaer efter behag og nemt integrere og styrke brugerdata. Kombinerer den høje sikkerhed, skalerbarhed og pålidelighed af public cloud med advantagMed privat cloud lancerede Espressif ESP
19

RainMaker, en dybt integreret privat cloud-løsning baseret på Amazon-skyen. Brugere kan implementere ESP RainMaker og bygge privat sky blot med en AWS-konto.
3.1 Hvad er ESP RainMaker?
ESP RainMaker er en komplet AIoT-platform bygget med flere modne AWS-produkter. Det giver forskellige tjenester, der kræves til masseproduktion, såsom enhedsskyadgang, enhedsopgradering, backend-administration, tredjepartslogin, stemmeintegration og brugeradministration. Ved at bruge Serverless Application Repository (SAR) leveret af AWS, kan terminalproducenter hurtigt implementere ESP RainMaker til deres AWS-konti, hvilket er tidseffektivt og nemt at betjene. Administreret og vedligeholdt af Espressif, SAR, der bruges af ESP RainMaker, hjælper udviklere med at reducere skyvedligeholdelsesomkostninger og fremskynde udviklingen af AIoT-produkter og dermed opbygge sikre, stabile og tilpasselige AIoT-løsninger. Figur 3.1 viser arkitekturen af ESP RainMaker.
Figur 3.1. Arkitektur af ESP RainMaker
Den offentlige ESP RainMaker-server fra Espressif er gratis for alle ESP-entusiaster, skabere og undervisere til løsningsevaluering. Udviklere kan logge ind med Apple-, Google- eller GitHub-konti og hurtigt bygge deres egne IoT-applikationsprototyper. Den offentlige server integrerer Alexa og Google Home og leverer stemmestyringstjenester, som understøttes af Alexa Skill og Google Actions. Dens semantiske genkendelsesfunktion er også drevet af tredjeparter. RainMaker IoT-enheder reagerer kun på specifikke handlinger. For en udtømmende liste over understøttede stemmekommandoer, tjek venligst tredjepartsplatformene. Derudover tilbyder Espressif en offentlig RainMaker-app, så brugerne kan styre produkterne via smartphones. 20 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

3.2 Implementeringen af ESP RainMaker
Som vist i figur 3.2 består ESP RainMaker af fire dele: · Kravservice, der gør det muligt for RainMaker-enheder dynamisk at opnå certifikater. · RainMaker Cloud (også kendt som cloud-backend), der leverer tjenester såsom meddelelsesfiltrering, brugeradministration, datalagring og tredjepartsintegrationer. · RainMaker Agent, der gør det muligt for RainMaker-enheder at oprette forbindelse til RainMaker Cloud. · RainMaker Client (RainMaker App eller CLI scripts), til klargøring, brugeroprettelse, enhedstilknytning og kontrol osv.
Figur 3.2. Struktur af ESP RainMaker
ESP RainMaker leverer et komplet sæt værktøjer til produktudvikling og masseproduktion, herunder: RainMaker SDK
RainMaker SDK er baseret på ESP-IDF og leverer kildekoden til agenten på enhedssiden og relaterede C API'er til firmwareudvikling. Udviklere behøver kun at skrive applikationslogikken og overlade resten til RainMaker-rammerne. For mere information om C API'er, besøg venligst https://bookc3.espressif.com/rm/c-api-reference. RainMaker App Den offentlige version af RainMaker App giver udviklere mulighed for at fuldføre enhedsforsyning og kontrollere og forespørge om enheders status (f.eks. smarte belysningsprodukter). Den er tilgængelig i både iOS- og Android-appbutikker. For flere detaljer, se venligst kapitel 10. REST API'er REST API'er hjælper brugere med at bygge deres egne applikationer, der ligner RainMaker-appen. For mere information, besøg venligst https://swaggerapis.rainmaker.espressif.com/.
Kapitel 3. Introduktion til ESP RainMaker 21

Python API'er En Python-baseret CLI, som leveres med RainMaker SDK, leveres til at implementere alle funktioner, der ligner smartphone-funktioner. For mere information om Python API'er, besøg venligst https://bookc3.espressif.com/rm/python-api-reference.
Admin CLI Admin CLI, med et højere adgangsniveau, leveres til ESP RainMaker privat implementering for at generere enhedscertifikater i bulk.
3.2.1 Reklamationsservice
Al kommunikation mellem RainMaker-enheder og cloud-backend udføres gennem MQTT+TLS. I sammenhæng med ESP RainMaker er "krav" den proces, hvor enheder får certifikater fra kravtjenesten for at oprette forbindelse til cloud-backend. Bemærk, at kravtjenesten kun gælder for den offentlige RainMaker-tjeneste, mens enhedscertifikaterne for privat implementering skal genereres i bulk gennem Admin CLI. ESP RainMaker understøtter tre typer kravservice: Self-claiming
Enheden henter selv certifikaterne gennem en hemmelig nøgle, der er forudprogrammeret i eFuse efter at have oprettet forbindelse til internettet. Værtsdrevet krav Certifikaterne fås fra udviklingsværten med RainMaker-kontoen. Assisteret krav Certifikaterne opnås via smartphone-applikationer under klargøring.
3.2.2 RainMaker Agent
Figur 3.3. Struktur af RainMaker SDK Den primære funktion af RainMaker Agent er at give forbindelse og hjælpe applikationslaget til at behandle uplink/downlink cloud-data. Den er bygget gennem RainMaker SDK 22 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT

og udviklet baseret på den gennemprøvede ESP-IDF-ramme, ved hjælp af ESP-IDF-komponenter såsom RTOS, NVS og MQTT. Figur 3.3 viser strukturen af RainMaker SDK.
RainMaker SDK indeholder to hovedfunktioner.
Forbindelse
jeg. Samarbejde med Claiming Service for at opnå enhedscertifikater.
ii. Tilslutning til cloud-backend ved hjælp af den sikre MQTT-protokol for at give fjernforbindelse og implementere fjernstyring, meddelelsesrapportering, brugeradministration, enhedsadministration osv. Den bruger som standard MQTT-komponenten i ESP-IDF og giver et abstraktionslag til grænseflader med andre protokol stakke.
iii. Leverer wifi-forsyningskomponent til Wi-Fi-forbindelse og klargøring, især https ota-komponent til OTA-opgraderinger, og især lokal ctrl-komponent til lokal enhedsopdagelse og -forbindelse. Alle disse mål kan opnås gennem simpel konfiguration.
Databehandling
jeg. Lagring af enhedscertifikater udstedt af Claiming Service og de nødvendige data, når du kører RainMaker, som standard ved at bruge grænsefladen fra nvs flash-komponenten og levere API'er til udviklere til direkte brug.
ii. Brug af tilbagekaldsmekanismen til at behandle uplink/downlink cloud-data og automatisk fjernelse af blokering af data til applikationslaget for nem behandling af udviklere. F.eksampRainMaker SDK giver rige grænseflader til etablering af TSL-data (Thing Specification Language), som er nødvendige for at definere TSL-modeller til at beskrive IoT-enheder og implementere funktioner såsom timing, nedtælling og stemmestyring. For grundlæggende interaktive funktioner såsom timing, tilbyder RainMaker SDK en udviklingsfri løsning, som ganske enkelt kan aktiveres, når det er nødvendigt. Derefter vil RainMaker-agenten behandle dataene direkte, sende dem til skyen gennem det tilknyttede MQTT-emne og tilbageføre dataændringerne i skyens backend gennem tilbagekaldsmekanisme.
3.2.3 Cloud Backend
Cloud-backend er bygget på AWS Serverless Computing og opnået gennem AWS Cognito (identitetsstyringssystem), Amazon API Gateway, AWS Lambda (serverløs computertjeneste), Amazon DynamoDB (NoSQL-database), AWS IoT Core (IoT-adgangskerne, der giver MQTT-adgang og regelfiltrering), Amazon Simple Email Service (SES simple mail service), Amazon CloudFront (hurtigt leveringsnetværk), Amazon Simple Queue Service (SQS message queuing) og Amazon S3 (bucket storage service). Det har til formål at optimere skalerbarhed og sikkerhed. Med ESP RainMaker kan udviklere administrere enheder uden at skulle skrive kode i skyen. Meddelelser, der rapporteres af enheder, transmitteres gennemsigtigt til
Kapitel 3. Introduktion til ESP RainMaker 23

applikationsklienter eller andre tredjepartstjenester. Tabel 3.1 viser AWS cloud-produkter og -funktioner, der bruges i cloud-backend, med flere produkter og funktioner under udvikling.
Tabel 3.1. AWS cloud-produkter og -funktioner, der bruges af cloud-backend

AWS Cloud-produkt brugt af RainMaker

Fungere

AWS Cognito

Håndtering af brugerlegitimationsoplysninger og understøttelse af tredjepartslogins

AWS Lambda

Implementering af kerneforretningslogikken i cloud-backend

Amazon Timestream Lagring af tidsseriedata

Amazon DynamoDB Lagring af kunders private oplysninger

AWS IoT Core

Understøtter MQTT-kommunikation

Amazon SES

Levering af e-mail-afsendelsestjenester

Amazon CloudFront Fremskynder administrationen af backend webadgang til webstedet

Amazon SQS

Videresendelse af beskeder fra AWS IoT Core

3.2.4 RainMaker Client
RainMaker-klienter, såsom App og CLI, kommunikerer med cloud-backend gennem REST API'er. Detaljerede oplysninger og instruktioner om REST API'er kan findes i Swagger-dokumentationen leveret af Espressif. RainMakers mobilapplikationsklient er tilgængelig til både iOS- og Android-systemer. Det giver mulighed for klargøring, kontrol og deling af enheder, såvel som at oprette og aktivere nedtællingsopgaver og oprette forbindelse til tredjepartsplatforme. Den kan automatisk indlæse UI og ikoner i henhold til konfigurationen rapporteret af enhederne og fuldt ud vise enhedens TSL.
F.eksample, hvis der er bygget et smart lys på den RainMaker SDK-leverede examples, vil ikonet og brugergrænsefladen for pærelyset blive indlæst automatisk, når klargøringen er fuldført. Brugere kan ændre lysets farve og lysstyrke gennem grænsefladen og opnå tredjepartskontrol ved at linke Alexa Smart Home Skill eller Google Smart Home Actions til deres ESP RainMaker-konti. Figur 3.4 viser ikonet og brugergrænsefladen f.eksamples af pærens lys på henholdsvis Alexa, Google Home og ESP RainMaker App.

24 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

(a) Eksample – Alexa

(b) Eksample – Google Home

(c) Eksample – ESP RainMaker
Figur 3.4. Eksamples af ikon og brugergrænseflade for pærelyset på Alexa, Google Home og ESP RainMaker App
3.3 Praksis: Nøglepunkter for udvikling med ESP RainMaker
Når enhedsdriverlaget er afsluttet, kan udviklere begynde at skabe TSL-modeller og behandle downlink-data ved hjælp af API'erne leveret af RainMaker SDK og aktivere ESP RainMaker-basistjenesterne baseret på produktdefinitionen og kravene.
Kapitel 3. Introduktion til ESP RainMaker 25

Afsnit 9.4 i denne bog vil forklare implementeringen af LED-smart lys i RainMaker. Under debugging kan udviklere bruge CLI-værktøjerne i RainMaker SDK til at kommunikere med det smarte lys (eller kalde REST API'er fra Swagger).
Kapitel 10 vil uddybe brugen af REST API'er til udvikling af smartphone-applikationer. OTA-opgraderingerne af LED-smartlys vil blive dækket i kapitel 11. Hvis udviklere har aktiveret ESP Insights fjernovervågning, vil ESP RainMaker-administrationsbackend vise ESP Insights-dataene. Detaljer vil blive præsenteret i kapitel 15.
ESP RainMaker understøtter privat implementering, som adskiller sig fra den offentlige RainMaker-server på følgende måder:
Kravtjeneste For at generere certifikater i private implementeringer er det påkrævet at bruge RainMaker Admin CLI i stedet for at gøre krav. Med offentlig server skal udviklere have administratorrettigheder til at implementere firmwareopgradering, men det er uønsket i kommercielle udrulninger. Derfor kan der hverken stilles særskilt godkendelsestjeneste til rådighed for selvkrav, eller administratorrettigheder for værtsdrevet eller assisteret krav.
Telefonapps I private implementeringer skal applikationer konfigureres og kompileres separat for at sikre, at kontosystemerne ikke er interoperable.
Tredjeparts logins og stemmeintegration Udviklere skal konfigurere separat via Google- og Apple-udviklerkonti for at aktivere tredjepartslogin samt integrationen med Alexa Skill og Google Voice Assistant.
TIPS For detaljer om cloud-implementering, besøg venligst https://customer.rainmaker.espressif. com. Med hensyn til firmware kræver migrering fra offentlig server til privat server kun udskiftning af enhedscertifikater, hvilket i høj grad forbedrer migreringseffektiviteten og reducerer omkostningerne ved migrering og sekundær debugging.
3.4 Funktioner i ESP RainMaker
ESP RainMaker-funktioner er hovedsageligt rettet mod tre aspekter - brugeradministration, slutbrugere og administratorer. Alle funktioner understøttes på både offentlige og private servere, medmindre andet er angivet.
3.4.1 Brugerstyring
Brugerstyringsfunktionerne giver slutbrugere mulighed for at registrere, logge ind, ændre adgangskoder, hente adgangskoder osv.
26 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Registrer og log ind Registrerings- og loginmetoderne understøttet af RainMaker inkluderer: · E-mail-id + Adgangskode · Telefonnummer + Adgangskode · Google-konto · Apple-konto · GitHub-konto (kun offentlig server) · Amazon-konto (kun privat server)
BEMÆRK Tilmeld dig med Google/Amazon deler brugerens e-mailadresse med RainMaker. Tilmeld dig med Apple deler en dummy-adresse, som Apple tildeler brugeren specifikt til RainMaker-tjenesten. En RainMaker-konto oprettes automatisk for brugere, der logger ind med en Google-, Apple- eller Amazon-konto for første gang.
Skift adgangskode Gælder kun for e-mail-id/telefonnummerbaserede logins. Alle andre aktive sessioner bliver logget ud, når adgangskoden er ændret. I henhold til AWS Cognito-adfærd kan de loggede sessioner forblive aktive i op til 1 time.
Hent adgangskode Gælder kun for e-mail-id/telefonnummerbaserede logins.
3.4.2 Slutbrugerfunktioner
Funktioner, der er åbne for slutbrugere, omfatter lokal og fjernstyring og overvågning, planlægning, enhedsgruppering, enhedsdeling, push-meddelelser og tredjepartsintegrationer.
Fjernstyring og overvågning · Forespørg om konfiguration, parameterværdier og forbindelsesstatus for en eller alle enheder. · Indstil parametre for enkelte eller flere enheder.
Lokal kontrol og overvågning Mobiltelefonen og enheden skal være forbundet til det samme netværk for lokal kontrol.
Planlægning · Brugere forudindstillede bestemte handlinger på et bestemt tidspunkt. · Der kræves ingen internetforbindelse til enheden, mens tidsplanen udføres. · Én gang eller gentag (ved at angive dage) for enkelte eller flere enheder.
Enhedsgruppering Understøtter abstrakt gruppering på flere niveauer. Gruppemetadata kan bruges til at skabe en Home Room-struktur.
Kapitel 3. Introduktion til ESP RainMaker 27

Deling af enhed En eller flere enheder kan deles med en eller flere brugere.
Push-beskeder Slutbrugere vil modtage push-beskeder for begivenheder såsom · Ny enhed(er) tilføjet/fjernet · Enhed tilsluttet skyen · Enhed afbrudt fra skyen · Anmodninger om enhedsdeling oprettet/accepteret/afvist · Alarmbeskeder rapporteret af enheder
Tredjepartsintegrationer Alexa og Google Voice Assistant understøttes til at styre RainMaker-enheder, inklusive lys, kontakter, stikkontakter, blæsere og temperatursensorer.
3.4.3 Adminfunktioner
Admin-funktioner giver administratorer mulighed for at implementere enhedsregistrering, enhedsgruppering og OTA-opgraderinger og til view statistik og ESP Insights-data.
Enhedsregistrering Generer enhedscertifikater og tilmeld dig med Admin CLI (kun privat server).
Enhedsgruppering Opret abstrakte eller strukturerede grupper baseret på enhedsoplysninger (kun privat server).
Over-the-Air (OTA) opgraderinger Upload firmware baseret på version og model til en eller flere enheder eller en gruppe Overvåg, annuller eller arkiver OTA-job.
View statistik Viewstatistikker inkluderer: · Enhedsregistreringer (certifikater registreret af administratoren) · Enhedsaktiveringer (enhed tilsluttet for første gang) · Brugerkonti · Bruger-enhed tilknytning
View ESP Insights data ViewESP Insights-data omfatter: · Fejl, advarsler og brugerdefinerede logfiler · Nedbrudsrapporter og analyser · Årsager til genstart · Metrik som hukommelsesforbrug, RSSI osv. · Brugerdefinerede metrics og variabler
28 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

3.5 Sammenfatning
I dette kapitel introducerede vi nogle vigtige forskelle mellem den offentlige RainMaker-implementering og den private implementering. Den private ESP RainMaker-løsning lanceret af Espressif er yderst pålidelig og kan udvides. Alle chips i ESP32-serien er blevet tilsluttet og tilpasset til AWS, hvilket i høj grad reducerer omkostningerne. Udviklere kan fokusere på prototypebekræftelse uden at skulle lære om AWS cloud-produkter. Vi forklarede også implementeringen og funktionerne i ESP RainMaker og nogle nøglepunkter for udvikling ved hjælp af platformen.
Scan for at downloade ESP RainMaker til Android Scan for at downloade ESP RainMaker til iOS
Kapitel 3. Introduktion til ESP RainMaker 29

30 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Kapitel Opsætning 4 Udviklingsmiljø
Dette kapitel fokuserer på ESP-IDF, den officielle softwareudviklingsramme for ESP32-C3. Vi vil forklare, hvordan man opsætter miljøet på forskellige operativsystemer og introducerer projektstrukturen og byggesystemet for ESP-IDF, samt brugen af relaterede udviklingsværktøjer. Derefter vil vi præsentere kompilerings- og køreprocessen for en example-projektet, samtidig med at der tilbydes en detaljeret forklaring af outputloggen ved hvert stage.
4.1 ESP-IDF Overview
ESP-IDF (Espressif IoT Development Framework) er en one-stop IoT-udviklingsramme leveret af Espressif Technology. Det bruger C/C++ som det primære udviklingssprog og understøtter krydskompilering under almindelige operativsystemer som Linux, Mac og Windows. EksampDe programmer, der er inkluderet i denne bog, er udviklet ved hjælp af ESP-IDF, som tilbyder følgende funktioner: · SoC-drivere på systemniveau. ESP-IDF inkluderer drivere til ESP32, ESP32-S2, ESP32-C3,
og andre chips. Disse drivere omfatter perifert lavniveau-bibliotek (LL), hardwareabstraktionslag-bibliotek (HAL), RTOS-understøttelse og driversoftware til øverste lag osv. · Væsentlige komponenter. ESP-IDF inkorporerer grundlæggende komponenter, der kræves til IoT-udvikling. Dette inkluderer flere netværksprotokolstakke såsom HTTP og MQTT, en strømstyringsramme med dynamisk frekvensmodulation og funktioner som Flash-kryptering og sikker opstart osv. · Udviklings- og produktionsværktøjer. ESP-IDF leverer almindeligt anvendte værktøjer til bygning, flash og fejlfinding under udvikling og masseproduktion (se figur 4.1), såsom byggesystemet baseret på CMake, krydskompileringsværktøjskæden baseret på GCC og JTAG fejlfindingsværktøj baseret på OpenOCD osv. Det er værd at bemærke, at ESP-IDF-koden primært overholder Apache 2.0 open source-licensen. Brugere kan udvikle personlig eller kommerciel software uden begrænsninger, mens de overholder vilkårene i open source-licensen. Derudover tildeles brugere permanente patentlicenser gratis, uden forpligtelse til at åbne kildekode eventuelle ændringer i kildekoden.
31

Figur 4.1.

Bygge, blinke og fejlfinde

værktøj til udvikling og masseproduktion

4.1.1 ESP-IDF-versioner
ESP-IDF-koden hostes på GitHub som et open source-projekt. I øjeblikket er der tre store versioner tilgængelige: v3, v4 og v5. Hver større version indeholder normalt forskellige underversioner, såsom v4.2, v4.3 og så videre. Espressif Systems sikrer en 30-måneders support til fejlrettelser og sikkerhedsrettelser for hver frigivet underversion. Derfor udgives der også jævnligt revisioner af subversioner, såsom v4.3.1, v4.2.2 osv. Tabel 4.1 viser supportstatus for forskellige ESP-IDF-versioner til Espressif-chips og angiver, om de er i en preview stage (tilbyder støtte til præview versioner, som muligvis mangler visse funktioner eller dokumentation) eller er officielt understøttet.

Tabel 4.1. Supportstatus for forskellige ESP-IDF-versioner til Espressif-chips

Serie ESP32 ESP32-S2 ESP32-C3 ESP32-S3 ESP32-C2 ESP32-H2

v4.1 understøttet

v4.2 understøttet

v4.3 understøttet understøttet understøttet

v4.4 understøttet understøttet understøttet understøttet
præview

v5.0 understøttet understøttet understøttet understøttet understøttet forudview

32 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Gentagelsen af større versioner involverer ofte justeringer af rammestrukturen og opdateringer af kompileringssystemet. F.eksample, den største ændring fra v3.* til v4.* var den gradvise migrering af byggesystemet fra Make til CMake. På den anden side medfører iteration af mindre versioner typisk tilføjelse af nye funktioner eller understøttelse af nye chips.
Det er vigtigt at skelne og forstå forholdet mellem stabile versioner og GitHub-grene. Versioner mærket som v*.* eller v*.*.* repræsenterer stabile versioner, der har bestået fuldstændig intern test af Espressif. Når de er rettet, forbliver koden, værktøjskæden og udgivelsesdokumenterne for den samme version uændrede. Imidlertid gennemgår GitHub-grene (f.eks. release/v4.3-grenen) hyppige kode-commits, ofte på daglig basis. Derfor kan to kodestykker under den samme gren være forskellige, hvilket gør det nødvendigt for udviklere at opdatere deres kode i overensstemmelse hermed.
4.1.2 ESP-IDF Git Workflow
Espressif følger en specifik Git-arbejdsgang for ESP-IDF, skitseret som følger:
· Der foretages nye ændringer på mastergrenen, der fungerer som hovedudviklingsgren. ESP-IDF-versionen på mastergrenen bærer altid en -dev tag for at indikere, at det i øjeblikket er under udvikling, såsom v4.3-dev. Ændringer på mastergrenen vil først blive vedrviewed og testet i Espressifs interne repository og derefter skubbet til GitHub, efter at den automatiske test er fuldført.
· Når en ny version har fuldført funktionsudvikling på master-grenen og opfyldt kriterierne for at gå ind i beta-test, overgår den til en ny gren, såsom release/v4.3. Derudover er denne nye filial tagged som en pre-release version, som v4.3-beta1. Udviklere kan henvise til GitHub-platformen for at få adgang til den komplette liste over filialer og tags for ESP-IDF. Det er vigtigt at bemærke, at betaversionen (pre-release version) stadig kan have et betydeligt antal kendte problemer. Da betaversionen gennemgår kontinuerlig testning, tilføjes fejlrettelser til både denne version og mastergrenen samtidigt. I mellemtiden kan mastergrenen allerede være begyndt at udvikle nye funktioner til den næste version. Når testen er næsten færdig, tilføjes en udgivelseskandidat (rc)-etiket til grenen, hvilket indikerer, at den er en potentiel kandidat til den officielle udgivelse, såsom v4.3-rc1. På dette stage, grenen forbliver en pre-release version.
· Hvis ingen større fejl opdages eller rapporteres, modtager pre-release-versionen i sidste ende en større version-etiket (f.eks. v5.0) eller en mindre version-etiket (f.eks. v4.3) og bliver en officiel udgivelsesversion, som er dokumenteret på siden med udgivelsesbemærkninger. Efterfølgende bliver eventuelle fejl identificeret i denne version rettet på udgivelsesgrenen. Efter manuel test er afsluttet, tildeles grenen en fejlrettelsesversionslabel (f.eks. v4.3.2), som også afspejles på siden med udgivelsesbemærkninger.
Kapitel 4. Opsætning af udviklingsmiljø 33

4.1.3 Valg af en passende version
Siden ESP-IDF officielt begyndte at understøtte ESP32-C3 fra version v4.3, og v4.4 endnu ikke er blevet officielt udgivet på tidspunktet for skrivningen af denne bog, er den version, der bruges i denne bog, v4.3.2, som er en revideret version af v4.3. Det er dog vigtigt at bemærke, at når du læser denne bog, er v4.4 eller nyere versioner muligvis allerede tilgængelige. Når du vælger en version, anbefaler vi følgende:
· For entry-level udviklere, er det tilrådeligt at vælge den stabile v4.3 version eller dens reviderede version, som stemmer overens med ex.ampversionen brugt i denne bog.
· Til masseproduktionsformål anbefales det at bruge den seneste stabile version for at drage fordel af den mest opdaterede tekniske support.
· Hvis du har til hensigt at eksperimentere med nye chips eller udforske nye produktfunktioner, så brug venligst mastergrenen. Den seneste version indeholder alle de nyeste funktioner, men husk, at der kan være kendte eller ukendte fejl til stede.
· Hvis den stabile version, der bruges, ikke indeholder de ønskede nye funktioner, og du ønsker at minimere risiciene forbundet med mastergrenen, kan du overveje at bruge den tilsvarende udgivelsesgren, såsom release/v4.4-grenen. Espressifs GitHub-lager vil først oprette release/v4.4-grenen og efterfølgende frigive den stabile v4.4-version baseret på et specifikt historisk øjebliksbillede af denne gren, efter at have gennemført al funktionsudvikling og -test.
4.1.4 Overview af ESP-IDF SDK Directory
ESP-IDF SDK består af to hovedmapper: esp-idf og .espressif. Førstnævnte indeholder ESP-IDF repositorys kildekode files og kompileringsscripts, mens sidstnævnte hovedsageligt gemmer kompileringsværktøjskæder og anden software. Kendskab til disse to mapper vil hjælpe udviklere med at udnytte de tilgængelige ressourcer bedre og fremskynde udviklingsprocessen. Katalogstrukturen for ESP-IDF er beskrevet nedenfor:
(1) ESP-IDF lagerkodemappe (/esp/esp-idf), som vist i figur 4.2.
en. Komponentkatalogkomponenter
Denne kernemappe integrerer adskillige væsentlige softwarekomponenter i ESP-IDF. Ingen projektkode kan kompileres uden at stole på komponenterne i denne mappe. Det inkluderer driverunderstøttelse til forskellige Espressif-chips. Fra LL-biblioteket og HAL-bibliotekets grænseflader til eksterne enheder til det øverste niveau Driver og Virtual File System (VFS) lagunderstøttelse, udviklere kan vælge de passende komponenter på forskellige niveauer til deres udviklingsbehov. ESP-IDF understøtter også flere standardnetværksprotokolstakke såsom TCP/IP, HTTP, MQTT, WebSocket osv. Udviklere kan bruge velkendte grænseflader som Socket til at bygge netværksapplikationer. Komponenter giver forståelse
34 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Figur 4.2. ESP-IDF depotkodemappe
sive funktionalitet og kan nemt integreres i applikationer, hvilket giver udviklere mulighed for udelukkende at fokusere på forretningslogikken. Nogle almindelige komponenter omfatter: · driver: Denne komponent indeholder perifere driverprogrammer til forskellige Espressif
chipserier, såsom GPIO, I2C, SPI, UART, LEDC (PWM) osv. De perifere driverprogrammer i denne komponent tilbyder chip-uafhængige abstrakte grænseflader. Hver perifer enhed har en fælles header file (såsom gpio.h), hvilket eliminerer behovet for at håndtere forskellige chip-specifikke supportspørgsmål. · esp_wifi: Wi-Fi, som en speciel perifer enhed, behandles som en separat komponent. Det inkluderer flere API'er, såsom initialisering af forskellige Wi-Fi-drivertilstande, parameterkonfiguration og hændelsesbehandling. Visse funktioner i denne komponent leveres i form af statiske linkbiblioteker. ESP-IDF giver også omfattende driverdokumentation for brugervenlighed.
Kapitel 4. Opsætning af udviklingsmiljø 35

· freeertos: Denne komponent indeholder den komplette FreeRTOS-kode. Udover at yde omfattende support til dette operativsystem, har Espressif også udvidet sin support til dual-core chips. For dual-core chips som ESP32 og ESP32-S3 kan brugere oprette opgaver på specifikke kerner.
b. Dokumentmappe
Denne mappe indeholder ESP-IDF-relaterede udviklingsdokumenter, herunder Kom godt i gang-vejledningen, API-referencemanualen, udviklingsvejledningen osv.
BEMÆRK Efter at være blevet kompileret af automatiserede værktøjer, implementeres indholdet af denne mappe på https://docs.espressif.com/projects/esp-idf. Sørg for at skifte dokumentmålet til ESP32-C3 og vælg den angivne ESP-IDF-version.
c. Scriptværktøjsværktøjer
Denne mappe indeholder almindeligt anvendte kompileringsfrontend-værktøjer såsom idf.py og monitorterminalværktøjet idf_monitor.py osv. Underbiblioteket cmake indeholder også kernescript files af kompileringssystemet, der tjener som grundlaget for implementering af ESP-IDF kompileringsregler. Når miljøvariablerne tilføjes, tilføjes indholdet i værktøjer-biblioteket til systemmiljøvariablen, hvilket gør det muligt at udføre idf.py direkte under projektstien.
d. Eksample programmappe examples
Denne mappe omfatter en stor samling af ESP-IDF example-programmer, der demonstrerer brugen af komponent-API'er. Eksampfiler er organiseret i forskellige undermapper baseret på deres kategorier:
· kom i gang: Denne undermappe indeholder entry-level examples som "hello world" og "blink" for at hjælpe brugerne med at forstå det grundlæggende.
· bluetooth: Du kan finde Bluetooth-relateret f.eksamples her, inklusive Bluetooth LE Mesh, Bluetooth LE HID, BluFi og mere.
· wifi: Denne undermappe fokuserer på Wi-Fi f.eksampfiler, herunder grundlæggende programmer som Wi-Fi SoftAP, Wi-Fi Station, espnow, samt proprietær kommunikationsprotokol f.eks.amples fra Espressif. Det inkluderer også flere applikationslag f.eksampfiler baseret på Wi-Fi, såsom Iperf, Sniffer og Smart Config.
· perifere enheder: Denne omfattende undermappe er yderligere opdelt i adskillige undermapper baseret på perifere navne. Den indeholder hovedsageligt perifer driver examples til Espressif chips, med hver example med flere undereksamples. For eksempel indeholder gpio-underbiblioteket to examples: GPIO og GPIO matrix tastatur. Det er vigtigt at bemærke, at ikke alle exampfilerne i denne mappe gælder for ESP32-C3.
36 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

F.eksample, exampfiler i usb/host gælder kun for perifere enheder med USB Host-hardware (såsom ESP32-S3), og ESP32-C3 har ikke denne periferiudstyr. Kompileringssystemet giver typisk prompter, når målet indstilles. README file af hver example viser de understøttede chips. · protokoller: Denne undermappe indeholder f.eksamples til forskellige kommunikationsprotokoller, inklusive MQTT, HTTP, HTTP Server, PPPoS, Modbus, mDNS, SNTP, der dækker en bred vifte af kommunikationsprotokoller f.eks.ampkræves til IoT-udvikling. · provisioning: Her finder du provisioning f.eksamples til forskellige metoder, såsom Wi-Fi-klargøring og Bluetooth LE-klargøring. · system: Denne undermappe inkluderer systemfejlfinding f.eksamples (f.eks. staksporing, runtime-sporing, opgaveovervågning), strømstyring f.eksamples (f.eks. forskellige dvaletilstande, co-processorer) og f.eksamples relateret til almindelige systemkomponenter som konsolterminal, hændelsesløkke og systemtimer. · opbevaring: I denne undermappe finder du f.eksamples af alle file systemer og lagermekanismer understøttet af ESP-IDF (såsom læsning og skrivning af Flash, SD-kort og andre lagermedier), samt f.eks.amples af ikke-flygtig lagring (NVS), FatFS, SPIFFS og andre file systemdrift. · sikkerhed: Denne undermappe indeholder f.eksamples relateret til flash-kryptering. (2) ESP-IDF kompileringsværktøjskædekatalog (/.espressif), som vist i figur 4.3.
Figur 4.3. ESP-IDF kompileringsværktøjskædekatalog
Kapitel 4. Opsætning af udviklingsmiljø 37

en. Software distribution bibliotek dist
ESP-IDF værktøjskæden og anden software distribueres i form af komprimerede pakker. Under installationsprocessen downloader installationsværktøjet først den komprimerede pakke til dist-mappen og udpakker den derefter til den angivne mappe. Når installationen er fuldført, kan indholdet i denne mappe fjernes sikkert.
b. Python virtuelle miljø bibliotek python env
Forskellige versioner af ESP-IDF er afhængige af specifikke versioner af Python-pakker. Installation af disse pakker direkte på den samme vært kan føre til konflikter mellem pakkeversioner. For at løse dette bruger ESP-IDF virtuelle Python-miljøer til at isolere forskellige pakkeversioner. Med denne mekanisme kan udviklere installere flere versioner af ESP-IDF på den samme vært og nemt skifte mellem dem ved at importere forskellige miljøvariabler.
c. ESP-IDF kompileringsværktøj kædekatalogværktøjer
Denne mappe indeholder hovedsageligt krydskompileringsværktøjer, der er nødvendige for at kompilere ESP-IDF-projekter, såsom CMake-værktøjer, Ninja-byggeværktøjer og gcc-værktøjskæden, der genererer det endelige eksekverbare program. Derudover rummer denne mappe standardbiblioteket for C/C++ sproget sammen med den tilsvarende header files. Hvis et program refererer til en systemoverskrift file like #inkluder , vil kompileringsværktøjskæden finde stdio.h file i denne mappe.
4.2 Opsætning af ESP-IDF udviklingsmiljø
ESP-IDF-udviklingsmiljøet understøtter almindelige operativsystemer såsom Windows, Linux og macOS. Dette afsnit vil introducere, hvordan man opsætter udviklingsmiljøet på hvert system. Det anbefales at udvikle ESP32-C3 på Linux-system, som vil blive introduceret i detaljer her. Mange instruktioner er anvendelige på tværs af platforme på grund af ligheden mellem udviklingsværktøjerne. Derfor anbefales det at læse indholdet af dette afsnit omhyggeligt.
BEMÆRK Du kan henvise til de online-dokumenter, der er tilgængelige på https://bookc3.espressif.com/esp32c3, som indeholder de kommandoer, der er nævnt i dette afsnit.
4.2.1 Opsætning af ESP-IDF udviklingsmiljø på Linux
GNU-udviklings- og fejlfindingsværktøjerne, der kræves til ESP-IDF-udviklingsmiljøet, er hjemmehørende i Linux-systemet. Derudover er kommandolinjeterminalen i Linux kraftfuld og brugervenlig, hvilket gør den til et ideelt valg til ESP32-C3-udvikling. Du kan
38 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

vælg din foretrukne Linux-distribution, men vi anbefaler at bruge Ubuntu eller andre Debianbaserede systemer. Dette afsnit giver vejledning om opsætning af ESP-IDF-udviklingsmiljøet på Ubuntu 20.04.
1. Installer nødvendige pakker
Åbn en ny terminal og udfør følgende kommando for at installere alle nødvendige pakker. Kommandoen vil automatisk springe pakker over, der allerede er installeret.
$ 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
TIPS Du skal bruge administratorkontoen og adgangskoden til kommandoen ovenfor. Som standard vil der ikke blive vist nogen information, når adgangskoden indtastes. Tryk blot på "Enter"-tasten for at fortsætte proceduren.
Git er et nøglekodestyringsværktøj i ESP-IDF. Efter succesfuld opsætning af udviklingsmiljøet, kan du bruge git log kommandoen til view alle kodeændringer foretaget siden oprettelsen af ESP-IDF. Derudover bruges Git også i ESP-IDF til at bekræfte versionsoplysninger, som er nødvendige for at installere den korrekte værktøjskæde svarende til specifikke versioner. Sammen med Git inkluderer andre vigtige systemværktøjer Python. ESP-IDF inkorporerer adskillige automatiseringsscripts skrevet i Python. Værktøjer som CMake, Ninja-build og Ccache er meget brugt i C/C++-projekter og fungerer som standardkodekompilerings- og byggeværktøjer i ESP-IDF. libusb-1.0-0 og dfu-util er de vigtigste drivere, der bruges til USB-seriel kommunikation og firmwarebrænding. Når softwarepakkerne er installeret, kan du bruge apt show kommando for at få detaljerede beskrivelser af hver pakke. F.eksample, brug apt show git til at udskrive beskrivelsesoplysningerne for Git-værktøjet.
Q: Hvad skal man gøre, hvis Python-versionen ikke understøttes? A: ESP-IDF v4.3 kræver en Python-version, der ikke er lavere end v3.6. For ældre versioner af Ubuntu skal du manuelt downloade og installere en højere version af Python og indstille Python3 som standard Python-miljø. Du kan finde detaljerede instruktioner ved at søge efter søgeordet update-alternatives python.
2. Download ESP-IDF repository kode
Åbn en terminal og opret en mappe med navnet esp i din hjemmemappe ved hjælp af mkdir-kommandoen. Du kan vælge et andet navn til mappen, hvis du foretrækker det. Brug cd-kommandoen til at gå ind i mappen.
Kapitel 4. Opsætning af udviklingsmiljø 39

$ mkdir -p /esp $ cd /esp
Brug git clone-kommandoen til at downloade ESP-IDF-depotkoden, som vist nedenfor:
$ git clone -b v4.3.2 –rekursiv https://github.com/espressif/esp-idf.git
I kommandoen ovenfor angiver parameteren -b v4.3.2 den version, der skal downloades (i dette tilfælde version 4.3.2). Parameteren –rekursiv sikrer, at alle underlagre af ESP-IDF downloades rekursivt. Information om sub-repositories kan findes i .gitmodules file.
3. Installer ESP-IDF udviklingsværktøjskæden
Espressif leverer et automatiseret script install.sh til at downloade og installere værktøjskæden. Dette script kontrollerer den aktuelle ESP-IDF-version og operativsystemmiljø og downloader og installerer derefter passende version af Python-værktøjspakker og kompileringsværktøjskæder. Standardinstallationsstien for værktøjskæden er /.espressif. Alt du skal gøre er at navigere til mappen esp-idf og køre install.sh.
$ cd /esp/esp-idf $ ./install.sh
Hvis du installerer værktøjskæden med succes, viser terminalen:
Alt færdigt!
På dette tidspunkt har du opsat ESP-IDF udviklingsmiljøet.
4.2.2 Opsætning af ESP-IDF udviklingsmiljø på Windows
1. Download installationsprogrammet til ESP-IDF værktøjer
TIPS Det anbefales at konfigurere ESP-IDF-udviklingsmiljøet på Windows 10 eller nyere. Du kan downloade installationsprogrammet fra https://dl.espressif.com/dl/esp-idf/. Installationsprogrammet er også en open source-software, og dets kildekode kan være viewed på https: //github.com/espressif/idf-installer.
· Online ESP-IDF værktøjer installer
Dette installationsprogram er relativt lille, omkring 4 MB i størrelse, og andre pakker og kode vil blive downloadet under installationsprocessen. AdvanentagE af online-installationsprogrammet er, at softwarepakker og kode ikke kun kan downloades efter behov under installationsprocessen, men også tillader installation af alle tilgængelige udgivelser af ESP-IDF og den seneste gren af GitHub-kode (såsom mastergrenen) . Ulempentage er, at det kræver en netværksforbindelse under installationsprocessen, hvilket kan forårsage installationsfejl på grund af netværksproblemer.
40 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

· Offline ESP-IDF-værktøjsinstallationsprogram Dette installationsprogram er større, omkring 1 GB i størrelse og indeholder alle de softwarepakker og kode, der kræves til miljøopsætning. Den vigtigste advantagE af offline-installationsprogrammet er, at det kan bruges på computere uden internetadgang og generelt har en højere succesrate for installationen. Det skal bemærkes, at offlineinstallationsprogrammet kun kan installere stabile udgivelser af ESP-IDF identificeret med v*.* eller v*.*.*.
2. Kør installationsprogrammet til ESP-IDF Tools Efter at have downloadet en passende version af installationsprogrammet (tag ESP-IDF Tools Offline 4.3.2 f.eks.ampher), dobbeltklik på exe file for at starte ESP-IDF installationsgrænsefladen. Det følgende viser, hvordan man installerer ESP-IDF stabil version v4.3.2 ved hjælp af offlineinstallationsprogrammet.
(1) I "Vælg installationssprog"-grænsefladen vist i figur 4.4 skal du vælge det sprog, der skal bruges, fra rullelisten.
Figur 4.4. "Vælg installationssprog"-grænseflade (2) Når du har valgt sproget, skal du klikke på "OK" for at åbne grænsefladen "Licensaftale"
(se figur 4.5). Efter omhyggeligt at have læst installationslicensaftalen, vælg "Jeg accepterer aftalen" og klik på "Næste".
Figur 4.5. "Licensaftale"-grænseflade Kapitel 4. Opsætning af udviklingsmiljø 41

(3) Vedrview systemkonfigurationen i grænsefladen "Pre-installation system check" (se figur 4.6). Kontroller Windows-versionen og oplysningerne om den installerede antivirussoftware. Klik på "Næste", hvis alle konfigurationselementer er normale. Ellers kan du klikke på "Fuld log" for løsninger baseret på nøglepunkter.
Figur 4.6. "System check før installation" interface TIPS
Du kan indsende logfiler til https://github.com/espressif/idf-installer/issues for at få hjælp. (4) Vælg ESP-IDF installationsmappe. Vælg her D:/.espressif, som vist i
Figur 4.7, og klik på "Næste". Bemærk venligst, at .espressif her er en skjult mappe. Efter installationen er fuldført, kan du view det specifikke indhold af denne mappe ved at åbne file manager og visning af skjulte elementer.
Figur 4.7. Vælg ESP-IDF installationsmappe 42 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT

(5) Kontroller de komponenter, der skal installeres, som vist i figur 4.8. Det anbefales at bruge standardindstillingen, det vil sige fuldfør installationen, og klik derefter på "Næste".
Figur 4.8. Vælg de komponenter, der skal installeres (6) Bekræft de komponenter, der skal installeres, og klik på "Installer" for at starte den automatiske in-
stallationsproces, som vist i figur 4.9. Installationsprocessen kan vare ti minutter, og statuslinjen for installationsprocessen er vist i figur 4.10. Vent venligst tålmodigt.
Figur 4.9. Forberedelse til installation (7) Når installationen er fuldført, anbefales det at kontrollere “Registrer ESP-IDF
Eksekverbare værktøjer som Windows Defender-ekskluderinger..." for at forhindre antivirussoftware i at slette files. Tilføjelse af ekskluderingselementer kan også springe over hyppige scanninger med antivirus
Kapitel 4. Opsætning af udviklingsmiljø 43

Figur 4.10. Installationsfremskridtslinjesoftware, der i høj grad forbedrer kodekompileringseffektiviteten i Windows-systemet. Klik på "Udfør" for at fuldføre installationen af udviklingsmiljøet, som vist i figur 4.11. Du kan vælge at markere "Kør ESP-IDF PowerShell-miljø" eller "Kør ESP-IDF kommandoprompt". Kør kompileringsvinduet direkte efter installationen for at sikre, at udviklingsmiljøet fungerer normalt.
Figur 4.11. Installation afsluttet (8) Åbn det installerede udviklingsmiljø i programlisten (enten ESP-IDF 4.3
CMD eller ESP-IDF 4.3 PowerShell-terminal, som vist i figur 4.12), og ESP-IDF-miljøvariablen tilføjes automatisk, når den kører i terminalen. Derefter kan du bruge kommandoen idf.py til operationer. Den åbnede ESP-IDF 4.3 CMD er vist i figur 4.13. 44 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Figur 4.12. Udviklingsmiljø installeret
Figur 4.13. ESP-IDF 4.3 CMD
4.2.3 Opsætning af ESP-IDF udviklingsmiljø på Mac
Processen med at installere ESP-IDF-udviklingsmiljøet på et Mac-system er den samme som på et Linux-system. Kommandoerne til at downloade arkivkoden og installere værktøjskæden er nøjagtig de samme. Kun kommandoerne til installation af afhængighedspakker er lidt anderledes. 1. Installer afhængighedspakker Åbn en terminal, og installer pip, Python-pakkehåndteringsværktøjet, ved at køre følgende kommando:
% sudo nem installation pip
Installer Homebrew, et pakkehåndteringsværktøj til macOS, ved at køre følgende kommando:
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/ HEAD/install.sh)"
Installer de nødvendige afhængighedspakker ved at køre følgende kommando:
% bryg python3 installer cmake ninja ccache dfu-util
2. Download ESP-IDF-lagerkode Følg instruktionerne i afsnit 4.2.1 for at downloade ESP-IDF-lagerkoden. Trinene er de samme som for download på et Linux-system.
Kapitel 4. Opsætning af udviklingsmiljø 45

3. Installer ESP-IDF udviklingsværktøjskæden
Følg instruktionerne i afsnit 4.2.1 for at installere ESP-IDF udviklingsværktøjskæden. Trinene er de samme som for installation på et Linux-system.
4.2.4 Installation af VS-kode
Som standard inkluderer ESP-IDF SDK ikke et koderedigeringsværktøj (selvom det seneste ESP-IDF installationsprogram til Windows giver mulighed for at installere ESP-IDF Eclipse). Du kan bruge et hvilket som helst tekstredigeringsværktøj efter eget valg til at redigere koden og derefter kompilere den ved hjælp af terminalkommandoer.
Et populært koderedigeringsværktøj er VS Code (Visual Studio Code), som er en gratis og funktionsrig kodeeditor med en brugervenlig grænseflade. Det tilbyder forskellige plugins der giver funktionaliteter såsom kodenavigation, syntaksfremhævning, Git-versionskontrol og terminalintegration. Derudover har Espressif udviklet et dedikeret plugin kaldet Espressif IDF til VS Code, som forenkler projektkonfiguration og fejlfinding.
Du kan bruge kodekommandoen i terminalen til hurtigt at åbne den aktuelle mappe i VS Code. Alternativt kan du bruge genvejen Ctrl+ til at åbne systemets standardterminalkonsol i VS Code.
TIPS Det anbefales at bruge VS-kode til udvikling af ESP32-C3-kode. Download og installer den seneste version af VS Code på https://code.visualstudio.com/.
4.2.5 Introduktion til tredjepartsudviklingsmiljøer
Udover det officielle ESP-IDF udviklingsmiljø, som primært bruger C-sproget, understøtter ESP32-C3 også andre almindelige programmeringssprog og en lang række tredjepartsudviklingsmiljøer. Nogle bemærkelsesværdige muligheder inkluderer:
Arduino: en open source platform til både hardware og software, der understøtter forskellige mikrocontrollere, herunder ESP32-C3.
Det bruger C++-sproget og tilbyder en forenklet og standardiseret API, almindeligvis omtalt som Arduino-sproget. Arduino er meget brugt i prototypeudvikling og uddannelsesmæssige sammenhænge. Det giver en udvidelsesbar softwarepakke og en IDE, der giver mulighed for nem kompilering og flashing.
MicroPython: en Python 3-sprogsfortolker designet til at køre på indlejrede mikrocontrollerplatforme.
Med et simpelt scriptsprog kan den få direkte adgang til ESP32-C3s perifere ressourcer (såsom UART, SPI og I2C) og kommunikationsfunktioner (såsom Wi-Fi og Bluetooth LE).
46 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

Dette forenkler hardwareinteraktion. MicroPython, kombineret med Pythons omfattende matematiske operationsbibliotek, muliggør implementering af komplekse algoritmer på ESP32-C3, hvilket letter udviklingen af AI-relaterede applikationer. Som scriptsprog er der ikke behov for gentagen kompilering; ændringer kan foretages, og scripts kan udføres direkte.
NodeMCU: en LUA-sprogfortolker udviklet til ESP-seriechips.
Den understøtter næsten alle perifere funktioner i ESP-chips og er lettere end MicroPython. I lighed med MicroPython bruger NodeMCU et scriptsprog, hvilket eliminerer behovet for gentagen kompilering.
Ydermere understøtter ESP32-C3 også NuttX- og Zephyr-operativsystemerne. NuttX er et realtidsoperativsystem, der giver POSIX-kompatible grænseflader, hvilket forbedrer applikationsportabilitet. Zephyr er et lille realtidsoperativsystem specielt designet til IoT-applikationer. Det omfatter adskillige softwarebiblioteker, der kræves i IoT-udvikling, og udvikler sig gradvist til et omfattende softwareøkosystem.
Denne bog giver ikke detaljerede installationsinstruktioner til de førnævnte udviklingsmiljøer. Du kan installere et udviklingsmiljø baseret på dine krav ved at følge den respektive dokumentation og instruktioner.
4.3 ESP-IDF kompileringssystem
4.3.1 Grundlæggende begreber for kompileringssystem
Et ESP-IDF-projekt er en samling af et hovedprogram med en indgangsfunktion og flere uafhængige funktionelle komponenter. F.eksample, et projekt, der styrer LED-switche, består hovedsageligt af en hovedindgangsprogram og en driverkomponent, der styrer GPIO. Hvis du vil realisere LED-fjernbetjeningen, skal du også tilføje Wi-Fi, TCP/IP-protokolstak osv.
Kompileringssystemet kan kompilere, linke og generere eksekverbare filer files (.bin) for koden gennem et sæt byggeregler. Kompileringssystemet for ESP-IDF v4.0 og nyere versioner er baseret på CMake som standard, og kompileringsscriptet CMakeLists.txt kan bruges til at styre kodens kompileringsadfærd. Ud over at understøtte den grundlæggende syntaks for CMake, definerer ESP-IDF kompileringssystemet også et sæt standard kompileringsregler og CMake funktioner, og du kan skrive kompileringsscriptet med simple sætninger.
4.3.2 Projekt File Struktur
Et projekt er en mappe, der indeholder en hovedindgangsprogram, brugerdefinerede komponenter og files påkrævet for at bygge eksekverbare applikationer, såsom kompileringsscripts, konfiguration
Kapitel 4. Opsætning af udviklingsmiljø 47

files, partitionstabeller osv. Projekter kan kopieres og videregives, og det samme eksekverbare file kan kompileres og genereres i maskiner med samme version af ESP-IDF udviklingsmiljø. Et typisk ESP-IDF projekt file struktur er vist i figur 4.14.
Figur 4.14. Typisk ESP-IDF projekt file struktur Da ESP-IDF understøtter flere IoT-chips fra Espressif, inklusive ESP32, ESP32-S-serien, ESP32-C-serien, ESP32-H-serien osv., skal et mål bestemmes, før koden kompileres. Målet er både den hardwareenhed, der kører applikationsprogrammet, og opbygningsmålet for kompileringssystemet. Afhængigt af dine behov kan du angive et eller flere mål for dit projekt. F.eksample, gennem kommandoen idf.py set-target esp32c3, kan du indstille kompileringsmålet til ESP32-C3, hvor standardparametrene og kompileringsværktøjets kædesti for ESP32C3 vil blive indlæst. Efter kompilering kan der genereres et eksekverbart program til ESP32C3. Du kan også køre kommandoen set-target igen for at indstille et andet mål, og kompileringssystemet vil automatisk rydde op og omkonfigurere. Komponenter
Komponenter i ESP-IDF er modulære og uafhængige kodeenheder, der administreres i kompileringssystemet. De er organiseret som mapper, hvor mappenavnet repræsenterer komponentnavnet som standard. Hver komponent har sit eget kompileringsscript, der 48 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT

specificerer dets kompileringsparametre og afhængigheder. Under kompileringsprocessen kompileres komponenter i separate statiske biblioteker (.a files) og til sidst kombineret med andre komponenter for at danne applikationsprogrammet.
ESP-IDF leverer væsentlige funktioner, såsom operativsystemet, perifere drivere og netværksprotokolstak, i form af komponenter. Disse komponenter er gemt i komponentbiblioteket i ESP-IDF-rodmappen. Udviklere behøver ikke at kopiere disse komponenter til komponentbiblioteket i myProject. I stedet behøver de kun at specificere afhængighedsrelationerne for disse komponenter i projektets CMakeLists.txt file ved at bruge REQUIRES- eller PRIV_REQUIRES-direktiverne. Kompileringssystemet vil automatisk lokalisere og kompilere de nødvendige komponenter.
Derfor er komponentbiblioteket under myProject ikke nødvendigt. Det bruges kun til at inkludere nogle brugerdefinerede komponenter i projektet, som kan være tredjepartsbiblioteker eller brugerdefineret kode. Derudover kan komponenter hentes fra enhver anden mappe end ESP-IDF eller det aktuelle projekt, såsom fra et open source-projekt, der er gemt i en anden mappe. I dette tilfælde behøver du kun at tilføje stien til komponenten ved at indstille variablen EXTRA_COMPONENT_DIRS i CMakeLists.txt under rodmappen. Denne mappe vil tilsidesætte enhver ESP-IDF-komponent med samme navn, hvilket sikrer, at den korrekte komponent bruges.
Entry program main Hovedkataloget i projektet følger samme file struktur som andre komponenter (f.eks. komponent1). Det har dog en særlig betydning, da det er en obligatorisk komponent, der skal eksistere i ethvert projekt. Hovedbiblioteket indeholder projektets kildekode og brugerprogrammets indgangspunkt, typisk kaldet app_main. Som standard starter udførelsen af brugerprogrammet fra dette indgangspunkt. Hovedkomponenten adskiller sig også ved, at den automatisk afhænger af alle komponenter inden for søgestien. Derfor er der ikke behov for eksplicit at angive afhængigheder ved hjælp af REQUIRES- eller PRIV_REQUIRES-direktiverne i CMakeLists.txt file.
Konfiguration file Projektets rodbibliotek indeholder en konfiguration file kaldet sdkconfig, som indeholder konfigurationsparametrene for alle komponenterne i projektet. sdkconfig file genereres automatisk af kompileringssystemet og kan ændres og regenereres med kommandoen idf.py menuconfig. Menuconfig-indstillingerne stammer hovedsageligt fra projektets Kconfig.projbuild og komponenternes Kconfig. Komponentudviklere tilføjer generelt konfigurationselementer i Kconfig for at gøre komponenten fleksibel og konfigurerbar.
Byg bibliotek Som standard gemmer build-mappen i projektet mellemliggende files og fi-
Kapitel 4. Opsætning af udviklingsmiljø 49

Nal eksekverbare programmer genereret af idf.py build-kommandoen. Generelt er det ikke nødvendigt at få direkte adgang til indholdet af build-mappen. ESP-IDF giver foruddefinerede kommandoer til at interagere med mappen, såsom at bruge flash-kommandoen idf.py til automatisk at finde den kompilerede binære file og flash det til den angivne flash-adresse, eller brug kommandoen idf.py fullclean til at rense hele build-mappen.
Partitionstabel (partitions.csv) Hvert projekt kræver en partitionstabel for at opdele flashrummet og specificere størrelsen og startadressen for det eksekverbare program og brugerdatarummet. Kommando idf.py flash eller OTA-opgraderingsprogram vil flashe firmwaren til den tilsvarende adresse i henhold til denne tabel. ESP-IDF giver flere standard partitionstabeller i komponenter/partition_table, såsom partitions_singleapp.csv og partitions_two_ ota.csv, som kan vælges i menuconfig.
Hvis systemets standardpartitionstabel ikke kan opfylde kravene til projektet, kan en brugerdefineret partitions.csv tilføjes til projektbiblioteket og vælges i menuconfig.
4.3.3 Standard opbygningsregler for kompileringssystemet
Regler for tilsidesættelse af komponenter med samme navn Under komponentsøgningsprocessen følger kompileringssystemet en bestemt rækkefølge. Den søger først efter interne komponenter i ESP-IDF, søger derefter efter komponenter i brugerprojektet og søger til sidst efter komponenter i EXTRA_COMPONENT_DIRS. I tilfælde, hvor flere mapper indeholder komponenter med samme navn, vil den komponent, der findes i den sidste mappe, tilsidesætte alle tidligere komponenter med samme navn. Denne regel giver mulighed for tilpasning af ESP-IDF-komponenter i brugerprojektet, mens den originale ESP-IDF-kode bevares intakt.
Regler for at inkludere almindelige komponenter som standard Som nævnt i afsnit 4.3.2 skal komponenter eksplicit specificere deres afhængigheder af andre komponenter i CMakeLists.txt. Almindelige komponenter såsom freeertos er dog automatisk inkluderet i byggesystemet som standard, selvom deres afhængighedsforhold ikke er eksplicit defineret i kompileringsscriptet. ESP-IDF fælles komponenter inkluderer freeertos, Newlib, heap, log, soc, esp_rom, esp_common, xtensa/riscv og cxx. Brug af disse almindelige komponenter undgår gentagende arbejde, når du skriver CMakeLists.txt og gør det mere kortfattet.
Regler for tilsidesættelse af konfigurationselementer Udviklere kan tilføje standardkonfigurationsparametre ved at tilføje en standardkonfiguration file navngivet sdkconfig.defaults til projektet. F.eksample, tilføjer CONFIG_LOG_
50 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

DEFAULT_LEVEL_NONE = y kan konfigurere UART-grænsefladen til ikke at udskrive logdata som standard. Desuden, hvis specifikke parametre skal indstilles for et bestemt mål, en konfiguration file navngivet sdkconfig.defaults.TARGET_NAME kan tilføjes, hvor TARGET_NAME kan være esp32s2, esp32c3, og så videre. Disse konfigurationer files importeres til sdkconfig under kompilering med den generelle standardkonfiguration file sdkconfig.defaults importeres først, efterfulgt af den målspecifikke konfiguration file, såsom sdkconfig.defaults.esp32c3. I tilfælde, hvor der er konfigurationselementer med samme navn, sidstnævnte konfiguration file vil tilsidesætte førstnævnte.
4.3.4 Introduktion til kompileringsscriptet
Når man udvikler et projekt ved hjælp af ESP-IDF, skal udviklere ikke kun skrive kildekode, men også skrive CMakeLists.txt til projektet og komponenterne. CMakeLists.txt er en tekst file, også kendt som et kompileringsscript, som definerer en række kompileringsobjekter, kompileringskonfigurationselementer og kommandoer til at guide kompileringsprocessen af kildekoden. Kompileringssystemet for ESP-IDF v4.3.2 er baseret på CMake. Ud over at understøtte native CMake-funktioner og -kommandoer, definerer den også en række brugerdefinerede funktioner, hvilket gør det meget nemmere at skrive kompileringsscripts.
Kompileringsscripterne i ESP-IDF omfatter hovedsageligt projektkompileringsscriptet og komponentkompileringsscripts. CMakeLists.txt i projektets rodbibliotek kaldes projektkompileringsscriptet, som guider kompileringsprocessen for hele projektet. Et grundlæggende projektkompileringsscript indeholder typisk følgende tre linjer:
1. cmake_minimum_required(VERSION 3.5) 2. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 3. project(mitprojekt)
Blandt dem skal cmake_minimum_required (VERSION 3.5) placeres på den første linje, som bruges til at angive det minimum CMake-versionsnummer, der kræves af projektet. Nyere versioner af CMake er generelt bagudkompatible med ældre versioner, så juster versionsnummeret i overensstemmelse hermed, når du bruger nyere CMake-kommandoer for at sikre kompatibilitet.
include($ENV {IDF_PATH}/tools/cmake/project.cmake) importerer foruddefinerede konfigurationselementer og kommandoer af ESP-IDF kompileringssystem, inklusive standard build-reglerne for kompileringssystemet beskrevet i afsnit 4.3.3. project(myProject) opretter selve projektet og angiver dets navn. Dette navn vil blive brugt som det endelige output binære file navn, dvs. myProject.elf og myProject.bin.
Et projekt kan have flere komponenter, inklusive hovedkomponenten. Mappen på øverste niveau for hver komponent indeholder en CMakeLists.txt file, som kaldes komponentkompileringsscriptet. Komponentkompileringsscripts bruges hovedsageligt til at specificere komponentafhængigheder, konfigurationsparametre, kildekode files, og inkluderet overskrift files for
Kapitel 4. Opsætning af udviklingsmiljø 51

samling. Med ESP-IDFs brugerdefinerede funktion idf_component_register er den mindst nødvendige kode for et komponentkompileringsscript som følger:

1. idf_component_register(SRCS "src1.c"

INCLUDE_DIRS "inkluder"

KRÆVER komponent1)

SRCS-parameteren giver en liste over kilder files i komponenten, adskilt af mellemrum, hvis der er flere files. INCLUDE_DIRS-parameteren giver en liste over offentlige overskrifter file mapper for komponenten, som vil blive tilføjet til include-søgestien for andre komponenter, der afhænger af den aktuelle komponent. Parameteren REQUIRES identificerer de offentlige komponentafhængigheder for den aktuelle komponent. Det er nødvendigt for komponenter eksplicit at angive, hvilke komponenter de er afhængige af, såsom komponent2 afhængig af komponent1. For hovedkomponenten, som som standard afhænger af alle komponenter, kan parameteren REQUIRES dog udelades.

Derudover kan native CMake-kommandoer også bruges i kompileringsscriptet. F.eksample, brug kommandosættet til at indstille variabler, såsom set(VARIABLE "VALUE").

4.3.5 Introduktion til almindelige kommandoer
ESP-IDF bruger CMake (projektkonfigurationsværktøj), Ninja (projektopbygningsværktøj) og esptool (flashværktøj) i processen med kodekompilering. Hvert værktøj spiller en anden rolle i kompilering, opbygning og flash-processen og understøtter også forskellige betjeningskommandoer. For at lette brugerbetjeningen tilføjer ESP-IDF en samlet front-end idf.py, der gør det muligt at kalde ovenstående kommandoer hurtigt.
Før du bruger idf.py, skal du sørge for at:
· Miljøvariablen IDF_PATH for ESP-IDF er blevet tilføjet til den aktuelle terminal. · Mappen til udførelse af kommandoen er rodmappen for projektet, som inkluderer
projekt kompileringsscript CMakeLists.txt.
De almindelige kommandoer i idf.py er som følger:
· idf.py –help: viser en liste over kommandoer og deres brugsinstruktioner. · idf.py sæt-mål : indstilling af kompileringen taidf.py fullcleanrget, f.eks
som erstatning med esp32c3. · idf.py menuconfig: lancering af menuconfig, en terminal grafisk konfiguration
værktøj, som kan vælge eller ændre konfigurationsmuligheder, og konfigurationsresultaterne gemmes i sdkconfig file. · idf.py build: initierer kodekompilering. Det mellemliggende files og det endelige eksekverbare program, der er genereret af kompileringen, gemmes som standard i projektets build-mappe. Kompileringsprocessen er inkrementel, hvilket betyder, at hvis kun én kilde file er ændret, kun det ændrede file vil blive udarbejdet næste gang.

52 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

· idf.py clean: rengøring af mellemproduktet files genereret af projektkompileringen. Hele projektet vil blive tvunget til at kompilere i den næste kompilering. Bemærk, at CMake-konfigurationen og konfigurationsændringerne foretaget af menuconfig ikke vil blive slettet under oprydning.
· idf.py fullclean: sletning af hele build-mappen, inklusive alle CMake-konfigurationsoutput files. Når du bygger projektet igen, vil CMake konfigurere projektet fra bunden. Bemærk venligst, at denne kommando rekursivt sletter alle files i build-mappen, så brug den med forsigtighed og projektkonfigurationen file vil ikke blive slettet.
· idf.py flash: blinker det eksekverbare program binært file genereret af build til målet ESP32-C3. Indstillingerne -s og -b bruges til at indstille henholdsvis enhedsnavnet på den serielle port og baudhastigheden for blink. Hvis disse to muligheder ikke er specificeret, vil den serielle port automatisk blive detekteret, og standard baudraten vil blive brugt.
· idf.py-skærm: Viser den serielle port-output for målet ESP32-C3. Indstillingen -p kan bruges til at angive enhedsnavnet på den serielle port på værtssiden. Under udskrivning af seriel port skal du trykke på tastekombinationen Ctrl+] for at forlade skærmen.
Ovenstående kommandoer kan også kombineres efter behov. F.eksample, kommandoen idf.py build flash monitor vil udføre kodekompilering, flashe og åbne serielportmonitoren i rækkefølge.
Du kan besøge https://bookc3.espressif.com/build-system for at vide mere om ESP-IDF kompileringssystem.
4.4 Praksis: Kompilering af Exampprogrammet "Blink"
4.4.1 Eksample Analyse
Dette afsnit vil tage programmet Blink som et example at analysere file struktur og kodningsregler for et rigtigt projekt i detaljer. Blink-programmet implementerer LED-blinkeffekten, og projektet er placeret i mappen f.eksamples/get-started/blink, som indeholder en kilde file, konfiguration files, og flere kompileringsscripts.
Det smarte lys-projekt, der introduceres i denne bog, er baseret på dette exampprogrammet. Funktioner vil gradvist blive tilføjet i senere kapitler for endelig at fuldføre det.
Kildekode For at demonstrere hele udviklingsprocessen er Blink-programmet blevet kopieret til esp32c3-iot-projects/device firmware/1 blink.
Blink-projektets biblioteksstruktur files er vist i figur 4.15.
Blink-projektet indeholder kun én hovedmappe, som er en speciel komponent, der
Kapitel 4. Opsætning af udviklingsmiljø 53

Figur 4.15. File mappestruktur for blink-projektet

skal medtages som beskrevet i afsnit 4.3.2. Hovedbiblioteket bruges hovedsageligt til at gemme implementeringen af app_main()-funktionen, som er indgangspunktet til brugerprogrammet. Blinkprojektet inkluderer ikke komponentbiblioteket, fordi dette f.eks.ample behøver kun at bruge de komponenter, der følger med ESP-IDF og kræver ikke yderligere komponenter. CMakeLists.txt, der er inkluderet i blink-projektet, bruges til at guide kompileringsprocessen, mens Kconfig.projbuild bruges til at tilføje konfigurationselementer til dette f.eks.ampprogrammet i menuconfig. Andet unødvendigt files vil ikke påvirke kompileringen af koden, så de vil ikke blive diskuteret her. En detaljeret introduktion til blinkprojektet files er som følger.

1. /*blink.c indeholder følgende header files*/

2. #inkluder

//Standard C biblioteksoverskrift file

3. #include “freertos/freeRTOS.h” //FreeRTOS hovedoverskrift file

4. #inkluder "freertos/task.h"

//FreeRTOS Opgavehoved file

5. #include "sdkconfig.h"

//Konfigurationsoverskrift file genereret af kconfig

6. #inkluder "driver/gpio.h"

//GPIO driver header file

Kilden file blink.c indeholder en række overskrifter files svarende til funktionserklæring-

tioner. ESP-IDF følger generelt rækkefølgen med at inkludere standard biblioteksheader files, friR-

TOS-header files, førerhoved files, anden komponent header files, og projekthoved files.

Rækkefølgen i hvilken overskrift files inkluderet kan påvirke det endelige kompileringsresultat, så prøv at

følg standardreglerne. Det skal bemærkes, at sdkconfig.h genereres automatisk

af kconfig og kan kun konfigureres gennem kommandoen idf.py menuconfig.

Direkte ændring af denne overskrift file vil blive overskrevet.

1. /*Du kan vælge den GPIO, der svarer til LED'en i idf.py menuconfig, og ændringsresultatet af menuconfig er, at værdien af CONFIG_BLINK

_GPIO vil blive ændret. Du kan også ændre makrodefinitionen direkte

her, og skift CONFIG_BLINK_GPIO til en fast værdi.*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO

3. void app_main(void)

4. {

/*Konfigurer IO som GPIO-standardfunktionen, aktiver pull-up-tilstand og

deaktiver input- og outputtilstande*/

gpio_reset_pin(BLINK_GPIO);

54 ESP32-C3 Wireless Adventure: En omfattende guide til IoT

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

/*Sæt GPIO til outputtilstand*/ gpio_set_direction(BLINK_GPIO, GPIO_MODE_OUTPUT); mens(1) {
/*Udskriv log*/ printf(“Slukker LEDn”); /*Sluk LED'en (output lavt niveau)*/ gpio_set_level(BLINK_GPIO, 0); /*Delay (1000 ms)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf(“Tænder LEDn”); /*Tænd LED'en (output højt niveau)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay(1000 / portTICK_PERIOD_MS); }

App_main()-funktionen i Blink-eksample-programmet fungerer som indgangspunkt for brugerprogrammer. Det er en simpel funktion uden parametre og ingen returværdi. Denne funktion kaldes, efter at systemet har afsluttet initialiseringen, hvilket inkluderer opgaver såsom initialisering af log-serieporten, konfiguration af single/dual core og konfiguration af vagthunden.

Funktionen app_main() kører i sammenhæng med en opgave med navnet main. Stakstørrelsen og -prioriteten for denne opgave kan justeres i menuconfig Componentconfig Common ESP-relateret.

Til simple opgaver som at blinke en LED kan al den nødvendige kode implementeres direkte i app_main()-funktionen. Dette involverer typisk initialisering af GPIO'en svarende til LED'en og brug af en while(1) loop til at tænde og slukke for LED'en. Alternativt kan du bruge FreeRTOS API til at oprette en ny opgave, der håndterer LED-blinkningen. Når den nye opgave er oprettet, kan du afslutte app_main()-funktionen.

Indholdet af main/CMakeLists.txt file, som guider kompileringsprocessen for hovedkomponenten, er som følger:

1. idf_component_register(SRCS "blink.c" INCLUDE_DIRS "." )

Blandt dem kalder main/CMakeLists.txt kun én kompileringssystemfunktion, det vil sige idf_component_register. I lighed med CMakeLists.txt for de fleste andre komponenter tilføjes blink.c til SRCS og kilden files tilføjet til SRCS vil blive kompileret. Samtidig skal ".", som repræsenterer stien, hvor CMakeLists.txt er placeret, føjes til INCLUDE_DIRS som søgemapper for header files. Indholdet af CMakeLists.txt er som følger:
1. #Specificer v3.5 som den ældste CMake-version, der understøttes af det aktuelle projekt 2. #Version lavere end v3.5 skal opgraderes, før kompilering fortsætter 3. cmake_minimum_required(VERSION 3.5) 4. #Inkluder standard CMake-konfigurationen af ESP'en -IDF kompileringssystem

Kapitel 4. Opsætning af udviklingsmiljø 55

5. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 6. #Opret et projekt med navnet "blink" 7. project(mitprojekt)
Blandt dem inkluderer CMakeLists.txt i rodbiblioteket hovedsageligt $ENV{IDF_ PATH}/tools/cmake/project.cmake, som er den primære CMake-konfiguration file leveret af ESP-IDF. Det bruges til at kon

Dokumenter/ressourcer

Espressif Systems ESP32-C3 Wireless Adventure [pdfBrugervejledning
ESP32-C3 Wireless Adventure, ESP32-C3, Wireless Adventure, Adventure

Referencer

Brugermanual

ESP32-C3 trådløst eventyr

ESP32-C3 trådløst eventyr

En omfattende guide til IoT

Specifikationer

Produktbrugsvejledning

Forberedelse

Introduktion og praktisering af IoT-projekter

Praksis: Smart Light Project

Projektets struktur

Projekt funktioner

Forberedelse af hardware

Udviklingsproces

Introduktion til ESP RainMaker

Hvad er ESP RainMaker?

Implementeringen af ESP RainMaker

Praksis: Nøglepunkter for udvikling med ESP RainMaker

Funktioner i ESP RainMaker

Opsætning af udviklingsmiljø

Hardware og driverudvikling

Hardwaredesign af Smart Light-produkter baseret på ESP32-C3

Funktioner og sammensætning af Smart Light-produkter

Hardwaredesign af ESP32-C3 Core System

FAQ

Q: Hvad er ESP RainMaker?

Q: Hvordan kan jeg konfigurere udviklingsmiljøet til
ESP32-C3?

Q: Hvad er funktionerne i ESP RainMaker?

Dokumenter/ressourcer

Referencer

Efterlad en kommentar

Annuller svar

ESP32-C3 trådløst eventyr

ESP32-C3 trådløst eventyr

En omfattende guide til IoT

Specifikationer

Produktbrugsvejledning

Forberedelse

Introduktion og praktisering af IoT-projekter

Praksis: Smart Light Project

Projektets struktur

Projekt funktioner

Forberedelse af hardware

Udviklingsproces

Introduktion til ESP RainMaker

Hvad er ESP RainMaker?

Implementeringen af ​​ESP RainMaker

Praksis: Nøglepunkter for udvikling med ESP RainMaker

Funktioner i ESP RainMaker

Opsætning af udviklingsmiljø

Hardware og driverudvikling

Hardwaredesign af Smart Light-produkter baseret på ESP32-C3

Funktioner og sammensætning af Smart Light-produkter

Hardwaredesign af ESP32-C3 Core System

FAQ

Q: Hvad er ESP RainMaker?

Q: Hvordan kan jeg konfigurere udviklingsmiljøet til ESP32-C3?

Q: Hvad er funktionerne i ESP RainMaker?

Dokumenter/ressourcer

Referencer

Relaterede indlæg

Efterlad en kommentar

Annuller svar

Implementeringen af ESP RainMaker

Q: Hvordan kan jeg konfigurere udviklingsmiljøet til
ESP32-C3?