ESP32-C3 Wireless Adventure

ESP32-C3 Wireless Adventure

Isang Komprehensibong Gabay sa IoT

Mga Sistema ng Espressif Hunyo 12, 2023

Mga pagtutukoy

  • Produkto: ESP32-C3 Wireless Adventure
  • Tagagawa: Espressif Systems
  • Petsa: Hunyo 12, 2023

Mga Tagubilin sa Paggamit ng Produkto

Paghahanda

Bago gamitin ang ESP32-C3 Wireless Adventure, siguraduhing ikaw ay
pamilyar sa mga konsepto at arkitektura ng IoT. Makakatulong ito
naiintindihan mo kung paano umaangkop ang device sa mas malaking IoT ecosystem
at ang mga potensyal na aplikasyon nito sa mga smart home.

Panimula at Practice ng IoT Projects

Sa seksyong ito, matututunan mo ang tungkol sa mga tipikal na proyekto ng IoT,
kabilang ang mga pangunahing module para sa mga karaniwang IoT device, mga pangunahing module
ng mga application ng kliyente, at mga karaniwang IoT cloud platform. Ito ay
bigyan ka ng pundasyon para sa pag-unawa at paglikha ng iyong
sariling mga proyekto ng IoT.

Pagsasanay: Smart Light Project

Sa proyektong pagsasanay na ito, matututunan mo kung paano lumikha ng isang matalino
liwanag gamit ang ESP32-C3 Wireless Adventure. Ang istraktura ng proyekto,
mga function, paghahanda ng hardware, at proseso ng pagbuo
ipinaliwanag nang detalyado.

Istruktura ng Proyekto

Ang proyekto ay binubuo ng ilang bahagi, kabilang ang
ESP32-C3 Wireless Adventure, LED, sensor, at cloud
backend.

Mga Pag-andar ng Proyekto

Binibigyang-daan ka ng smart light project na kontrolin ang liwanag at
kulay ng mga LED nang malayuan sa pamamagitan ng isang mobile app o web
interface.

Paghahanda ng Hardware

Upang maghanda para sa proyekto, kakailanganin mong tipunin ang
mga kinakailangang bahagi ng hardware, tulad ng ESP32-C3 Wireless
Adventure board, LEDs, resistors, at power supply.

Proseso ng Pag-unlad

Ang proseso ng pag-unlad ay nagsasangkot ng pag-set up ng pag-unlad
kapaligiran, pagsulat ng code upang kontrolin ang mga LED, pagkonekta sa
cloud backend, at pagsubok sa functionality ng smart
liwanag.

Panimula sa ESP RainMaker

Ang ESP RainMaker ay isang malakas na framework para sa pagbuo ng IoT
mga device. Sa seksyong ito, malalaman mo kung ano ang ESP RainMaker at
kung paano ito maipapatupad sa iyong mga proyekto.

Ano ang ESP RainMaker?

Ang ESP RainMaker ay isang cloud-based na platform na nagbibigay ng isang set ng
mga tool at serbisyo para sa pagbuo at pamamahala ng mga IoT device.

Ang Pagpapatupad ng ESP RainMaker

Ipinapaliwanag ng seksyong ito ang iba't ibang bahaging kasangkot sa
pagpapatupad ng ESP RainMaker, kabilang ang serbisyo sa pag-claim,
RainMaker Agent, cloud backend, at RainMaker Client.

Pagsasanay: Mga Pangunahing Punto para sa Pagbuo kasama ang ESP RainMaker

Sa seksyong ito ng pagsasanay, matututunan mo ang tungkol sa mga pangunahing punto sa
isaalang-alang kapag bumubuo sa ESP RainMaker. Kabilang dito ang device
pag-claim, pag-synchronize ng data, at pamamahala ng user.

Mga tampok ng ESP RainMaker

Nag-aalok ang ESP RainMaker ng iba't ibang mga tampok para sa pamamahala ng gumagamit, pagtatapos
mga gumagamit, at mga administrator. Ang mga tampok na ito ay nagbibigay-daan para sa madaling device
setup, remote control, at pagsubaybay.

Pagse-set Up ng Development Environment

Ang seksyong ito ay nagbibigay ng higitview ng ESP-IDF (Espressif IoT
Development Framework), na siyang opisyal na balangkas ng pag-unlad
para sa mga device na nakabatay sa ESP32. Ipinapaliwanag nito ang iba't ibang bersyon ng
ESP-IDF at kung paano i-set up ang development environment.

Pag-unlad ng Hardware at Driver

Disenyo ng Hardware ng mga Smart Light Products batay sa ESP32-C3

Nakatuon ang seksyong ito sa disenyo ng hardware ng matalinong ilaw
mga produkto batay sa ESP32-C3 Wireless Adventure. Sinasaklaw nito ang
mga tampok at komposisyon ng mga smart light na produkto, pati na rin ang
disenyo ng hardware ng ESP32-C3 core system.

Mga Tampok at Komposisyon ng Mga Smart Light Products

Ipinapaliwanag ng subsection na ito ang mga feature at component na gumagawa
up ng mga smart light na produkto. Tinatalakay nito ang iba't ibang mga pag-andar
at mga pagsasaalang-alang sa disenyo para sa paglikha ng mga matalinong ilaw.

Disenyo ng Hardware ng ESP32-C3 Core System

Ang disenyo ng hardware ng ESP32-C3 core system ay may kasamang kapangyarihan
supply, power-on sequence, pag-reset ng system, SPI flash, source ng orasan,
at pagsasaalang-alang sa RF at antenna. Ang subsection na ito ay nagbibigay
detalyadong impormasyon sa mga aspetong ito.

FAQ

Q: Ano ang ESP RainMaker?

A: Ang ESP RainMaker ay isang cloud-based na platform na nagbibigay ng mga tool
at mga serbisyo para sa pagbuo at pamamahala ng mga IoT device. Pinapasimple nito
ang proseso ng pagbuo at nagbibigay-daan para sa madaling pag-setup ng device, remote
kontrol, at pagsubaybay.

T: Paano ko ise-set up ang development environment para sa
ESP32-C3?

A: Upang i-set up ang development environment para sa ESP32-C3, kailangan mo
upang i-install ang ESP-IDF (Espressif IoT Development Framework) at
i-configure ito ayon sa ibinigay na mga tagubilin. Ang ESP-IDF ay ang
opisyal na balangkas ng pagpapaunlad para sa mga device na nakabatay sa ESP32.

Q: Ano ang mga tampok ng ESP RainMaker?

A: Nag-aalok ang ESP RainMaker ng iba't ibang feature, kabilang ang user
pamamahala, mga tampok ng end user, at mga tampok ng admin. Pamamahala ng gumagamit
nagbibigay-daan para sa madaling pag-claim ng device at pag-synchronize ng data. End user
pinapagana ng mga feature ang remote control ng mga device sa pamamagitan ng isang mobile app o
web interface. Nagbibigay ang mga feature ng admin ng mga tool para sa pagsubaybay sa device
at pamamahala.

ESP32-C3 Wireless Adventure
Isang Komprehensibong Gabay sa IoT
Mga Sistema ng Espressif Hunyo 12, 2023

Mga nilalaman

I Paghahanda

1

1 Panimula sa IoT

3

1.1 Arkitektura ng IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 IoT Application sa Smart Homes . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Panimula at Practice ng IoT Projects

9

2.1 Panimula sa Mga Karaniwang Proyekto ng IoT . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Mga Pangunahing Module para sa Mga Karaniwang IoT Device . . . . . . . . . . . . . . . . . 9

2.1.2 Mga Pangunahing Module ng Mga Aplikasyon ng Kliyente . . . . . . . . . . . . . . . . . . . 10

2.1.3 Panimula sa Mga Karaniwang IoT Cloud Platform . . . . . . . . . . . . . . 11

2.2 Pagsasanay: Smart Light Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Istruktura ng Proyekto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Mga Pag-andar ng Proyekto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Paghahanda ng Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Proseso ng Pag-unlad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Panimula sa ESP RainMaker

19

3.1 Ano ang ESP RainMaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Ang Pagpapatupad ng ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Serbisyo sa Pag-claim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 Ahente ng RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

3.2.4 Kliyente ng RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Pagsasanay: Mga Pangunahing Punto para sa Pagbuo gamit ang ESP RainMaker . . . . . . . . . . . . 25

3.4 Mga Tampok ng ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 Pamamahala ng Gumagamit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 Mga Tampok ng End User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.3 Mga Tampok ng Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Pagse-set up ng Development Environment

31

4.1 Tapos na ang ESP-IDFview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Mga Bersyon ng ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3

4.1.2 ESP-IDF Git Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 Pagpili ng Angkop na Bersyon . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4 Lampasview ng ESP-IDF SDK Directory . . . . . . . . . . . . . . . . . . . . 34 4.2 Pag-set up ng ESP-IDF Development Environment . . . . . . . . . . . . . . . . . 38 4.2.1 Pag-set up ng ESP-IDF Development Environment sa Linux . . . . . . . . 38 4.2.2 Pag-set up ng ESP-IDF Development Environment sa Windows . . . . . . 40 4.2.3 Pag-set up ng ESP-IDF Development Environment sa Mac . . . . . . . . . 45 4.2.4 Pag-install ng VS Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 Panimula sa Third-Party Development Environments . . . . . . . . 46 4.3 ESP-IDF Compilation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 Pangunahing Konsepto ng Compilation System . . . . . . . . . . . . . . . . . . 47 4.3.2 Proyekto File Istruktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 Mga Default na Panuntunan sa Pagbuo ng Compilation System. . . . . . . . . . . . . 50 4.3.4 Panimula sa Compilation Script . . . . . . . . . . . . . . . . . . 51 4.3.5 Panimula sa Mga Karaniwang Utos . . . . . . . . . . . . . . . . . . . 52 4.4 Pagsasanay: Pagbubuo ng Halampang Programang “Blink” . . . . . . . . . . . . . . . . . . 53 4.4.1 Halample Pagsusuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2 Pag-iipon ng Blink Program . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 Pag-flash ng Blink Program . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Pagsusuri ng Serial Port Log ng Blink Program. . . . . . . . . . . . . . 60 4.5 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

II Pag-unlad ng Hardware at Driver

65

5 Hardware Design ng Smart Light Products batay sa ESP32-C3

67

5.1 Mga Tampok at Komposisyon ng Mga Produktong Smart Light . . . . . . . . . . . . . . . 67

5.2 Disenyo ng Hardware ng ESP32-C3 Core System . . . . . . . . . . . . . . . . . . . 70

5.2.1 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2 Power-on Sequence at System Reset . . . . . . . . . . . . . . . . . . 74

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

5.2.4 Pinagmulan ng Orasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.5 RF at Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.6 Strapping Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2.7 GPIO at PWM Controller . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Pagsasanay: Pagbuo ng Smart Light System gamit ang ESP32-C3 . . . . . . . . . . . . . 80

5.3.1 Pagpili ng mga Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3.2 Pag-configure ng mga GPIO ng PWM Signals . . . . . . . . . . . . . . . . . . . . 82

5.3.3 Pag-download ng Firmware at Debugging Interface . . . . . . . . . . . . 82

5.3.4 Mga Alituntunin para sa RF Design . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 Mga Alituntunin para sa Disenyo ng Power Supply. . . . . . . . . . . . . . . . . . . 86 5.4 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Pag-unlad ng Driver

87

6.1 Proseso ng Pagbuo ng Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 ESP32-C3 Mga Peripheral na Application . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Mga Pangunahing Kaalaman sa LED Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.1 Mga Puwang ng Kulay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2 LED Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.3 LED Dimming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.4 Panimula sa PWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.4 LED Dimming Driver Development . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 Non-Volatile Storage (NVS) . . . . . . . . . . . . . . . . . . . . . . . . 97

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

6.4.3 LED PWM Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 Pagsasanay: Pagdaragdag ng mga Driver sa Smart Light Project . . . . . . . . . . . . . . . . . 103

6.5.1 Button Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5.2 LED Dimming Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.6 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

III Wireless na Komunikasyon at Kontrol

109

7 Configuration at Koneksyon ng Wi-Fi

111

7.1 Mga Pangunahing Kaalaman ng Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.1 Panimula sa Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.2 Ebolusyon ng IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.3 Mga Konsepto ng Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.1.4 Koneksyon ng Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2 Mga Pangunahing Kaalaman ng Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.2.1 Panimula sa Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.2 Mga Konsepto ng Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.2.3 Koneksyon sa Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Configuration ng Wi-Fi Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.3.1 Gabay sa Configuration ng Wi-Fi Network . . . . . . . . . . . . . . . . . . . . 131

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

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

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

7.3.5 Iba pang Pamamaraan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.4 Wi-Fi Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 Mga Bahagi ng Wi-Fi sa ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 Pagsasanay: Koneksyon ng Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 Pagsasanay: Smart Wi-Fi Connection . . . . . . . . . . . . . . . . . . . . . 145
7.5 Practice: Wi-Fi Configuration sa Smart Light Project . . . . . . . . . . . . . . . 156 7.5.1 Koneksyon ng Wi-Fi sa Smart Light Project . . . . . . . . . . . . . . . . . 156 7.5.2 Smart Wi-Fi Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8 Lokal na Pagkontrol

159

8.1 Panimula sa Lokal na Kontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1.1 Paglalapat ng Lokal na Kontrol . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.2 Advantages ng Lokal na Kontrol . . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.3 Pagtuklas ng Mga Kontroladong Device sa pamamagitan ng Mga Smartphone . . . . . . . . . . 161

8.1.4 Data Communication sa Pagitan ng Mga Smartphone at Device . . . . . . . . 162

8.2 Karaniwang Lokal na Pamamaraan sa Pagtuklas . . . . . . . . . . . . . . . . . . . . . . . . 162

8.2.1 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

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

8.2.3 Paghahambing sa Pagitan ng Broadcast at Multicast . . . . . . . . . . . . . . 176

8.2.4 Multicast Application Protocol mDNS para sa Lokal na Pagtuklas . . . . . . . . 176

8.3 Mga Karaniwang Protokol ng Komunikasyon para sa Lokal na Data . . . . . . . . . . . . . . . 179

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

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

8.3.3 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . 189

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

8.3.5 Bluetooth Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.3.6 Buod ng Data Communication Protocols . . . . . . . . . . . . . . . 203

8.4 Garantiya ng Data Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

8.4.1 Panimula sa Transport Layer Security (TLS) . . . . . . . . . . . . . 207

8.4.2 Panimula sa Datagram Transport Layer Security (DTLS) . . . . . . . 213

8.5 Pagsasanay: Lokal na Kontrol sa Smart Light Project . . . . . . . . . . . . . . . . . . 217

8.5.1 Paglikha ng Local Control Server na nakabatay sa Wi-Fi . . . . . . . . . . . . . . . 217

8.5.2 Pag-verify ng Lokal na Pag-andar ng Kontrol gamit ang Mga Script . . . . . . . . . . . 221

8.5.3 Paglikha ng isang Bluetooth-based na Local Control Server . . . . . . . . . . . . 222

8.6 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 Cloud Control

225

9.1 Panimula sa Remote Control . . . . . . . . . . . . . . . . . . . . . . . . . . 225

9.2 Mga Protokol ng Komunikasyon ng Data ng Cloud . . . . . . . . . . . . . . . . . . . . . . 226

9.2.1 MQTT Panimula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 9.2.2 Mga Prinsipyo ng MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.3 MQTT Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.4 Paghahambing ng Protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5 Pag-set Up ng MQTT Broker sa Linux at Windows . . . . . . . . . . . . 233 9.2.6 Pag-set up ng MQTT Client Batay sa ESP-IDF . . . . . . . . . . . . . . . . 235 9.3 Pagtiyak sa Seguridad ng Data ng MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.1 Kahulugan at Tungkulin ng mga Sertipiko . . . . . . . . . . . . . . . . . . . 237 9.3.2 Lokal na Pagbuo ng mga Sertipiko . . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 Pag-configure ng MQTT Broker . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 Pag-configure ng MQTT Client . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.4 Pagsasanay: Remote Control sa pamamagitan ng ESP RainMaker . . . . . . . . . . . . . . . . 243 9.4.1 Mga Pangunahing Kaalaman sa ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.2 Node at Cloud Backend Communication Protocol . . . . . . . . . . . 244 9.4.3 Komunikasyon sa pagitan ng Kliyente at Cloud Backend . . . . . . . . . . . 249 9.4.4 Mga Tungkulin ng Gumagamit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 Mga Pangunahing Serbisyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.4.6 Matalinong Liwanag Halample . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.7 RainMaker App at Third-Party Integrations . . . . . . . . . . . . . . . 262 9.5 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

10 Pagbuo ng Smartphone App

269

10.1 Panimula sa Pagbuo ng Smartphone App . . . . . . . . . . . . . . . . . . 269

10.1.1 Lampasview ng Smartphone App Development . . . . . . . . . . . . . . . 270

10.1.2 Istraktura ng Android Project . . . . . . . . . . . . . . . . . . . . . . 270

10.1.3 Istraktura ng iOS Project . . . . . . . . . . . . . . . . . . . . . . . . 271

10.1.4 Lifecycle ng isang Aktibidad sa Android . . . . . . . . . . . . . . . . . . . . . . 272

10.1.5 Lifecycle ng iOS ViewController . . . . . . . . . . . . . . . . . . . . . . 273

10.2 Paglikha ng Bagong Smartphone App Project . . . . . . . . . . . . . . . . . . . . . 275

10.2.1 Paghahanda para sa Android Development . . . . . . . . . . . . . . . . . . . 275

10.2.2 Paglikha ng Bagong Proyekto sa Android . . . . . . . . . . . . . . . . . . . . . . 275

10.2.3 Pagdaragdag ng Dependencies para sa MyRainmaker . . . . . . . . . . . . . . . . . 276

10.2.4 Kahilingan ng Pahintulot sa Android . . . . . . . . . . . . . . . . . . . . . . 277

10.2.5 Paghahanda para sa iOS Development . . . . . . . . . . . . . . . . . . . . . . 277

10.2.6 Paglikha ng Bagong Proyekto sa iOS . . . . . . . . . . . . . . . . . . . . . . . . 278

10.2.7 Pagdaragdag ng Dependencies para sa MyRainmaker . . . . . . . . . . . . . . . . . 279

10.2.8 Kahilingan ng Pahintulot sa iOS . . . . . . . . . . . . . . . . . . . . . . . . . 280

10.3 Pagsusuri ng Mga Kinakailangan sa Paggana ng App . . . . . . . . . . . . . . . . . . 281

10.3.1 Pagsusuri ng Mga Kinakailangan sa Paggana ng Proyekto . . . . . . . . . . . . 282

10.3.2 Pagsusuri ng Mga Kinakailangan sa Pamamahala ng Gumagamit. . . . . . . . . . . . . . . 282 10.3.3 Pagsusuri ng Mga Kinakailangan sa Pagbibigay ng Device at Pagbubuklod. . . . . . . 283 10.3.4 Pagsusuri ng Mga Kinakailangang Remote-Control . . . . . . . . . . . . . . . . 283 10.3.5 Pagsusuri ng mga Kinakailangan sa Pag-iiskedyul. . . . . . . . . . . . . . . . . . . 284 10.3.6 Pagsusuri ng Mga Kinakailangan sa User Center . . . . . . . . . . . . . . . . . . 285 10.4 Pagbuo ng Pamamahala ng Gumagamit . . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.1 Panimula sa mga RainMaker API . . . . . . . . . . . . . . . . . . . . . . 285 10.4.2 Pagsisimula ng Komunikasyon sa pamamagitan ng Smartphone . . . . . . . . . . . . . . . . 286 10.4.3 Pagpaparehistro ng Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 10.4.4 Pag-login sa Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 10.5 Pagbuo ng Paglalaan ng Device . . . . . . . . . . . . . . . . . . . . . . . 292 10.5.1 Pag-scan ng Mga Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 10.5.2 Pagkonekta ng mga Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.5.3 Pagbuo ng mga Lihim na Susi . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.4 Pagkuha ng Node ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.5 Mga Provisioning Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 10.6 Pagbuo ng Kontrol ng Device . . . . . . . . . . . . . . . . . . . . . . . . . . 302 10.6.1 Nagbubuklod ng Mga Device sa Mga Cloud Account . . . . . . . . . . . . . . . . . . . . 303 10.6.2 Pagkuha ng Listahan ng Mga Device . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.6.3 Pagkuha ng Katayuan ng Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 10.6.4 Pagbabago ng Katayuan ng Device . . . . . . . . . . . . . . . . . . . . . . . . . . 310 10.7 Pagbuo ng Pag-iiskedyul at User Center . . . . . . . . . . . . . . . . . . . 313 10.7.1 Pagpapatupad ng Function ng Pag-iiskedyul . . . . . . . . . . . . . . . . . . . . 313 10.7.2 Pagpapatupad ng User Center . . . . . . . . . . . . . . . . . . . . . . . . . 315 10.7.3 Higit pang Cloud API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.8 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

11 Pag-upgrade ng Firmware at Pamamahala ng Bersyon

321

11.1 Pag-upgrade ng Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

11.1.1 Lampasview ng Partition Tables . . . . . . . . . . . . . . . . . . . . . . . . 322

11.1.2 Proseso ng Pag-boot ng Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

11.1.3 Lampasview ng OTA Mechanism . . . . . . . . . . . . . . . . . . . . . 326

11.2 Pamamahala ng Bersyon ng Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.1 Pagmarka ng Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

11.2.2 Rollback at Anti-Rollback . . . . . . . . . . . . . . . . . . . . . . . . 331

11.3 Pagsasanay: Over-the-air (OTA) Halample . . . . . . . . . . . . . . . . . . . . . . . 332

11.3.1 I-upgrade ang Firmware sa Pamamagitan ng Lokal na Host . . . . . . . . . . . . . . . . . 332

11.3.2 I-upgrade ang Firmware Sa pamamagitan ng ESP RainMaker . . . . . . . . . . . . . . . 335

11.4 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

IV Optimization at Mass Production

343

12 Power Management at Low-Power Optimization

345

12.1 ESP32-C3 Pamamahala ng Power . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

12.1.1 Pag-scale ng Dynamic na Dalas . . . . . . . . . . . . . . . . . . . . . . . . 346

12.1.2 Configuration ng Power Management . . . . . . . . . . . . . . . . . . . . 348

12.2 ESP32-C3 Low-Power Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

12.2.1 Modem-sleep mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

12.2.2 Light-sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

12.2.3 Deep-sleep mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

12.2.4 Kasalukuyang Pagkonsumo sa Iba't ibang Power Mode . . . . . . . . . . . . . 358

12.3 Power Management at Low-Power Debugging . . . . . . . . . . . . . . . . . 359

12.3.1 Pag-debug ng Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

12.3.2 Pag-debug ng GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

12.4 Practice: Power Management sa Smart Light Project . . . . . . . . . . . . . . . 363

12.4.1 Pag-configure ng Power Management Feature . . . . . . . . . . . . . . . . . 364

12.4.2 Gumamit ng Power Management Locks . . . . . . . . . . . . . . . . . . . . . . 365

12.4.3 Pag-verify ng Pagkonsumo ng Power . . . . . . . . . . . . . . . . . . . . . . . 366

12.5 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

13 Pinahusay na Mga Tampok ng Seguridad ng Device

369

13.1 Lampasview ng IoT Device Data Security . . . . . . . . . . . . . . . . . . . . . . . 369

13.1.1 Bakit Sini-secure ang Data ng IoT Device? . . . . . . . . . . . . . . . . . . . . . . 370

13.1.2 Mga Pangunahing Kinakailangan para sa Seguridad ng Data ng IoT Device . . . . . . . . . . . . 371

13.2 Proteksyon sa Integridad ng Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

13.2.1 Panimula sa Paraan ng Pagpapatunay ng Integridad. . . . . . . . . . . . . . 372

13.2.2 Integridad na Pag-verify ng Firmware Data . . . . . . . . . . . . . . . . . . 373

13.2.3 Halample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3 Proteksyon sa Pagkakumpidensyal ng Data . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.1 Panimula sa Data Encryption . . . . . . . . . . . . . . . . . . . . . . 374

13.3.2 Panimula sa Flash Encryption Scheme . . . . . . . . . . . . . . . . . 376

13.3.3 Flash Encryption Key Storage . . . . . . . . . . . . . . . . . . . . . . . 379

13.3.4 Working Mode ng Flash Encryption . . . . . . . . . . . . . . . . . . . . 380

13.3.5 Proseso ng Flash Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 381

13.3.6 Panimula sa NVS Encryption . . . . . . . . . . . . . . . . . . . . . . 383

13.3.7 Halampkaunting Flash Encryption at NVS Encryption . . . . . . . . . . . 384

13.4 Proteksyon sa Legitimacy ng Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.1 Panimula sa Digital Signature . . . . . . . . . . . . . . . . . . . . . 386

13.4.2 Lampasview ng Secure Boot Scheme . . . . . . . . . . . . . . . . . . . . . 388

13.4.3 Panimula sa Software Secure Boot . . . . . . . . . . . . . . . . . . . 388 13.4.4 Panimula sa Hardware Secure Boot . . . . . . . . . . . . . . . . . . 390 13.4.5 Halamples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 13.5 Practice: Mga Tampok ng Seguridad Sa Mass Production . . . . . . . . . . . . . . . . . . 396 13.5.1 Flash Encryption at Secure Boot . . . . . . . . . . . . . . . . . . . . . 396 13.5.2 Paganahin ang Flash Encryption at Secure Boot na may Batch Flash Tools . . 397 13.5.3 Pag-enable ng Flash Encryption at Secure Boot sa Smart Light Project . . . 398 13.6 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

14 Pagsunog at Pagsubok ng Firmware para sa Mass Production

399

14.1 Pagsunog ng Firmware sa Mass Production . . . . . . . . . . . . . . . . . . . . . . 399

14.1.1 Pagtukoy sa Mga Partition ng Data . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.2 Pagsunog ng Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

14.2 Pagsubok sa Mass Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

14.3 Pagsasanay: Data ng Mass Production sa Smart Light Project . . . . . . . . . . . . . 404

14.4 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

15 Mga Insight sa ESP: Remote Monitoring Platform

405

15.1 Panimula sa ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

15.2 Pagsisimula sa ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . 409

15.2.1 Pagsisimula sa ESP Insights sa esp-insights Project . . . . . . 409

15.2.2 Pagtakbo Halample sa esp-insights Project . . . . . . . . . . . . . . . 411

15.2.3 Pag-uulat ng Impormasyon ng Coredump . . . . . . . . . . . . . . . . . . . . . 411

15.2.4 Pag-customize ng mga Log ng Interes . . . . . . . . . . . . . . . . . . . . . . . . 412

15.2.5 Pag-uulat Dahilan ng Pag-reboot . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.2.6 Pag-uulat ng Mga Custom na Sukat . . . . . . . . . . . . . . . . . . . . . . . . . 413

15.3 Pagsasanay: Paggamit ng ESP Insights sa Smart Light Project . . . . . . . . . . . . . . . 416

15.4 Buod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Panimula
Ang ESP32-C3 ay isang single-core Wi-Fi at Bluetooth 5 (LE) microcontroller SoC, batay sa open-source na arkitektura ng RISC-V. Naabot nito ang tamang balanse ng kapangyarihan, mga kakayahan ng I/O, at seguridad, kaya nag-aalok ng pinakamainam na solusyon sa cost-effective para sa mga konektadong device. Upang ipakita ang iba't ibang aplikasyon ng pamilyang ESP32-C3, dadalhin ka ng aklat na ito ni Espressif sa isang kawili-wiling paglalakbay sa pamamagitan ng AIoT, simula sa mga pangunahing kaalaman sa pagbuo ng proyekto ng IoT at pag-setup ng kapaligiran hanggang sa praktikal na datingamples. Ang unang apat na kabanata ay nagsasalita tungkol sa IoT, ESP RainMaker at ESP-IDF. Maikling Kabanata 5 at 6 sa disenyo ng hardware at pag-develop ng driver. Habang sumusulong ka, matutuklasan mo kung paano i-configure ang iyong proyekto sa pamamagitan ng mga Wi-Fi network at mobile Apps. Sa wakas, matututunan mong i-optimize ang iyong proyekto at ilagay ito sa mass production.
Kung ikaw ay isang inhinyero sa mga kaugnay na larangan, isang software architect, isang guro, isang mag-aaral, o sinumang may interes sa IoT, ang aklat na ito ay para sa iyo.
Maaari mong i-download ang code exampginamit sa aklat na ito mula sa site ni Espressif sa GitHub. Para sa pinakabagong impormasyon sa pag-unlad ng IoT, mangyaring sundan ang aming opisyal na account.

Paunang Salita
Isang Informatising World
Sa pamamagitan ng alon ng Internet, ginawa ng Internet of Things (IoT) ang engrandeng debut nito upang maging isang bagong uri ng imprastraktura sa digital na ekonomiya. Upang mailapit ang teknolohiya sa publiko, gumagana ang Espressif Systems para sa pananaw na ang mga developer mula sa lahat ng antas ng pamumuhay ay maaaring gumamit ng IoT upang lutasin ang ilan sa mga pinakamabigat na problema sa ating panahon. Isang mundo ng "Intelligent Network of All Things" ang inaasahan natin sa hinaharap.
Ang pagdidisenyo ng sarili nating mga chip ay gumagawa ng isang kritikal na bahagi ng pananaw na iyon. Ito ay isang marathon, na nangangailangan ng patuloy na mga tagumpay laban sa mga hangganan ng teknolohiya. Mula sa "Game Changer" na ESP8266 hanggang sa serye ng ESP32 na nagsasama ng Wi-Fi at Bluetoothr (LE) na pagkakakonekta, na sinusundan ng ESP32-S3 na nilagyan ng AI acceleration, hindi tumitigil ang Espressif sa pagsasaliksik at pagbuo ng mga produkto para sa mga solusyon sa AIoT. Gamit ang aming open-source na software, gaya ng IoT Development Framework ESP-IDF, Mesh Development Framework ESP-MDF, at Device Connectivity Platform ESP RainMaker, nakagawa kami ng independiyenteng framework para sa pagbuo ng mga AIoT application.
Noong Hulyo 2022, ang pinagsama-samang pagpapadala ng mga IoT chipset ng Espressif ay lumampas sa 800 milyon, nangunguna sa merkado ng Wi-Fi MCU at nagpapagana ng malaking bilang ng mga konektadong device sa buong mundo. Ang paghahangad para sa kahusayan ay ginagawang malaking hit ang bawat produkto ng Espressif para sa mataas na antas ng pagsasama nito at kahusayan sa gastos. Ang paglabas ng ESP32-C3 ay nagmamarka ng isang makabuluhang milestone ng self-developed na teknolohiya ng Espressif. Ito ay isang single-core, 32-bit, RISC-V-based na MCU na may 400KB ng SRAM, na maaaring tumakbo sa 160MHz. Isinama nito ang 2.4 GHz Wi-Fi at Bluetooth 5 (LE) na may long-range na suporta. Nakakakuha ito ng mahusay na balanse ng kapangyarihan, mga kakayahan sa I/O, at seguridad, kaya nag-aalok ng pinakamainam na solusyon sa cost-effective para sa mga konektadong device. Batay sa napakalakas na ESP32-C3, ang aklat na ito ay nilayon na tulungan ang mga mambabasa na maunawaan ang kaalamang nauugnay sa IoT na may detalyadong paglalarawan at praktikal na dating.amples.
Bakit namin sinulat ang librong ito?
Ang Espressif Systems ay higit pa sa isang semiconductor na kumpanya. Isa rin itong kumpanya ng platform ng IoT, na palaging nagsusumikap para sa mga tagumpay at pagbabago sa larangan ng teknolohiya. Kasabay nito, ang Espressif ay may open-sourced at ibinahagi ang sariling binuo na operating system at software framework sa komunidad, na bumubuo ng isang natatanging ecosystem. Ang mga inhinyero, gumagawa, at mahilig sa teknolohiya ay aktibong bumuo ng mga bagong software application batay sa mga produkto ng Espressif, malayang nakikipag-usap, at nagbabahagi ng kanilang karanasan. Maaari mong makita ang mga kamangha-manghang ideya ng mga developer sa iba't ibang platform sa lahat ng oras, gaya ng YouTube at GitHub. Ang katanyagan ng mga produkto ng Espressif ay nagpasigla ng dumaraming bilang ng mga may-akda na gumawa ng higit sa 100 mga libro batay sa mga chipset ng Espressif, sa higit sa sampung wika, kabilang ang English, Chinese, German, French, at Japanese.

Ang suporta at pagtitiwala ng mga kasosyo sa komunidad ang naghihikayat sa patuloy na pagbabago ng Espressif. “Nagsusumikap kaming gawing mas may-katuturan ang aming mga chip, operating system, frameworks, solusyon, Cloud, mga kasanayan sa negosyo, tool, dokumentasyon, mga sulatin, ideya, atbp., sa mga sagot na kailangan ng mga tao sa mga problema sa kontemporaryong buhay. Ito ang pinakamataas na ambisyon at moral na kompas ni Espressif.” sabi ni G. Teo Swee Ann, Founder at CEO ng Espressif.
Pinahahalagahan ng espressif ang pagbabasa at mga ideya. Dahil ang patuloy na pag-upgrade ng teknolohiya ng IoT ay nagdudulot ng mas matataas na pangangailangan sa mga inhinyero, paano namin matutulungan ang mas maraming tao na mabilis na makabisado ang mga IoT chips, operating system, software frameworks, application scheme at cloud service products? Sabi nga sa kasabihan, mas mabuting turuan ang isang tao kung paano mangisda kaysa bigyan siya ng isda. Sa isang sesyon ng brainstorming, naisip namin na maaari kaming magsulat ng isang libro upang sistematikong ayusin ang pangunahing kaalaman sa pag-unlad ng IoT. Naabot namin ito, mabilis na nagtipon ng grupo ng mga senior engineer, at pinagsama ang karanasan ng technical team sa naka-embed na programming, IoT hardware at software development, lahat ay nag-aambag sa pag-publish ng aklat na ito. Sa proseso ng pagsusulat, sinubukan namin ang aming makakaya na maging layunin at patas, alisin ang cocoon, at gumamit ng mga maiikling expression upang sabihin ang pagiging kumplikado at kagandahan ng Internet of Things. Maingat naming ibinuod ang mga karaniwang tanong, tinukoy ang feedback at suhestiyon ng komunidad, upang malinaw na masagot ang mga tanong na nakatagpo sa proseso ng pag-unlad, at magbigay ng praktikal na mga alituntunin sa pagpapaunlad ng IoT para sa mga nauugnay na technician at gumagawa ng desisyon.
Istraktura ng Aklat
Ang aklat na ito ay tumatagal ng isang inhinyero na nakasentro sa pananaw at nagpapaliwanag ng kinakailangang kaalaman para sa IoT project development hakbang-hakbang. Ito ay binubuo ng apat na bahagi, tulad ng sumusunod:
· Paghahanda (Kabanata 1): Ang bahaging ito ay nagpapakilala sa arkitektura ng IoT, tipikal na IoT project framework, ang ESP RainMakerr cloud platform, at ang development environment na ESP-IDF, upang maglatag ng matatag na pundasyon para sa IoT project development.
· Pag-develop ng Hardware at Driver (Kabanata 5): Batay sa ESP6-C32 chipset, ang bahaging ito ay nagpapaliwanag sa minimum na sistema ng hardware at pag-develop ng driver, at ipinapatupad ang kontrol ng dimming, color grading, at wireless na komunikasyon.
· Wireless na Komunikasyon at Kontrol (Kabanata 7): Ipinapaliwanag ng bahaging ito ang intelligent na scheme ng pagsasaayos ng Wi-Fi batay sa ESP11-C32 chip, lokal at cloud control protocol, at lokal at remote na kontrol ng mga device. Nagbibigay din ito ng mga scheme para sa pagbuo ng mga smartphone app, pag-upgrade ng firmware, at pamamahala ng bersyon.
· Optimization at Mass Production (Kabanata 12-15): Ang bahaging ito ay inilaan para sa mga advanced na IoT application, na tumutuon sa pag-optimize ng mga produkto sa pamamahala ng kuryente, low-power optimization, at pinahusay na seguridad. Ipinakikilala rin nito ang pagsunog at pagsubok ng firmware sa mass production, at kung paano i-diagnose ang running status at mga log ng firmware ng device sa pamamagitan ng remote monitoring platform na ESP Insights.

Tungkol sa Source Code
Maaaring patakbuhin ng mga mambabasa ang exampang mga programa sa aklat na ito, alinman sa pamamagitan ng pagpasok ng code nang manu-mano o sa pamamagitan ng paggamit ng source code na kasama ng aklat. Binibigyang-diin namin ang kumbinasyon ng teorya at kasanayan, at sa gayon ay nagtatakda ng seksyong Practice batay sa proyekto ng Smart Light sa halos bawat kabanata. Ang lahat ng mga code ay open-sourced. Inaanyayahan ang mga mambabasa na i-download ang source code at talakayin ito sa mga seksyong nauugnay sa aklat na ito sa GitHub at sa aming opisyal na forum na esp32.com. Ang open-sourced code ng aklat na ito ay napapailalim sa mga tuntunin ng Apache License 2.0.
Author's Note
Ang aklat na ito ay opisyal na ginawa ng Espressif Systems at isinulat ng mga senior engineer ng kumpanya. Ito ay angkop para sa mga tagapamahala at mga tauhan ng R&D sa mga industriyang nauugnay sa IoT, mga guro at mag-aaral ng mga kaugnay na major, at mga mahilig sa larangan ng Internet of Things. Umaasa kami na ang aklat na ito ay magsisilbing manwal sa trabaho, sanggunian, at aklat sa tabi ng kama, upang maging tulad ng isang mabuting tagapagturo at kaibigan.
Habang kino-compile ang aklat na ito, tinukoy namin ang ilang nauugnay na resulta ng pananaliksik ng mga eksperto, iskolar, at technician sa loob at labas ng bansa, at ginawa namin ang aming makakaya upang banggitin ang mga ito ayon sa mga pamantayang pang-akademiko. Gayunpaman, hindi maiiwasan na magkaroon ng ilang mga pagkukulang, kaya dito nais naming ipahayag ang aming matinding paggalang at pasasalamat sa lahat ng may-katuturang may-akda. Bilang karagdagan, nag-quote kami ng impormasyon mula sa Internet, kaya nais naming pasalamatan ang mga orihinal na may-akda at mga publisher at humihingi ng paumanhin na hindi namin maipahiwatig ang pinagmulan ng bawat piraso ng impormasyon.
Upang makabuo ng isang aklat na may mataas na kalidad, nag-organisa kami ng mga pag-ikot ng mga panloob na talakayan, at natuto mula sa mga mungkahi at puna ng mga pagsubok na mambabasa at mga editor ng publisher. Dito, nais naming magpasalamat muli sa iyong tulong na lahat ay nag-ambag sa matagumpay na gawaing ito.
Huli, ngunit ang pinakamahalaga, salamat sa lahat sa Espressif na nagsumikap para sa pagsilang at pagpapasikat ng aming mga produkto.
Ang pagbuo ng mga proyekto ng IoT ay nagsasangkot ng malawak na hanay ng kaalaman. Limitado sa haba ng aklat, pati na rin ang antas at karanasan ng may-akda, ang mga pagkukulang ay hindi maiiwasan. Kaya naman, hinihiling namin sa mga eksperto at mambabasa na punahin at itama ang aming mga pagkakamali. Kung mayroon kang anumang mga mungkahi para sa aklat na ito, mangyaring makipag-ugnayan sa amin sa book@espressif.com. Inaasahan namin ang iyong puna.

Paano gamitin ang aklat na ito?
Ang code ng mga proyekto sa aklat na ito ay open sourced. Maaari mong i-download ito mula sa aming GitHub repository at ibahagi ang iyong mga iniisip at tanong sa aming opisyal na forum. GitHub: https://github.com/espressif/book-esp32c3-iot-projects Forum: https://www.esp32.com/bookc3 Sa kabuuan ng aklat, may mga bahaging naka-highlight tulad ng ipinapakita sa ibaba.
Source code Sa aklat na ito, binibigyang-diin namin ang kumbinasyon ng teorya at kasanayan, at sa gayon ay nagtatakda ng seksyong Practice tungkol sa proyekto ng Smart Light sa halos bawat kabanata. Ang mga kaukulang hakbang at pahina ng pinagmulan ay mamarkahan sa pagitan ng dalawang linya na nagsisimula sa tag Source code.
TANDAAN/TIPS Dito maaari kang makakita ng ilang kritikal na impormasyon at paalala para sa matagumpay na pag-debug ng iyong programa. Sila ay mamarkahan sa pagitan ng dalawang makapal na linya na nagsisimula sa tag TANDAAN o TIP.
Karamihan sa mga utos sa aklat na ito ay isinasagawa sa ilalim ng Linux, na sinenyasan ng character na "$". Kung ang command ay nangangailangan ng mga pribilehiyo ng superuser upang maipatupad, ang prompt ay papalitan ng "#". Ang command prompt sa mga Mac system ay “%”, gaya ng ginamit sa Seksyon 4.2.3 Pag-install ng ESP-IDF sa Mac.
Ang body text sa aklat na ito ay ipi-print sa Charter, habang ang code examples, mga bahagi, mga function, mga variable, code file ang mga pangalan, mga direktoryo ng code, at mga string ay nasa Courier New.
Ang mga command o text na kailangang i-input ng user, at mga command na maaaring ilagay sa pamamagitan ng pagpindot sa "Enter" key ay ipi-print sa Courier New bold. Ang mga log at mga bloke ng code ay ipapakita sa mapusyaw na asul na mga kahon.
Example:
Pangalawa, gumamit ng esp-idf/components/nvs flash/nvs partition generator/nvs partition gen.py para bumuo ng NVS partition binary file sa development host na may sumusunod na command:
$ python $IDF PATH/mga bahagi/nvs flash/nvs partition generator/nvs partition gen.py –input mass prod.csv –output mass prod.bin –size NVS PARTITION SIZE

Kabanata 1

Panimula

sa

IoT

Sa pagtatapos ng ika-20 siglo, sa pag-usbong ng mga network ng kompyuter at mga teknolohiya ng komunikasyon, mabilis na isinama ang Internet sa buhay ng mga tao. Habang patuloy na tumatanda ang teknolohiya ng Internet, ipinanganak ang ideya ng Internet of Things (IoT). Sa literal, ang IoT ay nangangahulugang isang Internet kung saan konektado ang mga bagay. Bagama't nilalabag ng orihinal na Internet ang mga limitasyon ng espasyo at oras at pinapaliit ang distansya sa pagitan ng "tao at tao", ginagawa ng IoT na mahalagang kalahok ang "mga bagay", na pinaglapit ang "mga tao" at "mga bagay". Sa nakikinita na hinaharap, ang IoT ay nakatakdang maging puwersang nagtutulak ng industriya ng impormasyon.
Kaya, ano ang Internet ng mga Bagay?
Mahirap na tumpak na tukuyin ang Internet ng mga Bagay, dahil ang kahulugan at saklaw nito ay patuloy na nagbabago. Noong 1995, unang inilabas ni Bill Gates ang ideya ng IoT sa kanyang aklat na The Road Ahead. Sa madaling salita, binibigyang-daan ng IoT ang mga bagay na makipagpalitan ng impormasyon sa isa't isa sa pamamagitan ng Internet. Ang sukdulang layunin nito ay magtatag ng isang "Internet ng Lahat". Ito ay isang maagang interpretasyon ng IoT, pati na rin isang pantasya ng hinaharap na teknolohiya. Makalipas ang tatlumpung taon, sa mabilis na pag-unlad ng ekonomiya at teknolohiya, ang pantasya ay natutupad na. Mula sa mga smart device, smart home, smart city, Internet of Vehicles at wearable device, hanggang sa "metaverse" na sinusuportahan ng mga teknolohiya ng IoT, patuloy na umuusbong ang mga bagong konsepto. Sa kabanatang ito, magsisimula tayo sa pagpapaliwanag ng arkitektura ng Internet of Things, at pagkatapos ay ipakilala ang pinakakaraniwang IoT application, ang smart home, upang matulungan kang makakuha ng malinaw na pag-unawa sa IoT.
1.1 Arkitektura ng IoT
Ang Internet of Things ay nagsasangkot ng maraming teknolohiya na may iba't ibang mga pangangailangan at porma ng aplikasyon sa iba't ibang industriya. Upang ayusin ang istraktura, ang mga pangunahing teknolohiya at mga katangian ng aplikasyon ng IoT, kinakailangan na magtatag ng isang pinag-isang arkitektura at isang karaniwang teknikal na sistema. Sa aklat na ito, ang arkitektura ng IoT ay simpleng nahahati sa apat na layer: perception & control layer, network layer, platform layer, at application layer.
Perception at Control Layer Bilang ang pinakapangunahing elemento ng IoT architecture, perception at control layer ang core upang maisakatuparan ang komprehensibong sensing ng IoT. Ang pangunahing tungkulin nito ay upang mangolekta, kilalanin at kontrolin ang impormasyon. Binubuo ito ng iba't ibang mga aparato na may kakayahan ng pang-unawa,
3

pagkakakilanlan, kontrol at pagpapatupad, at responsable para sa pagkuha at pagsusuri ng data tulad ng mga materyal na katangian, mga uso sa pag-uugali, at katayuan ng device. Sa ganitong paraan, nakikilala ng IoT ang tunay na pisikal na mundo. Bukod, ang layer ay nagagawa ring kontrolin ang katayuan ng device.
Ang pinakakaraniwang mga aparato ng layer na ito ay iba't ibang mga sensor, na gumaganap ng isang mahalagang papel sa pagkolekta ng impormasyon at pagkakakilanlan. Ang mga sensor ay tulad ng mga organo ng pandama ng tao, tulad ng mga photosensitive sensor na katumbas ng paningin, mga acoustic sensor sa pandinig, mga gas sensor sa pang-amoy, at mga pressure-at temperature-sensitive na sensor sa paghawak. Sa lahat ng mga "sensory organ" na ito, ang mga bagay ay nagiging "buhay" at may kakayahang matalinong pagdama, pagkilala at pagmamanipula ng pisikal na mundo.
Network Layer Ang pangunahing function ng network layer ay upang magpadala ng impormasyon, kabilang ang data na nakuha mula sa perception at control layer sa tinukoy na target, pati na rin ang mga command na inilabas mula sa application layer pabalik sa perception at control layer. Nagsisilbi itong mahalagang tulay ng komunikasyon na nagkokonekta sa iba't ibang layer ng isang IoT system. Upang mag-set up ng pangunahing modelo ng Internet of Things, nagsasangkot ito ng dalawang hakbang upang isama ang mga bagay sa isang network: access sa Internet at transmission sa pamamagitan ng Internet.
Ang pag-access sa Internet Internet ay nagbibigay-daan sa interconnection sa pagitan ng tao at tao, ngunit nabigo na isama ang mga bagay sa malaking pamilya. Bago ang pagdating ng IoT, karamihan sa mga bagay ay hindi "magagawa ng network". Salamat sa patuloy na pag-unlad ng teknolohiya, ang IoT ay namamahala upang ikonekta ang mga bagay sa Internet, kaya napagtatanto ang pagkakaugnay sa pagitan ng "mga tao at mga bagay", at "mga bagay at bagay". Mayroong dalawang karaniwang paraan para ipatupad ang koneksyon sa Internet: wired network access at wireless network access.
Kasama sa mga paraan ng pag-access sa wired network ang Ethernet, serial communication (hal., RS-232, RS-485) at USB, habang ang wireless network access ay nakasalalay sa wireless na komunikasyon, na maaaring nahahati pa sa short-range wireless communication at long-range wireless communication.
Kasama sa short-range na wireless na komunikasyon ang ZigBee, Bluetoothr, Wi-Fi, Near-Field Communication (NFC), at Radio Frequency Identification (RFID). Kasama sa long-range na wireless na komunikasyon ang Enhanced Machine Type Communication (eMTC), LoRa, Narrow Band Internet of Things (NB-IoT), 2G, 3G, 4G, 5G, atbp.
Paghahatid sa pamamagitan ng Internet Ang iba't ibang paraan ng pag-access sa Internet ay humahantong sa kaukulang pisikal na link ng paghahatid ng data. Ang susunod na bagay ay ang magpasya kung aling protocol ng komunikasyon ang gagamitin upang maihatid ang data. Kung ikukumpara sa mga Internet terminal, karamihan sa mga IoT terminal ay kasalukuyang mas kaunti
4 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

magagamit na mga mapagkukunan, tulad ng pagganap ng pagproseso, kapasidad ng imbakan, rate ng network, atbp., kaya kinakailangang pumili ng protocol ng komunikasyon na sumasakop sa mas kaunting mga mapagkukunan sa mga application ng IoT. Mayroong dalawang protocol ng komunikasyon na malawakang ginagamit ngayon: Message Queuing Telemetry Transport (MQTT) at Constrained Application Protocol (CoAP).
Platform Layer Pangunahing tumutukoy ang layer ng platform sa mga IoT cloud platform. Kapag ang lahat ng IoT terminal ay naka-network, ang kanilang data ay kailangang pagsama-samahin sa isang IoT cloud platform upang makalkula at maiimbak. Pangunahing sinusuportahan ng layer ng platform ang mga application ng IoT sa pagpapadali ng pag-access at pamamahala ng napakalaking device. Ikinokonekta nito ang mga terminal ng IoT sa cloud platform, nangongolekta ng data ng terminal, at nag-isyu ng mga command sa mga terminal, upang maipatupad ang remote control. Bilang isang intermediate na serbisyo upang magtalaga ng mga kagamitan sa mga aplikasyon sa industriya, ang layer ng platform ay gumaganap ng isang papel na nagkokonekta sa buong arkitektura ng IoT, na nagdadala ng abstract na lohika ng negosyo at standardized na pangunahing modelo ng data, na hindi lamang makakapagtanto ng mabilis na pag-access ng mga device, ngunit nagbibigay din ng malakas na modular na mga kakayahan. upang matugunan ang iba't ibang pangangailangan sa mga sitwasyon ng aplikasyon sa industriya. Pangunahing kasama sa layer ng platform ang mga functional na module tulad ng pag-access sa device, pamamahala ng device, pamamahala sa seguridad, komunikasyon sa mensahe, pagsubaybay sa operasyon at pagpapanatili, at mga application ng data.
· Pag-access sa device, na napagtatanto ang koneksyon at komunikasyon sa pagitan ng mga terminal at IoT cloud platform.
· Pamamahala ng device, kabilang ang mga function gaya ng paggawa ng device, pagpapanatili ng device, conversion ng data, pag-synchronize ng data, at pamamahagi ng device.
· Pamamahala sa seguridad, tinitiyak ang seguridad ng pagpapadala ng data ng IoT mula sa mga pananaw ng pagpapatunay ng seguridad at seguridad ng komunikasyon.
· Komunikasyon ng mensahe, kabilang ang tatlong direksyon sa pagpapadala, iyon ay, ang terminal ay nagpapadala ng data sa IoT cloud platform, ang IoT cloud platform ay nagpapadala ng data sa server side o iba pang IoT cloud platform, at ang server side ay malayuang kinokontrol ang IoT device.
· Pagsubaybay sa O&M, na kinasasangkutan ng pagsubaybay at pagsusuri, pag-upgrade ng firmware, online na pag-debug, mga serbisyo sa pag-log, atbp.
· Mga aplikasyon ng data, na kinasasangkutan ng imbakan, pagsusuri at aplikasyon ng data.
Application Layer Ginagamit ng application layer ang data mula sa platform layer upang pamahalaan ang application, pag-filter at pagproseso ng mga ito gamit ang mga tool tulad ng mga database at software sa pagsusuri. Maaaring gamitin ang resultang data para sa mga real-world na IoT application gaya ng smart healthcare, smart agriculture, smart homes, at smart city.
Siyempre, ang arkitektura ng IoT ay maaaring hatiin sa higit pang mga layer, ngunit gaano man karaming mga layer ang binubuo nito, ang pinagbabatayan na prinsipyo ay nananatiling pareho. Pag-aaral
Kabanata 1. Panimula sa IoT 5

Ang tungkol sa arkitektura ng IoT ay nakakatulong na palalimin ang aming pag-unawa sa mga teknolohiya ng IoT at bumuo ng mga fully functional na proyekto ng IoT.
1.2 IoT Application sa Smart Homes
Ang IoT ay tumagos sa lahat ng antas ng pamumuhay, at ang pinaka malapit na nauugnay na IoT application sa amin ay ang matalinong tahanan. Maraming tradisyunal na appliances ang nilagyan na ngayon ng isa o higit pang IoT device, at maraming bagong gawang bahay ang idinisenyo gamit ang mga teknolohiya ng IoT sa simula. Ipinapakita ng Figure 1.1 ang ilang karaniwang smart home device.
Larawan 1.1. Mga karaniwang smart home device Ang pagbuo ng smart home ay maaaring hatiin lamang sa mga smart na produktotage, pagkakaugnay ng eksena stage at matalino stage, tulad ng ipinapakita sa Figure 1.2.
Larawan 1.2. Pag-unlad stage ng smart home 6 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Ang unang stage ay tungkol sa mga matalinong produkto. Kaiba sa mga tradisyonal na tahanan, sa mga smart home, ang mga IoT device ay tumatanggap ng mga signal na may mga sensor, at naka-network sa pamamagitan ng mga wireless na teknolohiya sa komunikasyon gaya ng Wi-Fi, Bluetooth LE, at ZigBee. Maaaring kontrolin ng mga user ang mga smart na produkto sa iba't ibang paraan, gaya ng mga smartphone app, voice assistant, smart speaker control, atbp. Ang pangalawang stage nakatutok sa pagkakaugnay ng eksena. Sa stage, hindi na isinasaalang-alang ng mga developer ang pagkontrol sa iisang smart na produkto, ngunit pag-uugnay ng dalawa o higit pang matalinong produkto, pag-automate sa isang partikular na lawak, at sa wakas ay bumubuo ng custom na scene mode. Para kay exampAt, kapag pinindot ng user ang anumang button ng scene mode, ang mga ilaw, kurtina, at air conditioner ay awtomatikong iaangkop sa mga preset. Siyempre, mayroong paunang kinakailangan na ang logic ng linkage ay madaling mai-set up, kabilang ang mga kundisyon sa pag-trigger at mga aksyon sa pagpapatupad. Isipin na ang air conditioning heating mode ay na-trigger kapag ang panloob na temperatura ay bumaba sa ibaba 10°C; na sa alas-7 ng umaga, pinapatugtog ang musika upang gisingin ang gumagamit, bubuksan ang mga smart curtain, at magsisimula ang rice cooker o bread toaster sa pamamagitan ng smart socket; habang ang gumagamit ay bumangon at matapos maghugas, inihahain na ang almusal, upang walang pagkaantala sa pagpasok sa trabaho. Gaano kaginhawa ang ating buhay! Ang ikatlong stage napupunta sa katalinuhan stage. Habang mas maraming smart home device ang naa-access, gayundin ang mga uri ng data na nabuo. Sa tulong ng cloud computing, big data at artificial intelligence, para itong "mas matalinong utak" na itinanim sa mga smart home, na hindi na nangangailangan ng madalas na mga utos mula sa user. Nangongolekta sila ng data mula sa mga nakaraang pakikipag-ugnayan at natutunan ang mga pattern ng pag-uugali at mga kagustuhan ng user, upang i-automate ang mga aktibidad, kabilang ang pagbibigay ng mga rekomendasyon para sa paggawa ng desisyon. Sa kasalukuyan, karamihan sa mga matalinong tahanan ay nasa eksenang magkakaugnay stage. Habang tumataas ang penetration rate at intelligence ng mga smart na produkto, inaalis ang mga hadlang sa pagitan ng mga protocol ng komunikasyon. Sa hinaharap, ang mga matalinong tahanan ay tiyak na magiging talagang "matalino", tulad ng AI system na Jarvis sa Iron Man, na hindi lamang makakatulong sa gumagamit na kontrolin ang iba't ibang mga aparato, pangasiwaan ang mga pang-araw-araw na gawain, ngunit mayroon ding sobrang kapangyarihan sa pag-compute at kakayahan sa pag-iisip. Sa matatalinong stage, ang mga tao ay makakatanggap ng mas mahusay na serbisyo kapwa sa dami at kalidad.
Kabanata 1. Panimula sa IoT 7

8 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Panimula at Pagsasanay ng Kabanata ng 2 IoT Projects
Sa Kabanata 1, ipinakilala namin ang arkitektura ng IoT, at ang mga tungkulin at ugnayan ng perception at control layer, network layer, platform layer, at application layer, pati na rin ang pagbuo ng smart home. Gayunpaman, tulad ng kapag natutunan nating magpinta, ang pag-alam sa teoretikal na kaalaman ay malayo sa sapat. Kailangan nating "marumi ang ating mga kamay" upang maisagawa ang mga proyekto ng IoT upang tunay na makabisado ang teknolohiya. Bilang karagdagan, kapag ang isang proyekto ay lumipat sa mass production stage, kinakailangang isaalang-alang ang higit pang mga salik gaya ng koneksyon sa network, pagsasaayos, pakikipag-ugnayan ng IoT cloud platform, pamamahala at pag-update ng firmware, pamamahala sa mass production, at pagsasaayos ng seguridad. Kaya, ano ang kailangan nating bigyang pansin kapag bumubuo ng isang kumpletong proyekto ng IoT? Sa Kabanata 1, binanggit namin na ang smart home ay isa sa mga pinakakaraniwang sitwasyon ng IoT application, at ang mga smart light ay isa sa pinakapangunahing at praktikal na appliances, na maaaring gamitin sa mga tahanan, hotel, gym, ospital, atbp. Samakatuwid, sa sa aklat na ito, gagawin namin ang pagbuo ng isang smart light project bilang panimulang punto, ipaliwanag ang mga bahagi at feature nito, at magbibigay ng gabay sa pagbuo ng proyekto. Umaasa kami na makakagawa ka ng mga hinuha mula sa kasong ito upang lumikha ng higit pang mga IoT application.
2.1 Panimula sa Mga Karaniwang Proyekto ng IoT
Sa mga tuntunin ng pagpapaunlad, ang mga pangunahing functional na module ng mga proyekto ng IoT ay maaaring uriin sa software at hardware development ng IoT device, client application development, at IoT cloud platform development. Mahalagang linawin ang mga pangunahing functional na module, na higit na ilalarawan sa seksyong ito.
2.1.1 Mga Pangunahing Module para sa Mga Karaniwang IoT Device
Kasama sa software at hardware development ng IoT device ang mga sumusunod na pangunahing module: Pangongolekta ng data
Bilang ilalim na layer ng arkitektura ng IoT, ang mga IoT device ng perception at control layer ay nagkokonekta ng mga sensor at device sa pamamagitan ng kanilang mga chip at peripheral upang makamit ang pangongolekta ng data at kontrol sa pagpapatakbo.
9

Account binding at paunang configuration Para sa karamihan ng IoT device, ang account binding at initial configuration ay nakumpleto sa isang operational na proseso, para sa example, pagkonekta ng mga device sa mga user sa pamamagitan ng pag-configure ng Wi-Fi network.
Pakikipag-ugnayan sa mga IoT cloud platform Para masubaybayan at makontrol ang mga IoT device, kinakailangan ding ikonekta ang mga ito sa IoT cloud platform, para makapagbigay ng mga command at mag-ulat ng status sa pamamagitan ng pakikipag-ugnayan sa isa't isa.
Kontrol ng device Kapag nakakonekta sa mga IoT cloud platform, maaaring makipag-ugnayan ang mga device sa cloud at mairehistro, i-bound, o kontrolado. Maaaring i-query ng mga user ang status ng produkto at magsagawa ng iba pang mga operasyon sa smartphone app sa pamamagitan ng IoT cloud platform o local communication protocols.
Ang pag-upgrade ng firmware na mga IoT device ay maaari ding makamit ang pag-upgrade ng firmware batay sa mga pangangailangan ng mga tagagawa. Sa pamamagitan ng pagtanggap ng mga utos na ipinadala ng cloud, ang pag-upgrade ng firmware at pamamahala ng bersyon ay maisasakatuparan. Gamit ang feature na ito sa pag-upgrade ng firmware, maaari mong patuloy na mapahusay ang mga function ng mga IoT device, ayusin ang mga depekto, at pagbutihin ang karanasan ng user.
2.1.2 Mga Pangunahing Module ng Mga Aplikasyon ng Kliyente
Pangunahing kasama sa mga application ng kliyente (hal., mga smartphone app) ang mga sumusunod na pangunahing module:
Sistema ng account at awtorisasyon Sinusuportahan nito ang awtorisasyon ng account at device.
Kontrol ng device Ang mga smartphone app ay karaniwang nilagyan ng mga function ng pagkontrol. Madaling kumonekta ang mga user sa mga IoT device, at pamahalaan ang mga ito anumang oras, kahit saan sa pamamagitan ng mga smartphone app. Sa isang real-world na smart home, ang mga device ay kadalasang kinokontrol sa pamamagitan ng mga smartphone app, na hindi lamang nagbibigay-daan sa matalinong pamamahala ng mga device, ngunit nakakatipid din sa gastos ng lakas-tao. Samakatuwid, kailangan ang kontrol ng device para sa mga application ng kliyente, tulad ng kontrol ng katangian ng function ng device, kontrol ng eksena, pag-iiskedyul, remote control, linkage ng device, atbp. Maaari ding i-customize ng mga user ng Smart home ang mga eksena ayon sa mga personal na pangangailangan, pagkontrol sa ilaw, mga gamit sa bahay, pasukan. , atbp., upang gawing mas komportable at maginhawa ang buhay tahanan. Maaari nilang i-time ang air conditioning, i-off ito nang malayuan, awtomatikong i-on ang ilaw sa pasilyo kapag na-unlock ang pinto, o lumipat sa "theater" mode gamit ang isang solong button.
Ina-update ng mga application ng Notification Client ang real-time na status ng mga IoT device, at nagpapadala ng mga alerto kapag naging abnormal ang mga device.
10 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

After-sales customer service Maaaring magbigay ang mga smartphone app ng mga after-sales na serbisyo para sa mga produkto, upang malutas ang mga problemang nauugnay sa mga pagkabigo ng IoT device at teknikal na operasyon sa isang napapanahong paraan.
Mga tampok na function Upang matugunan ang mga pangangailangan ng iba't ibang mga user, maaaring magdagdag ng iba pang mga function, tulad ng Shake, NFC, GPS, atbp. Makakatulong ang GPS na itakda ang katumpakan ng mga operasyon sa eksena ayon sa lokasyon at distansya, habang ang Shake function ay nagpapahintulot sa mga user na itakda ang mga utos na isasagawa para sa partikular na device o eksena sa pamamagitan ng pag-iling.
2.1.3 Panimula sa Mga Karaniwang IoT Cloud Platform
Ang IoT cloud platform ay isang all-in-one na platform na nagsasama ng mga function tulad ng pamamahala ng device, komunikasyon sa seguridad ng data, at pamamahala ng notification. Ayon sa kanilang target na grupo at pagiging naa-access, ang mga IoT cloud platform ay maaaring hatiin sa mga pampublikong IoT cloud platform (mula rito ay tinutukoy bilang "pampublikong ulap") at pribadong IoT cloud platform (mula dito ay tinutukoy bilang "pribadong ulap").
Karaniwang ipinapahiwatig ng pampublikong cloud ang mga nakabahaging IoT cloud platform para sa mga negosyo o indibidwal, pinatatakbo at pinapanatili ng mga provider ng platform, at ibinahagi sa pamamagitan ng Internet. Maaari itong maging libre o mura, at nagbibigay ng mga serbisyo sa buong bukas na pampublikong network, tulad ng Alibaba Cloud, Tencent Cloud, Baidu Cloud, AWS IoT, Google IoT, atbp. Bilang isang sumusuportang platform, maaaring isama ng pampublikong cloud ang mga upstream na service provider at downstream end user upang lumikha ng bagong value chain at ecosystem.
Ang pribadong cloud ay binuo para sa paggamit ng enterprise lamang, kaya ginagarantiyahan ang pinakamahusay na kontrol sa data, seguridad, at kalidad ng serbisyo. Ang mga serbisyo at imprastraktura nito ay hiwalay na pinapanatili ng mga negosyo, at ang sumusuportang hardware at software ay nakatuon din sa mga partikular na user. Maaaring i-customize ng mga negosyo ang mga serbisyo sa cloud upang matugunan ang mga pangangailangan ng kanilang negosyo. Sa kasalukuyan, ang ilang mga tagagawa ng smart home ay nakakuha na ng mga pribadong IoT cloud platform at nakabuo ng mga smart home application batay sa mga ito.
Ang pampublikong ulap at pribadong ulap ay may sariling advantages, na ipapaliwanag sa ibang pagkakataon.
Upang makamit ang koneksyon sa komunikasyon, kinakailangan na kumpletuhin ang hindi bababa sa naka-embed na pag-develop sa bahagi ng device, kasama ang mga server ng negosyo, mga IoT cloud platform, at mga smartphone app. Sa pagharap sa napakalaking proyekto, ang pampublikong cloud ay karaniwang nagbibigay ng mga software development kit para sa device-side at smartphone apps upang mapabilis ang proseso. Parehong pampubliko at pribadong cloud ay nagbibigay ng mga serbisyo kabilang ang pag-access sa device, pamamahala ng device, anino ng device, at pagpapatakbo at pagpapanatili.
Ang pag-access sa device ng IoT cloud platform ay kailangang magbigay hindi lamang ng mga interface para sa pag-access ng device gamit ang mga protocol
Kabanata 2. Panimula at Pagsasanay ng Mga Proyekto ng IoT 11

gaya ng MQTT, CoAP, HTTPS, at WebSocket, kundi pati na rin ang function ng pagpapatunay ng seguridad ng device upang harangan ang mga peke at ilegal na device, na epektibong binabawasan ang panganib na makompromiso. Karaniwang sinusuportahan ng naturang pagpapatotoo ang iba't ibang mekanismo, kaya kapag ang mga device ay ginawa nang maramihan, kinakailangan na paunang italaga ang sertipiko ng device ayon sa napiling mekanismo ng pagpapatunay at sunugin ito sa mga device.
Pamamahala ng device Ang function ng pamamahala ng device na ibinigay ng mga IoT cloud platform ay hindi lamang makakatulong sa mga manufacturer na subaybayan ang activation status at online na status ng kanilang mga device sa real time, ngunit nagbibigay-daan din sa mga opsyon gaya ng pagdaragdag/pag-alis ng mga device, pagbawi, pagdaragdag/pagtanggal ng mga grupo, pag-upgrade ng firmware , at pamamahala ng bersyon.
Ang mga device shadow IoT cloud platform ay maaaring lumikha ng isang tuluy-tuloy na virtual na bersyon (device shadow) para sa bawat device, at ang status ng device shadow ay maaaring i-synchronize at makuha ng smartphone app o iba pang device sa pamamagitan ng Internet transmission protocols. Iniimbak ng device shadow ang pinakabagong iniulat na status at inaasahang status ng bawat device, at kahit na offline ang device, makukuha pa rin nito ang status sa pamamagitan ng pagtawag sa mga API. Nagbibigay ang anino ng device ng mga API na laging naka-on, na nagpapadali sa pagbuo ng mga smartphone app na nakikipag-ugnayan sa mga device.
Operasyon at pagpapanatili Ang O&M function ay may kasamang tatlong aspeto: · Pagpapakita ng istatistikal na impormasyon tungkol sa mga IoT device at notification. · Ang pamamahala ng log ay nagbibigay-daan sa pagkuha ng impormasyon tungkol sa gawi ng device, pataas / pababang daloy ng mensahe, at nilalaman ng mensahe. · Sinusuportahan ng pag-debug ng device ang paghahatid ng command, pag-update ng configuration, at pagsuri sa pakikipag-ugnayan sa pagitan ng mga IoT cloud platform at mga mensahe ng device.
2.2 Pagsasanay: Smart Light Project
Pagkatapos ng teoretikal na panimula sa bawat kabanata, makakahanap ka ng seksyon ng pagsasanay na nauugnay sa proyekto ng Smart Light upang matulungan kang makakuha ng hands-on na karanasan. Ang proyekto ay batay sa ESP32-C3 chip ng ESPressif at ESP RainMaker IoT Cloud Platform, at sumasaklaw sa wireless module hardware sa mga smart light na produkto, naka-embed na software para sa mga smart device batay sa ESP32C3, smartphone apps, at ESP RainMaker na pakikipag-ugnayan.
Source code Para sa mas mahusay na pag-aaral at pagbuo ng karanasan, ang proyekto sa aklat na ito ay opensourced. Maaari mong i-download ang source code mula sa aming GitHub repository sa https://github. com/espressif/book-esp32c3-iot-projects.
12 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

2.2.1 Istruktura ng Proyekto
Ang proyekto ng Smart Light ay binubuo ng tatlong bahagi: i. Mga smart light device batay sa ESP32-C3, responsable sa pakikipag-ugnayan sa mga IoT cloud platform, at pagkontrol sa switch, liwanag at temperatura ng kulay ng LED lamp kuwintas. ii. Mga smartphone app (kabilang ang mga tablet app na tumatakbo sa Android at iOS), na responsable para sa configuration ng network ng mga smart light na produkto, pati na rin ang pag-query at pagkontrol sa kanilang status.
iii. Isang IoT cloud platform batay sa ESP RainMaker. Para sa pagpapasimple, isinasaalang-alang namin ang IoT cloud platform at business server sa kabuuan sa aklat na ito. Ang mga detalye tungkol sa ESP RainMaker ay ibibigay sa Kabanata 3.
Ang pagsusulatan sa pagitan ng istraktura ng proyekto ng Smart Light at ang arkitektura ng IoT ay ipinapakita sa Figure 2.1.
Larawan 2.1. Istraktura ng smart light project
2.2.2 Mga Pag-andar ng Proyekto
Nahahati ayon sa istraktura, ang mga pag-andar ng bawat bahagi ay ang mga sumusunod. Mga aparatong matalinong ilaw
· Network configuration at koneksyon. · LED PWM control, gaya ng switch, brightness, color temperature, atbp. · Automation o scene control, hal, time switch. · Pag-encrypt at secure na boot ng Flash. · Pag-upgrade ng firmware at pamamahala ng bersyon.
Kabanata 2. Panimula at Pagsasanay ng Mga Proyekto ng IoT 13

Mga smartphone app · Network configuration at device binding. · Smart light na kontrol ng produkto, gaya ng switch, brightness, color temperature, atbp. · Automation o scene settings, hal, time switch. · Lokal / remote control. · Pagrehistro ng user, pag-login, atbp.
ESP RainMaker IoT cloud platform · Pinapagana ang pag-access ng IoT device. · Pagbibigay ng mga API para sa pagpapatakbo ng device na naa-access sa mga smartphone app. · Pag-upgrade ng firmware at pamamahala ng bersyon.
2.2.3 Paghahanda ng Hardware
Kung interesadong isagawa ang proyekto, kakailanganin mo rin ang sumusunod na hardware: mga matalinong ilaw, smartphone, Wi-Fi router, at isang computer na nakakatugon sa mga kinakailangan sa pag-install ng development environment. Mga matalinong ilaw
Ang mga matalinong ilaw ay isang bagong uri ng mga bombilya, na ang hugis ay kapareho ng pangkalahatang incandescent bulb. Ang matalinong ilaw ay binubuo ng capacitor step-down regulated power supply, wireless module (na may built-in na ESP32-C3), LED controller at RGB LED matrix. Kapag nakakonekta sa kapangyarihan, ang 15 V DC voltage output pagkatapos ng capacitor step-down, diode rectification, at regulasyon ay nagbibigay ng enerhiya sa LED controller at LED matrix. Ang LED controller ay maaaring awtomatikong magpadala ng mataas at mababang antas sa ilang partikular na agwat, na inililipat ang RGB LED matrix sa pagitan ng sarado (nakabukas ang mga ilaw) at bukas (nakapatay ang mga ilaw), upang makapaglabas ito ng cyan, dilaw, berde, lila, asul, pula, at puting ilaw. Ang wireless module ay responsable para sa pagkonekta sa Wi-Fi router, pagtanggap at pag-uulat ng katayuan ng mga matalinong ilaw, at pagpapadala ng mga command para makontrol ang LED.
Larawan 2.2. Isang kunwa na matalinong ilaw
Sa maagang pag-unlad stage, maaari mong gayahin ang isang matalinong ilaw gamit ang ESP32-C3DevKitM-1 board na konektado sa RGB LED lamp kuwintas (tingnan ang Larawan 2.2). Pero dapat
14 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

tandaan na hindi lang ito ang paraan para mag-assemble ng smart light. Ang disenyo ng hardware ng proyekto sa aklat na ito ay naglalaman lamang ng isang wireless module (na may built-in na ESP32-C3), ngunit hindi isang kumpletong smart light na disenyo ng hardware. Bilang karagdagan, gumagawa din ang Espressif ng ESP32-C3-based na audio development board na ESP32C3-Lyra para sa pagkontrol ng mga ilaw gamit ang audio. Ang board ay may mga interface para sa mga mikropono at speaker at maaaring kontrolin ang mga LED strip. Magagamit ito para sa pagbuo ng mga ultra-low-cost, highperformance na audio broadcaster at rhythm light strips. Ipinapakita ng Figure 2.3 ang isang ESP32-C3Lyra board na naka-link sa isang strip ng 40 LED lights.
Larawan 2.3. Na-link ang ESP32-C3-Lyra sa isang strip ng 40 LED na ilaw
Mga Smartphone (Android/iOS) Ang proyekto ng Smart Light ay nagsasangkot ng pagbuo ng isang smartphone app para sa pag-set up at pagkontrol ng mga produktong smart light.
Mga Wi-Fi router Ang Wi-Fi router ay nagko-convert ng mga wired network signal at mobile network signal sa wireless network signal, para sa mga computer, smartphone, tablet, at iba pang wireless na device upang kumonekta sa network. Para kay exampSa gayon, ang broadband sa bahay ay kailangan lamang na konektado sa isang Wi-Fi router upang makamit ang wireless networking ng mga Wi-Fi device. Ang pangunahing pamantayan ng protocol na sinusuportahan ng mga Wi-Fi router ay IEEE 802.11n, na may average na TxRate na 300 Mbps, o 600 Mbps sa maximum. Ang mga ito ay pabalik na katugma sa IEEE 802.11b at IEEE 802.11g. Ang ESP32-C3 chip ng Espressif ay sumusuporta sa IEEE 802.11b/g/n, kaya maaari kang pumili ng single-band (2.4 GHz) o dual-band (2.4 GHz at 5 GHz) na Wi-Fi router.
Ang isang computer (Linux/macOS/Windows) Development environment ay ipapakilala sa Kabanata 4. Kabanata 2. Panimula at Practice ng IoT Projects 15

2.2.4 Proseso ng Pag-unlad
Larawan 2.4. Mga hakbang sa pagbuo ng proyekto ng Smart Light
Disenyo ng hardware Ang disenyo ng hardware ng mga IoT device ay mahalaga sa isang proyekto ng IoT. Ang isang kumpletong proyekto ng matalinong ilaw ay inilaan upang makagawa ng alamp nagtatrabaho sa ilalim ng supply ng mains. Ang iba't ibang mga tagagawa ay gumagawa ng lamps ng iba't ibang mga estilo at uri ng driver, ngunit ang kanilang mga wireless module ay karaniwang may parehong function. Upang gawing simple ang proseso ng pagbuo ng proyekto ng Smart Ligh, sinasaklaw lamang ng aklat na ito ang disenyo ng hardware at software development ng mga wireless module.
Configuration ng IoT cloud platform Para magamit ang mga IoT cloud platform, kailangan mong i-configure ang mga proyekto sa backend, gaya ng paggawa ng mga produkto, paggawa ng mga device, pagtatakda ng mga property ng device, atbp.
Naka-embed na software development para sa mga IoT device Ipatupad ang mga inaasahang function sa ESP-IDF, SDK sa gilid ng device ng Espressif, kabilang ang pagkonekta sa mga IoT cloud platform, pagbuo ng mga LED driver, at pag-upgrade ng firmware.
Pag-unlad ng smartphone app Bumuo ng mga smartphone app para sa mga Android at iOS system upang maisakatuparan ang pagpaparehistro at pag-login ng user, kontrol ng device at iba pang mga function.
Pag-optimize ng IoT device Kapag nakumpleto na ang pangunahing pag-develop ng mga function ng IoT device, maaari kang pumunta sa mga gawain sa pag-optimize, gaya ng power optimization.
Pagsusuri sa mass production Magsagawa ng mga pagsusuri sa mass production ayon sa mga kaugnay na pamantayan, tulad ng pagsubok sa pag-andar ng kagamitan, pagsubok sa pagtanda, pagsubok sa RF, atbp.
Sa kabila ng mga hakbang na nakalista sa itaas, ang isang Smart Light na proyekto ay hindi kinakailangang napapailalim sa naturang pamamaraan dahil ang iba't ibang mga gawain ay maaari ding isagawa nang sabay-sabay. Para kay example, naka-embed na software at smartphone apps ay maaaring binuo nang magkatulad. Maaaring kailanganin ding ulitin ang ilang hakbang, gaya ng IoT device optimization at mass production testing.
16 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

2.3 Buod
Sa kabanatang ito, una naming ipinaliwanag ang mga pangunahing bahagi at functional na module ng isang proyekto ng IoT, pagkatapos ay ipinakilala ang Smart Light case para sa pagsasanay, na tumutukoy sa istraktura, mga function, paghahanda ng hardware, at proseso ng pagbuo nito. Ang mga mambabasa ay maaaring makakuha ng mga hinuha mula sa pagsasanay at maging kumpiyansa na magsagawa ng mga proyekto ng IoT na may pinakamababang pagkakamali sa hinaharap.
Kabanata 2. Panimula at Pagsasanay ng Mga Proyekto ng IoT 17

18 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Kabanata 3

Panimula

sa

ESP

RainMaker

Ang Internet of Things (IoT) ay nag-aalok ng walang katapusang mga posibilidad na baguhin ang paraan ng pamumuhay ng mga tao, ngunit ang pagbuo ng IoT engineering ay puno ng mga hamon. Sa mga pampublikong ulap, maaaring ipatupad ng mga tagagawa ng terminal ang paggana ng produkto sa pamamagitan ng mga sumusunod na solusyon:
Batay sa mga cloud platform ng mga provider ng solusyon Sa ganitong paraan, kailangan lang ng mga tagagawa ng terminal na idisenyo ang hardware ng produkto, pagkatapos ay ikonekta ang hardware sa cloud gamit ang ibinigay na module ng komunikasyon, at i-configure ang mga function ng produkto ayon sa mga alituntunin. Ito ay isang mahusay na diskarte dahil inaalis nito ang pangangailangan para sa server-side at application-side development at operations and maintenance (O&M). Pinapayagan nito ang mga tagagawa ng terminal na tumuon sa disenyo ng hardware nang hindi kinakailangang isaalang-alang ang pagpapatupad ng cloud. Gayunpaman, ang mga naturang solusyon (hal., firmware ng device at App) ay karaniwang hindi open source, kaya ang mga function ng produkto ay malilimitahan ng cloud platform ng provider na hindi mako-customize. Samantala, kabilang din sa cloud platform ang data ng user at device.
Batay sa mga produkto ng ulap Sa solusyon na ito, pagkatapos makumpleto ang disenyo ng hardware, ang mga tagagawa ng terminal ay hindi lamang kailangang magpatupad ng mga pag-andar ng ulap gamit ang isa o higit pang mga produkto ng ulap na ibinigay ng pampublikong ulap, ngunit kailangan ding i-link ang hardware sa cloud. Para kay example, para kumonekta sa Amazon Web Services (AWS), ang mga terminal manufacturer ay kailangang gumamit ng mga produkto ng AWS gaya ng Amazon API Gateway, AWS IoT Core, at AWS Lambda para paganahin ang pag-access ng device, remote control, pag-iimbak ng data, pamamahala ng user, at iba pang pangunahing function. Hindi lamang nito hinihiling sa mga tagagawa ng terminal na madaling gamitin at i-configure ang mga produkto ng cloud na may malalim na pag-unawa at mayamang karanasan, ngunit hinihiling din sa kanila na isaalang-alang ang gastos sa pagtatayo at pagpapanatili para sa una at mas bago.tagIto ay nagdudulot ng malalaking hamon sa enerhiya at mapagkukunan ng kumpanya.
Kung ikukumpara sa mga pampublikong ulap, ang mga pribadong ulap ay karaniwang binuo para sa mga partikular na proyekto at produkto. Ang mga pribadong cloud developer ay binibigyan ng pinakamataas na antas ng kalayaan sa disenyo ng protocol at pagpapatupad ng lohika ng negosyo. Ang mga tagagawa ng terminal ay maaaring gumawa ng mga produkto at disenyo ng mga scheme sa kalooban, at madaling isama at bigyang kapangyarihan ang data ng user. Pinagsasama ang mataas na seguridad, scalability at pagiging maaasahan ng pampublikong cloud sa advantages ng pribadong cloud, inilunsad ng Espressif ang ESP
19

RainMaker, isang malalim na pinagsamang pribadong solusyon sa ulap batay sa Amazon cloud. Maaaring mag-deploy ang mga user ng ESP RainMaker at bumuo ng pribadong cloud gamit ang isang AWS account.
3.1 Ano ang ESP RainMaker?
Ang ESP RainMaker ay isang kumpletong AIoT platform na binuo gamit ang maramihang mga mature na produkto ng AWS. Nagbibigay ito ng iba't ibang serbisyong kinakailangan para sa mass production gaya ng device cloud access, device upgrade, backend management, third-party na login, voice integration, at user management. Sa pamamagitan ng paggamit ng Serverless Application Repository (SAR) na ibinigay ng AWS, mabilis na mai-deploy ng mga terminal manufacturer ang ESP RainMaker sa kanilang mga AWS account, na mahusay sa oras at madaling patakbuhin. Pinamamahalaan at pinapanatili ng Espressif, ang SAR na ginagamit ng ESP RainMaker ay tumutulong sa mga developer na bawasan ang mga gastos sa pagpapanatili ng ulap at pabilisin ang pagbuo ng mga produkto ng AIoT, sa gayon ay bumubuo ng ligtas, matatag, at nako-customize na mga solusyon sa AIoT. Ipinapakita ng Figure 3.1 ang arkitektura ng ESP RainMaker.
Larawan 3.1. Arkitektura ng ESP RainMaker
Ang pampublikong server ng ESP RainMaker ng Espressif ay libre para sa lahat ng mahilig sa ESP, gumagawa, at tagapagturo para sa pagsusuri ng solusyon. Maaaring mag-log in ang mga developer gamit ang Apple, Google, o GitHub account, at mabilis na bumuo ng sarili nilang mga prototype ng IoT application. Pinagsasama ng pampublikong server ang Alexa at Google Home, at nagbibigay ng mga serbisyo sa pagkontrol ng boses, na sinusuportahan ng Alexa Skill at Google Actions. Pinapatakbo din ng mga third party ang semantic recognition function nito. Tumutugon lang ang mga RainMaker IoT device sa mga partikular na pagkilos. Para sa kumpletong listahan ng mga sinusuportahang voice command, pakitingnan ang mga third-party na platform. Bilang karagdagan, nag-aalok ang Espressif ng pampublikong RainMaker App para makontrol ng mga user ang mga produkto sa pamamagitan ng mga smartphone. 20 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

3.2 Ang Pagpapatupad ng ESP RainMaker
Gaya ng ipinapakita sa Figure 3.2, ang ESP RainMaker ay binubuo ng apat na bahagi: · Serbisyo sa Pag-claim, na nagbibigay-daan sa mga RainMaker device na dynamic na makakuha ng mga certificate. · RainMaker Cloud (kilala rin bilang cloud backend), na nagbibigay ng mga serbisyo tulad ng pag-filter ng mensahe, pamamahala ng user, pag-iimbak ng data, at mga pagsasama ng third-party. · RainMaker Agent, na nagbibigay-daan sa mga RainMaker device na kumonekta sa RainMaker Cloud. · RainMaker Client (RainMaker App o CLI scripts), para sa provisioning, paggawa ng user, pag-uugnay at kontrol ng device, atbp.
Larawan 3.2. Istraktura ng ESP RainMaker
Nagbibigay ang ESP RainMaker ng kumpletong hanay ng mga tool para sa pagbuo ng produkto at mass production, kabilang ang: RainMaker SDK
Ang RainMaker SDK ay batay sa ESP-IDF at nagbibigay ng source code ng device-side agent at mga kaugnay na C API para sa pag-develop ng firmware. Kailangan lang isulat ng mga developer ang logic ng application at iwanan ang iba sa framework ng RainMaker. Para sa higit pang impormasyon tungkol sa mga C API, pakibisita ang https://bookc3.espressif.com/rm/c-api-reference. RainMaker App Ang pampublikong bersyon ng RainMaker App ay nagbibigay-daan sa mga developer na kumpletuhin ang provisioning ng device, at kontrolin at i-query ang status ng mga device (hal., mga produkto ng smart lighting). Available ito sa parehong iOS at Android app store. Para sa higit pang mga detalye, mangyaring sumangguni sa Kabanata 10. REST APIs REST APIs ay tumutulong sa mga user na bumuo ng kanilang sariling mga application na katulad ng RainMaker App. Para sa karagdagang impormasyon, pakibisita ang https://swaggerapis.rainmaker.espressif.com/.
Kabanata 3. Panimula sa ESP RainMaker 21

Mga Python API Ang isang Python-based na CLI, na kasama ng RainMaker SDK, ay ibinigay upang ipatupad ang lahat ng mga function na katulad ng mga feature ng smartphone. Para sa higit pang impormasyon tungkol sa mga Python API, pakibisita ang https://bookc3.espressif.com/rm/python-api-reference.
Ang Admin CLI Admin CLI, na may mas mataas na antas ng access, ay ibinibigay para sa pribadong deployment ng ESP RainMaker upang bumuo ng mga certificate ng device nang maramihan.
3.2.1 Serbisyo sa Pag-claim
Ang lahat ng komunikasyon sa pagitan ng mga RainMaker device at ng cloud backend ay isinasagawa sa pamamagitan ng MQTT+TLS. Sa konteksto ng ESP RainMaker, ang “Claiming” ay ang proseso kung saan kumukuha ang mga device ng mga certificate mula sa Claiming Service para kumonekta sa cloud backend. Tandaan na ang Serbisyo sa Pag-claim ay naaangkop lamang sa pampublikong serbisyo ng RainMaker, habang para sa pribadong deployment, ang mga certificate ng device ay kailangang mabuo nang maramihan sa pamamagitan ng Admin CLI. Sinusuportahan ng ESP RainMaker ang tatlong uri ng Serbisyo sa Pag-claim: Self Claiming
Kinukuha mismo ng device ang mga certificate sa pamamagitan ng isang secret key na na-pre-program sa eFuse pagkatapos kumonekta sa Internet. Host Driven Claiming Ang mga certificate ay nakuha mula sa development host gamit ang RainMaker account. Tinulungang Pag-claim Ang mga sertipiko ay nakukuha sa pamamagitan ng mga application ng smartphone sa panahon ng provisioning.
3.2.2 Ahente ng RainMaker
Larawan 3.3. Structure ng RainMaker SDK Ang pangunahing function ng RainMaker Agent ay magbigay ng koneksyon at tulungan ang application layer na iproseso ang uplink/downlink cloud data. Ito ay binuo sa pamamagitan ng RainMaker SDK 22 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

at binuo batay sa napatunayang balangkas ng ESP-IDF, gamit ang mga bahagi ng ESP-IDF gaya ng RTOS, NVS, at MQTT. Ipinapakita ng Figure 3.3 ang istruktura ng RainMaker SDK.
Kasama sa RainMaker SDK ang dalawang pangunahing tampok.
Koneksyon
i. Pakikipagtulungan sa Serbisyo sa Pag-claim upang makakuha ng mga sertipiko ng device.
ii. Kumokonekta sa cloud backend gamit ang secure na MQTT protocol para magbigay ng malayuang koneksyon at magpatupad ng remote control, pag-uulat ng mensahe, pamamahala ng user, pamamahala ng device, atbp. Ginagamit nito ang MQTT component sa ESP-IDF bilang default at nagbibigay ng abstraction layer upang mag-interface sa iba mga stack ng protocol.
iii. Nagbibigay ng bahagi ng pag-provision ng wifi para sa koneksyon at pag-provision ng Wi-Fi, esp https ota component para sa mga pag-upgrade ng OTA, at esp ng lokal na ctrl component para sa pagtuklas at koneksyon ng lokal na device. Ang lahat ng mga layuning ito ay maaaring makamit sa pamamagitan ng simpleng pagsasaayos.
Pagproseso ng data
i. Pag-iimbak ng mga certificate ng device na ibinigay ng Serbisyo sa Pag-claim at ang data na kailangan kapag nagpapatakbo ng RainMaker, bilang default gamit ang interface na ibinigay ng bahagi ng nvs flash, at pagbibigay ng mga API para sa mga developer para sa direktang paggamit.
ii. Gamit ang mekanismo ng callback upang iproseso ang uplink/downlink cloud data at awtomatikong i-unblock ang data sa layer ng application para sa madaling pagproseso ng mga developer. Para kay exampSa gayon, ang RainMaker SDK ay nagbibigay ng mga rich interface para sa pagtatatag ng data ng TSL (Thing Specification Language), na kinakailangan upang tukuyin ang mga modelo ng TSL upang ilarawan ang mga IoT device at ipatupad ang mga function tulad ng timing, countdown, at voice control. Para sa mga pangunahing interactive na feature tulad ng timing, ang RainMaker SDK ay nagbibigay ng isang development-free na solusyon na maaaring paganahin lamang kapag kinakailangan. Pagkatapos, direktang ipoproseso ng RainMaker Agent ang data, ipapadala ito sa cloud sa pamamagitan ng nauugnay na paksa ng MQTT, at ibabalik ang mga pagbabago sa data sa cloud backend sa pamamagitan ng mekanismo ng callback.
3.2.3 Cloud Backend
Ang cloud backend ay binuo sa AWS Serverless Computing at nakamit sa pamamagitan ng AWS Cognito (identity management system), Amazon API Gateway, AWS Lambda (serverless computing service), Amazon DynamoDB (NoSQL database), AWS IoT Core (IoT access core na nagbibigay ng MQTT access at pag-filter ng panuntunan), Amazon Simple Email Service (SES simpleng serbisyo ng mail), Amazon CloudFront (mabilis na paghahatid ng network), Amazon Simple Queue Service (SQS message queuing), at Amazon S3 (bucket storage service). Ito ay naglalayong i-optimize ang scalability at seguridad. Sa ESP RainMaker, maaaring pamahalaan ng mga developer ang mga device nang hindi kinakailangang magsulat ng code sa cloud. Ang mga mensaheng iniulat ng mga device ay malinaw na ipinapadala sa
Kabanata 3. Panimula sa ESP RainMaker 23

mga kliyente ng aplikasyon o iba pang mga serbisyo ng third-party. Ipinapakita sa talahanayan 3.1 ang mga produkto at function ng AWS cloud na ginagamit sa cloud backend, na may higit pang mga produkto at feature na ginagawa.
Talahanayan 3.1. AWS cloud na mga produkto at function na ginagamit ng cloud backend

AWS Cloud Product na Ginamit ng RainMaker

Function

AWS Cognito

Pamamahala ng mga kredensyal ng user at pagsuporta sa mga third-party na pag-log in

AWS Lambda

Pagpapatupad ng pangunahing lohika ng negosyo ng cloud backend

Amazon Timestream Pag-iimbak ng data ng serye ng oras

Amazon DynamoDB Pag-iimbak ng pribadong impormasyon ng mga customer

AWS IoT Core

Pagsuporta sa komunikasyon ng MQTT

Amazon SES

Nagbibigay ng mga serbisyo sa pagpapadala ng email

Amazon CloudFront Pinapabilis ang pamamahala ng backend webaccess sa site

Amazon SQS

Pagpasa ng mga mensahe mula sa AWS IoT Core

3.2.4 Kliyente ng RainMaker
Ang mga kliyente ng RainMaker, gaya ng App at CLI, ay nakikipag-ugnayan sa cloud backend sa pamamagitan ng REST API. Ang detalyadong impormasyon at mga tagubilin tungkol sa mga REST API ay matatagpuan sa dokumentasyong Swagger na ibinigay ng Espressif. Available ang mobile application client ng RainMaker para sa parehong iOS at Android system. Pinapayagan nito ang provisioning, kontrol, at pagbabahagi ng device, pati na rin ang paggawa at pagpapagana ng mga gawain sa pag-countdown at pagkonekta sa mga platform ng third-party. Maaari itong awtomatikong mag-load ng UI at mga icon ayon sa configuration na iniulat ng mga device at ganap na maipakita ang TSL ng device.
Para kay exampKung ang isang matalinong ilaw ay binuo sa RainMaker SDK-provided examples, ang icon at UI ng bulb light ay awtomatikong mailo-load kapag nakumpleto na ang provisioning. Maaaring baguhin ng mga user ang kulay at liwanag ng liwanag sa pamamagitan ng interface at makamit ang kontrol ng third-party sa pamamagitan ng pag-link ng Alexa Smart Home Skill o Google Smart Home Actions sa kanilang mga ESP RainMaker account. Ipinapakita ng Figure 3.4 ang icon at UI halamples ng bulb light ayon sa pagkakabanggit sa Alexa, Google Home, at ESP RainMaker App.

24 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

(a) Halample – Alexa

(b) Halample – Google Home

(c) Halample – ESP RainMaker
Larawan 3.4. Halampkaunting icon at UI ng bulb light sa Alexa, Google Home, at ESP RainMaker App
3.3 Pagsasanay: Mga Pangunahing Punto para sa Pagbuo sa ESP RainMaker
Kapag nakumpleto na ang layer ng driver ng device, maaaring magsimula ang mga developer na gumawa ng mga modelo ng TSL at magproseso ng data ng downlink gamit ang mga API na ibinigay ng RainMaker SDK, at paganahin ang mga pangunahing serbisyo ng ESP RainMaker batay sa kahulugan at mga kinakailangan ng produkto.
Kabanata 3. Panimula sa ESP RainMaker 25

Ipapaliwanag ng Seksyon 9.4 ng aklat na ito ang pagpapatupad ng LED smart light sa RainMaker. Sa panahon ng pag-debug, maaaring gamitin ng mga developer ang mga CLI tool sa RainMaker SDK para makipag-ugnayan sa smart light (o tumawag sa REST API mula sa Swagger).
Idetalye ng Kabanata 10 ang paggamit ng REST API sa pagbuo ng mga smartphone application. Ang mga OTA upgrade ng LED smart lights ay sasaklawin sa Kabanata 11. Kung pinagana ng mga developer ang remote monitoring ng ESP Insights, ipapakita ng backend ng pamamahala ng ESP RainMaker ang data ng ESP Insights. Ang mga detalye ay ilalahad sa Kabanata 15.
Sinusuportahan ng ESP RainMaker ang pribadong deployment, na naiiba sa pampublikong RainMaker server sa mga sumusunod na paraan:
Serbisyo sa Pag-claim Upang makabuo ng mga certificate sa mga pribadong deployment, kinakailangang gamitin ang RainMaker Admin CLI sa halip na Mag-claim. Sa pampublikong server, dapat bigyan ang mga developer ng mga karapatan ng admin upang ipatupad ang pag-upgrade ng firmware, ngunit hindi ito kanais-nais sa mga komersyal na deployment. Samakatuwid, walang hiwalay na serbisyo sa pagpapatotoo ang maaaring ibigay para sa self-claim, o mga karapatan ng admin para sa pag-claim na hinimok ng host o tinulungan.
Mga app ng telepono Sa mga pribadong deployment, kailangang i-configure at i-compile ang mga application nang hiwalay upang matiyak na hindi interoperable ang mga system ng account.
Mga 3rd party na login at voice integration Kailangang magkahiwalay na i-configure ng mga Developer sa pamamagitan ng Google at Apple Developer account para ma-enable ang mga 3rd party na login, pati na rin ang Alexa Skill at Google Voice Assistant integration.
TIP Para sa mga detalye tungkol sa cloud deployment, pakibisita ang https://customer.rainmaker.espressif. com. Sa mga tuntunin ng firmware, ang paglipat mula sa pampublikong server patungo sa pribadong server ay nangangailangan lamang ng pagpapalit ng mga certificate ng device, na lubos na nagpapahusay sa kahusayan sa paglilipat at nagpapababa sa gastos ng paglipat at pangalawang pag-debug.
3.4 Mga Tampok ng ESP RainMaker
Pangunahing naka-target ang mga feature ng ESP RainMaker sa tatlong aspeto – pamamahala ng user, end user, at admin. Ang lahat ng mga tampok ay sinusuportahan sa parehong pampubliko at pribadong mga server maliban kung iba ang nakasaad.
3.4.1 Pamamahala ng Gumagamit
Ang mga tampok sa pamamahala ng gumagamit ay nagbibigay-daan sa mga end user na magrehistro, mag-log in, magpalit ng mga password, kumuha ng mga password, atbp.
26 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Magrehistro at mag-log in Ang mga paraan ng pagpaparehistro at pag-log in na sinusuportahan ng RainMaker ay kinabibilangan ng: · Email id + Password · Numero ng telepono + Password · Google account · Apple account · GitHub account (pampublikong server lamang) · Amazon account (pribadong server lamang)
TANDAAN Mag-sign up gamit ang Google/Amazon ay nagbabahagi ng email address ng user sa RainMaker. Mag-sign up gamit ang Apple ay nagbabahagi ng dummy address na itinalaga ng Apple para sa user na partikular para sa serbisyo ng RainMaker. Awtomatikong gagawin ang isang RainMaker account para sa mga user na nagsa-sign in gamit ang isang Google, Apple, o Amazon account sa unang pagkakataon.
Baguhin ang password Valid lamang para sa Email id/Phone number based logins. Mala-log out ang lahat ng iba pang aktibong session pagkatapos mapalitan ang password. Alinsunod sa pag-uugali ng AWS Cognito, ang mga naka-log out na session ay maaaring manatiling aktibo hanggang 1 oras.
Kunin ang password Valid lamang para sa Email id/Phone number based logins.
3.4.2 Mga Tampok ng End User
Kasama sa mga feature na bukas sa mga end user ang lokal at remote control at pagsubaybay, pag-iiskedyul, pagpapangkat ng device, pagbabahagi ng device, push notification, at pagsasama ng third-party.
Remote control at pagsubaybay · Configuration ng query, mga value ng parameter, at status ng koneksyon para sa isa o lahat ng device. · Itakda ang mga parameter para sa isa o maramihang mga aparato.
Lokal na kontrol at pagsubaybay Kailangang konektado ang mobile phone at ang device sa parehong network para sa lokal na kontrol.
Pag-iskedyul · Paunang itinakda ng mga user ang ilang partikular na pagkilos sa isang partikular na oras. · Walang koneksyon sa Internet na kinakailangan para sa aparato habang isinasagawa ang iskedyul. · Isang beses o ulitin (sa pamamagitan ng pagtukoy ng mga araw) para sa isa o maramihang mga aparato.
Pagpapangkat ng device Sinusuportahan ang multi-level abstract grouping Maaaring gamitin ang metadata ng grupo para gumawa ng istraktura ng Home Room.
Kabanata 3. Panimula sa ESP RainMaker 27

Pagbabahagi ng device Maaaring ibahagi ang isa o higit pang device sa isa o higit pang user.
Mga push notification Ang mga end user ay makakatanggap ng mga push notification para sa mga kaganapan tulad ng · Bagong (mga) device na idinagdag/inalis · Nakakonekta ang device sa cloud · Nadiskonekta ang device sa cloud · Mga kahilingan sa pagbabahagi ng device na ginawa/tinanggap/tinanggihan · Mga mensahe ng alerto na iniulat ng mga device
Ang mga pagsasama ng third party na Alexa at Google Voice Assistant ay sinusuportahan upang kontrolin ang mga RainMaker device, kabilang ang mga ilaw, switch, socket, fan, at temperature sensor.
3.4.3 Mga Tampok ng Admin
Binibigyang-daan ng mga feature ng admin ang mga administrator na ipatupad ang pagpaparehistro ng device, pagpapangkat ng device, at mga upgrade sa OTA, at sa view istatistika at data ng ESP Insights.
Pagpaparehistro ng device Bumuo ng mga certificate ng device at magparehistro sa Admin CLI (pribadong server lang).
Pagpapangkat ng device Gumawa ng abstract o structured na mga grupo batay sa impormasyon ng device (pribadong server lang).
Over-the-Air (OTA) na mga upgrade Mag-upload ng firmware batay sa bersyon at modelo, sa isa o higit pang device o isang grupong Monitor, kanselahin, o i-archive ang mga trabaho sa OTA.
View mga istatistika ViewKasama sa mga istatistikang magagawa ang: · Mga pagpaparehistro ng device (mga sertipiko na inirehistro ng admin) · Mga pag-activate ng device (nakakonekta ang device sa unang pagkakataon) · Mga account ng user · Pag-uugnay ng user-device
View Data ng ESP Insights ViewKasama sa data ng ESP Insights ang: · Mga error, babala, at custom na log · Mga ulat at pagsusuri sa pag-crash · Mga dahilan ng pag-reboot · Mga sukatan tulad ng paggamit ng memory, RSSI, atbp. · Mga custom na sukatan at variable
28 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

3.5 Buod
Sa kabanatang ito, ipinakilala namin ang ilang pangunahing pagkakaiba sa pagitan ng pampublikong RainMaker deployment at pribadong deployment. Ang pribadong ESP RainMaker na solusyon na inilunsad ng Espressif ay lubos na maaasahan at napapalawak. Ang lahat ng ESP32 series chips ay konektado at inangkop sa AWS, na lubos na nakakabawas sa gastos. Maaaring tumuon ang mga developer sa prototype na pag-verify nang hindi kinakailangang matuto tungkol sa mga produkto ng AWS cloud. Ipinaliwanag din namin ang pagpapatupad at mga tampok ng ESP RainMaker, at ilang mahahalagang punto para sa pag-unlad gamit ang platform.
I-scan para i-download ang ESP RainMaker para sa Android I-scan para i-download ang ESP RainMaker para sa iOS
Kabanata 3. Panimula sa ESP RainMaker 29

30 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Pag-set Up ng Kabanata 4 Development Environment
Nakatuon ang kabanatang ito sa ESP-IDF, ang opisyal na balangkas ng pagbuo ng software para sa ESP32-C3. Ipapaliwanag namin kung paano i-set up ang kapaligiran sa iba't ibang operating system, at ipakilala ang istruktura ng proyekto at bumuo ng system ng ESP-IDF, pati na rin ang paggamit ng mga nauugnay na tool sa pag-develop. Pagkatapos ay ipapakita namin ang proseso ng pag-compile at pagpapatakbo ng isang example proyekto, habang nag-aalok ng isang detalyadong paliwanag ng output log sa bawat stage.
4.1 Tapos na ang ESP-IDFview
Ang ESP-IDF (Espressif IoT Development Framework) ay isang one-stop IoT development framework na ibinigay ng Espressif Technology. Gumagamit ito ng C/C++ bilang pangunahing wika ng pag-unlad at sumusuporta sa cross-compilation sa ilalim ng mga pangunahing operating system gaya ng Linux, Mac, at Windows. Ang exampAng mga programang kasama sa aklat na ito ay binuo gamit ang ESP-IDF, na nag-aalok ng mga sumusunod na tampok: · SoC system-level drivers. Kasama sa ESP-IDF ang mga driver para sa ESP32, ESP32-S2, ESP32-C3,
at iba pang chips. Ang mga driver na ito ay sumasaklaw sa peripheral low level (LL) library, hardware abstraction layer (HAL) library, RTOS support at upper-layer driver software, atbp. · Mga mahahalagang bahagi. Isinasama ng ESP-IDF ang mga pangunahing sangkap na kinakailangan para sa pag-unlad ng IoT. Kabilang dito ang maraming network protocol stack gaya ng HTTP at MQTT, isang power management framework na may dynamic frequency modulation, at mga feature tulad ng Flash Encryption at Secure Boot, atbp. · Mga tool sa pag-develop at produksyon. Nagbibigay ang ESP-IDF ng mga karaniwang ginagamit na tool para sa pagbuo, flash, at pag-debug sa panahon ng pag-develop at mass production (tingnan ang Figure 4.1), tulad ng sistema ng gusali batay sa CMake, ang cross-compilation tool chain batay sa GCC, at ang JTAG debugging tool batay sa OpenOCD, atbp. Dapat tandaan na ang ESP-IDF code ay pangunahing sumusunod sa Apache 2.0 open-source na lisensya. Maaaring bumuo ang mga user ng personal o komersyal na software nang walang mga paghihigpit habang sumusunod sa mga tuntunin ng open-source na lisensya. Bukod pa rito, binibigyan ang mga user ng permanenteng lisensya ng patent nang walang bayad, nang walang obligasyon na i-open-source ang anumang mga pagbabagong ginawa sa source code.
31

Larawan 4.1.

Pagbuo, pag-flash, at pag-debug-

ging tool para sa pag-unlad at mass production

4.1.1 Mga Bersyon ng ESP-IDF
Ang ESP-IDF code ay naka-host sa GitHub bilang isang open-source na proyekto. Sa kasalukuyan, mayroong tatlong pangunahing bersyon na magagamit: v3, v4, at v5. Ang bawat pangunahing bersyon ay karaniwang naglalaman ng iba't ibang mga subversion, tulad ng v4.2, v4.3, at iba pa. Tinitiyak ng Espressif Systems ang isang 30-buwang suporta para sa mga pag-aayos ng bug at mga patch ng seguridad para sa bawat inilabas na sub-bersyon. Samakatuwid, ang mga rebisyon ng mga subversion ay regular ding inilalabas, tulad ng v4.3.1, v4.2.2, atbp. Ipinapakita ng Talahanayan 4.1 ang katayuan ng suporta ng iba't ibang bersyon ng ESP-IDF para sa mga chip ng Espressif, na nagsasaad kung ang mga ito ay nasa preview stage (nag-aalok ng suporta para sa preview mga bersyon, na maaaring kulang sa ilang partikular na feature o dokumentasyon) o opisyal na sinusuportahan.

Talahanayan 4.1. Katayuan ng suporta ng iba't ibang bersyon ng ESP-IDF para sa mga chip ng Espressif

Serye ESP32 ESP32-S2 ESP32-C3 ESP32-S3 ESP32-C2 ESP32-H2

v4.1 suportado

v4.2 suportado suportado

v4.3 suportado suportado suportado

v4.4 suportado suportado suportado suportado
preview

v5.0 suportado suportado suportado suportado suportado preview

32 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Ang pag-ulit ng mga pangunahing bersyon ay kadalasang nagsasangkot ng mga pagsasaayos sa istraktura ng balangkas at mga update sa sistema ng compilation. Para kay exampAt, ang pangunahing pagbabago mula v3.* hanggang v4.* ay ang unti-unting paglipat ng build system mula sa Make hanggang CMake. Sa kabilang banda, ang pag-ulit ng mga menor de edad na bersyon ay karaniwang nangangailangan ng pagdaragdag ng mga bagong feature o suporta para sa mga bagong chip.
Mahalagang makilala at maunawaan ang kaugnayan sa pagitan ng mga stable na bersyon at mga sangay ng GitHub. Ang mga bersyon na may label na v*.* o v*.*.* ay kumakatawan sa mga matatag na bersyon na nakapasa sa kumpletong panloob na pagsubok ng Espressif. Kapag naayos na, ang code, tool chain, at release na mga dokumento para sa parehong bersyon ay mananatiling hindi nagbabago. Gayunpaman, ang mga sangay ng GitHub (hal., ang release/v4.3 branch) ay sumasailalim sa mga madalas na code commit, madalas araw-araw. Samakatuwid, maaaring magkaiba ang dalawang snippet ng code sa ilalim ng parehong sangay, na nangangailangan ng mga developer na agad na i-update ang kanilang code nang naaayon.
4.1.2 ESP-IDF Git Workflow
Ang Espressif ay sumusunod sa isang partikular na Git workflow para sa ESP-IDF, na nakabalangkas tulad ng sumusunod:
· Ang mga bagong pagbabago ay ginawa sa master branch, na nagsisilbing pangunahing development branch. Ang bersyon ng ESP-IDF sa master branch ay palaging may dalang -dev tag upang ipahiwatig na kasalukuyan itong ginagawa, gaya ng v4.3-dev. Ang mga pagbabago sa master branch ay unang reviewed at sinubukan sa panloob na repositoryo ng Espressif, at pagkatapos ay itinulak sa GitHub pagkatapos makumpleto ang awtomatikong pagsubok.
· Kapag nakumpleto na ng bagong bersyon ang feature development sa master branch at natugunan ang pamantayan para sa pagpasok ng beta testing, lilipat ito sa bagong branch, gaya ng release/v4.3. Bilang karagdagan, ang bagong sangay na ito ay tagged bilang isang pre-release na bersyon, tulad ng v4.3-beta1. Maaaring sumangguni ang mga developer sa GitHub platform para ma-access ang kumpletong listahan ng mga branch at tags para sa ESP-IDF. Mahalagang tandaan na ang beta na bersyon (pre-release na bersyon) ay maaari pa ring magkaroon ng malaking bilang ng mga kilalang isyu. Habang ang bersyon ng beta ay sumasailalim sa patuloy na pagsubok, ang mga pag-aayos ng bug ay idinaragdag sa bersyong ito at sa master branch nang sabay-sabay. Samantala, maaaring nagsimula na ang master branch sa pagbuo ng mga bagong feature para sa susunod na bersyon. Kapag halos kumpleto na ang pagsubok, ang isang release candidate (rc) label ay idaragdag sa branch, na nagsasaad na ito ay isang potensyal na kandidato para sa opisyal na release, gaya ng v4.3-rc1. Sa stage, ang sangay ay nananatiling isang pre-release na bersyon.
· Kung walang malalaking bug ang natuklasan o naiulat, ang pre-release na bersyon sa kalaunan ay makakatanggap ng major version label (hal, v5.0) o isang minor na label na bersyon (hal, v4.3) at magiging opisyal na bersyon ng release, na nakadokumento. sa pahina ng mga tala sa paglabas. Kasunod nito, ang anumang mga bug na natukoy sa bersyong ito ay naayos sa sangay ng paglabas. Pagkatapos makumpleto ang manu-manong pagsubok, bibigyan ang sangay ng label ng bersyon ng pag-aayos ng bug (hal, v4.3.2), na makikita rin sa pahina ng mga tala sa paglabas.
Kabanata 4. Pag-set up ng Development Environment 33

4.1.3 Pagpili ng Angkop na Bersyon
Dahil opisyal na sinimulan ng ESP-IDF ang pagsuporta sa ESP32-C3 mula sa bersyong v4.3, at ang v4.4 ay hindi pa opisyal na inilabas sa panahon ng pagsulat ng aklat na ito, ang bersyon na ginamit sa aklat na ito ay v4.3.2, na isang binagong bersyon ng v4.3. Gayunpaman, mahalagang tandaan na sa oras na basahin mo ang aklat na ito, maaaring available na ang v4.4 o mas bagong mga bersyon. Kapag pumipili ng bersyon, inirerekomenda namin ang sumusunod:
· Para sa mga entry-level na developer, ipinapayong piliin ang stable v4.3 na bersyon o ang binagong bersyon nito, na nakaayon sa datingample bersyon na ginamit sa aklat na ito.
· Para sa mass production na layunin, inirerekumenda na gamitin ang pinakabagong stable na bersyon upang makinabang mula sa pinaka-up-to-date na teknikal na suporta.
· Kung balak mong mag-eksperimento sa mga bagong chips o tuklasin ang mga bagong feature ng produkto, mangyaring gamitin ang master branch. Ang pinakabagong bersyon ay naglalaman ng lahat ng pinakabagong mga tampok, ngunit tandaan na maaaring may kilala o hindi kilalang mga bug na naroroon.
· Kung ang stable na bersyon na ginagamit ay hindi kasama ang ninanais na mga bagong feature at gusto mong bawasan ang mga panganib na nauugnay sa master branch, isaalang-alang ang paggamit ng kaukulang release branch, tulad ng release/v4.4 branch. Ang GitHub repository ng Espressif ay unang gagawa ng release/v4.4 branch at pagkatapos ay ilalabas ang stable v4.4 na bersyon batay sa isang partikular na historikal na snapshot ng branch na ito, pagkatapos makumpleto ang lahat ng feature development at testing.
4.1.4 Lampasview ng ESP-IDF SDK Directory
Ang ESP-IDF SDK ay binubuo ng dalawang pangunahing direktoryo: esp-idf at .espressif. Ang dating ay naglalaman ng source code ng ESP-IDF repository files at compilation script, habang ang huli ay pangunahing nag-iimbak ng mga compilation tool chain at iba pang software. Ang pagiging pamilyar sa dalawang direktoryo na ito ay makakatulong sa mga developer na mas mahusay na magamit ang mga magagamit na mapagkukunan at mapabilis ang proseso ng pagbuo. Ang istraktura ng direktoryo ng ESP-IDF ay inilarawan sa ibaba:
(1) Direktoryo ng code ng repositoryo ng ESP-IDF (/esp/esp-idf), tulad ng ipinapakita sa Figure 4.2.
a. Mga bahagi ng direktoryo ng bahagi
Ang pangunahing direktoryo na ito ay nagsasama ng maraming mahahalagang bahagi ng software ng ESP-IDF. Walang project code ang maaaring i-compile nang hindi umaasa sa mga bahagi sa loob ng direktoryong ito. Kasama dito ang suporta sa driver para sa iba't ibang mga chip ng Espressif. Mula sa LL library at HAL library interface para sa mga peripheral hanggang sa upper-level na Driver at Virtual File System (VFS) layer support, maaaring piliin ng mga developer ang naaangkop na mga bahagi sa iba't ibang antas para sa kanilang mga pangangailangan sa pag-unlad. Sinusuportahan din ng ESP-IDF ang maramihang karaniwang mga stack ng protocol ng network tulad ng TCP/IP, HTTP, MQTT, WebSocket, atbp. Ang mga developer ay maaaring gumamit ng mga pamilyar na interface tulad ng Socket upang bumuo ng mga network application. Ang mga bahagi ay nagbibigay ng pag-unawa-
34 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Larawan 4.2. Direktoryo ng code ng repositoryo ng ESP-IDF
sive functionality at madaling maisama sa mga application, na nagbibigay-daan sa mga developer na tumutok lamang sa lohika ng negosyo. Ang ilang mga karaniwang bahagi ay kinabibilangan ng: · driver: Ang component na ito ay naglalaman ng mga peripheral driver program para sa iba't ibang Espressif
serye ng chip, tulad ng GPIO, I2C, SPI, UART, LEDC (PWM), atbp. Ang mga programa ng peripheral driver sa bahaging ito ay nag-aalok ng mga chip-independent na abstract na interface. Ang bawat peripheral ay may isang karaniwang header file (gaya ng gpio.h), inaalis ang pangangailangang harapin ang iba't ibang tanong sa suporta na partikular sa chip. · esp_wifi: Ang Wi-Fi, bilang isang espesyal na peripheral, ay itinuturing bilang isang hiwalay na bahagi. Kabilang dito ang maraming API gaya ng pagsisimula ng iba't ibang Wi-Fi driver mode, configuration ng parameter, at pagpoproseso ng kaganapan. Ang ilang partikular na function ng component na ito ay ibinibigay sa anyo ng mga static link library. Nagbibigay din ang ESP-IDF ng komprehensibong dokumentasyon ng driver para sa kadalian ng paggamit.
Kabanata 4. Pag-set up ng Development Environment 35

· freertos: Ang bahaging ito ay naglalaman ng kumpletong FreeRTOS code. Bukod sa pagbibigay ng komprehensibong suporta para sa operating system na ito, pinalawak din ng Espressif ang suporta nito sa dual-core chips. Para sa dual-core chips tulad ng ESP32 at ESP32-S3, ang mga user ay maaaring gumawa ng mga gawain sa mga partikular na core.
b. Mga doc ng direktoryo ng dokumento
Naglalaman ang direktoryo na ito ng mga dokumento sa pag-develop na nauugnay sa ESP-IDF, kasama ang Gabay sa Pagsisimula, Manual ng Reference ng API, Gabay sa Pag-develop, atbp.
TANDAAN Matapos ma-compile ng mga automated na tool, ang mga nilalaman ng direktoryo na ito ay na-deploy sa https://docs.espressif.com/projects/esp-idf. Pakitiyak na ilipat ang target ng dokumento sa ESP32-C3 at piliin ang tinukoy na bersyon ng ESP-IDF.
c. Mga tool sa script
Ang direktoryo na ito ay naglalaman ng mga karaniwang ginagamit na compilation na front-end na mga tool tulad ng idf.py, at ang monitor terminal tool na idf_monitor.py, atbp. Ang sub-directory na cmake ay naglalaman din ng core script files ng compilation system, nagsisilbing pundasyon para sa pagpapatupad ng ESP-IDF compilation rules. Kapag nagdaragdag ng mga variable ng kapaligiran, ang mga nilalaman sa loob ng direktoryo ng mga tool ay idinaragdag sa variable ng kapaligiran ng system, na nagpapahintulot sa idf.py na maisagawa nang direkta sa ilalim ng landas ng proyekto.
d. Halampang direktoryo ng programa halamples
Ang direktoryo na ito ay binubuo ng isang malawak na koleksyon ng ESP-IDF exampmga program na nagpapakita ng paggamit ng mga component API. Ang exampAng mga les ay nakaayos sa iba't ibang mga subdirectory batay sa kanilang mga kategorya:
· makapagsimula: Kasama sa sub-directory na ito ang entry-level halamptulad ng "hello world" at "blink" upang matulungan ang mga user na maunawaan ang mga pangunahing kaalaman.
· Bluetooth: Makakahanap ka ng Bluetooth na nauugnay halamples dito, kabilang ang Bluetooth LE Mesh, Bluetooth LE HID, BluFi, at higit pa.
· wifi: Nakatuon ang sub-directory na ito sa Wi-Fi examples, kabilang ang mga pangunahing programa tulad ng Wi-Fi SoftAP, Wi-Fi Station, espnow, pati na rin ang proprietary communication protocol examples mula sa Espressif. Kasama rin dito ang maraming application layer halamples batay sa Wi-Fi, gaya ng Iperf, Sniffer, at Smart Config.
· Mga peripheral: Ang malawak na sub-directory na ito ay higit pang nahahati sa maraming mga subfolder batay sa mga peripheral na pangalan. Pangunahing naglalaman ito ng peripheral driver halamples para sa Espressif chips, sa bawat example na nagtatampok ng ilang sub-examples. Halimbawa, ang gpio sub-directory ay may kasamang dalawang examples: GPIO at GPIO matrix keyboard. Mahalagang tandaan na hindi lahat ng examples sa direktoryo na ito ay naaangkop sa ESP32-C3.
36 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Para kay example, ang exampAng mga les sa usb/host ay naaangkop lamang sa mga peripheral na may USB Host hardware (tulad ng ESP32-S3), at ang ESP32-C3 ay walang ganitong peripheral. Ang compilation system ay karaniwang nagbibigay ng mga prompt kapag nagtatakda ng target. Ang README file ng bawat exampInililista ni le ang mga sinusuportahang chips. · mga protocol: Ang sub-directory na ito ay naglalaman ng examples para sa iba't ibang protocol ng komunikasyon, kabilang ang MQTT, HTTP, HTTP Server, PPPoS, Modbus, mDNS, SNTP, na sumasaklaw sa malawak na hanay ng communication protocol exampmga kinakailangan para sa pag-unlad ng IoT. · provisioning: Dito, makikita mo ang provisioning examples para sa iba't ibang paraan, gaya ng Wi-Fi provisioning at Bluetooth LE provisioning. · system: Kasama sa sub-directory na ito ang pag-debug ng system halamples (hal., stack tracing, runtime tracing, task monitoring), power management halamples (hal., iba't ibang sleep mode, co-processors), at halampmga nauugnay sa mga karaniwang bahagi ng system tulad ng console terminal, event loop, at system timer. · imbakan: Sa loob ng sub-directory na ito, matutuklasan mo ang examples sa lahat file mga system at mekanismo ng storage na sinusuportahan ng ESP-IDF (tulad ng pagbabasa at pagsulat ng Flash, SD card at iba pang storage media), pati na rin ang exampkaunting non-volatile storage (NVS), FatFS, SPIFFS at iba pa file mga operasyon ng system. · seguridad: Ang sub-directory na ito ay naglalaman ng exampmga nauugnay sa flash encryption. (2) ESP-IDF compilation tool chain directory (/.espressif), tulad ng ipinapakita sa Figure 4.3.
Larawan 4.3. ESP-IDF compilation tool chain directory
Kabanata 4. Pag-set up ng Development Environment 37

a. Direktoryo ng pamamahagi ng software dist
Ang ESP-IDF tool chain at iba pang software ay ipinamamahagi sa anyo ng mga naka-compress na pakete. Sa panahon ng proseso ng pag-install, dina-download muna ng installation tool ang naka-compress na package sa dist directory, at pagkatapos ay i-extract ito sa tinukoy na direktoryo. Kapag kumpleto na ang pag-install, maaaring ligtas na maalis ang mga nilalaman sa direktoryo na ito.
b. Direktoryo ng virtual na kapaligiran ng Python python env
Ang iba't ibang bersyon ng ESP-IDF ay umaasa sa mga partikular na bersyon ng mga pakete ng Python. Ang pag-install ng mga package na ito nang direkta sa parehong host ay maaaring humantong sa mga salungatan sa pagitan ng mga bersyon ng package. Upang matugunan ito, ginagamit ng ESP-IDF ang mga virtual na kapaligiran ng Python upang ihiwalay ang iba't ibang bersyon ng package. Sa mekanismong ito, maaaring mag-install ang mga developer ng maraming bersyon ng ESP-IDF sa iisang host at madaling lumipat sa pagitan ng mga ito sa pamamagitan ng pag-import ng iba't ibang variable ng kapaligiran.
c. ESP-IDF compilation tool chain directory tools
Pangunahing naglalaman ang direktoryo na ito ng mga cross-compilation na tool na kinakailangan para mag-compile ng mga proyekto ng ESP-IDF, gaya ng mga CMake tool, Ninja build tool, at ang gcc tool chain na bumubuo ng panghuling executable na programa. Bilang karagdagan, ang direktoryo na ito ay naglalaman ng karaniwang aklatan ng C/C++ na wika kasama ang kaukulang header files. Kung ang isang programa ay tumutukoy sa isang header ng system file tulad ng #include , hahanapin ng compilation tool chain ang stdio.h file sa loob ng direktoryong ito.
4.2 Pag-set up ng ESP-IDF Development Environment
Ang ESP-IDF development environment ay sumusuporta sa mga pangunahing operating system gaya ng Windows, Linux, at macOS. Ipakikilala ng seksyong ito kung paano i-set up ang development environment sa bawat system. Inirerekomenda na bumuo ng ESP32-C3 sa Linux system, na ipapakilala nang detalyado dito. Maraming mga tagubilin ang naaangkop sa mga platform dahil sa pagkakapareho ng mga tool sa pag-develop. Samakatuwid, ipinapayo na maingat na basahin ang nilalaman ng seksyong ito.
TANDAAN Maaari kang sumangguni sa mga online na dokumento na makukuha sa https://bookc3.espressif.com/esp32c3, na nagbibigay ng mga utos na binanggit sa seksyong ito.
4.2.1 Pag-set up ng ESP-IDF Development Environment sa Linux
Ang mga tool sa pag-develop at pag-debug ng GNU na kinakailangan para sa kapaligiran ng pagpapaunlad ng ESP-IDF ay katutubong sa Linux system. Bukod pa rito, ang command-line terminal sa Linux ay makapangyarihan at madaling gamitin, ginagawa itong mainam na pagpipilian para sa pagpapaunlad ng ESP32-C3. Kaya mo
38 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

piliin ang iyong gustong pamamahagi ng Linux, ngunit inirerekumenda namin ang paggamit ng Ubuntu o iba pang Debianbased system. Ang seksyong ito ay nagbibigay ng gabay sa pag-set up ng ESP-IDF development environment sa Ubuntu 20.04.
1. I-install ang mga kinakailangang pakete
Magbukas ng bagong terminal at isagawa ang sumusunod na command para i-install ang lahat ng kinakailangang package. Awtomatikong lalaktawan ng command ang mga package na naka-install na.
$ 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
TIP Kailangan mong gamitin ang administrator account at password para sa command sa itaas. Bilang default, walang ipapakitang impormasyon kapag ipinasok ang password. Pindutin lamang ang "Enter" key upang ipagpatuloy ang pamamaraan.
Ang Git ay isang pangunahing tool sa pamamahala ng code sa ESP-IDF. Pagkatapos ng matagumpay na pag-set up ng development environment, maaari mong gamitin ang git log command sa view lahat ng mga pagbabago sa code na ginawa mula noong nilikha ang ESP-IDF. Bilang karagdagan, ang Git ay ginagamit din sa ESP-IDF upang kumpirmahin ang impormasyon ng bersyon, na kinakailangan para sa pag-install ng tamang tool chain na naaayon sa mga partikular na bersyon. Kasama ng Git, ang iba pang mahahalagang tool sa system ay kasama ang Python. Ang ESP-IDF ay nagsasama ng maraming mga script ng automation na nakasulat sa Python. Ang mga tool gaya ng CMake, Ninja-build, at Ccache ay malawakang ginagamit sa mga proyektong C/C++ at nagsisilbing default na compilation ng code at mga tool sa pagbuo sa ESP-IDF. Ang libusb-1.0-0 at dfu-util ay ang mga pangunahing driver na ginagamit para sa USB serial communication at firmware burning. Kapag na-install na ang mga software package, maaari mong gamitin ang apt show utos upang makakuha ng mga detalyadong paglalarawan ng bawat pakete. Para kay example, gumamit ng apt show git para i-print ang impormasyon ng paglalarawan para sa tool na Git.
Q: Ano ang gagawin kung ang bersyon ng Python ay hindi suportado? A: Ang ESP-IDF v4.3 ay nangangailangan ng bersyon ng Python na hindi mas mababa sa v3.6. Para sa mga mas lumang bersyon ng Ubuntu, mangyaring manu-manong mag-download at mag-install ng mas mataas na bersyon ng Python at itakda ang Python3 bilang default na kapaligiran ng Python. Makakahanap ka ng mga detalyadong tagubilin sa pamamagitan ng paghahanap para sa keyword update-alternatives python.
2. I-download ang ESP-IDF repository code
Magbukas ng terminal at lumikha ng isang folder na pinangalanang esp sa iyong home directory gamit ang mkdir command. Maaari kang pumili ng ibang pangalan para sa folder kung gusto mo. Gamitin ang cd command para ipasok ang folder.
Kabanata 4. Pag-set up ng Development Environment 39

$ mkdir -p /esp $ cd /esp
Gamitin ang git clone command upang i-download ang ESP-IDF repository code, tulad ng ipinapakita sa ibaba:
$ git clone -b v4.3.2 –recursive https://github.com/espressif/esp-idf.git
Sa command sa itaas, tinutukoy ng parameter -b v4.3.2 ang bersyon na ida-download (sa kasong ito, bersyon 4.3.2). Tinitiyak ng parameter –recursive na ang lahat ng sub-repositories ng ESP-IDF ay na-download nang recursively. Ang impormasyon tungkol sa mga sub-repositories ay matatagpuan sa .gitmodules file.
3. I-install ang ESP-IDF development tool chain
Nagbibigay ang Espressif ng automated script install.sh para i-download at i-install ang tool chain. Sinusuri ng script na ito ang kasalukuyang bersyon ng ESP-IDF at operating system na kapaligiran, at pagkatapos ay ida-download at i-install ang naaangkop na bersyon ng Python tool packages at compilation tool chain. Ang default na landas sa pag-install para sa chain ng tool ay /.espressif. Ang kailangan mo lang gawin ay mag-navigate sa direktoryo ng esp-idf at patakbuhin ang install.sh.
$ cd /esp/esp-idf $ ./install.sh
Kung matagumpay mong na-install ang tool chain, ipapakita ng terminal ang:
Tapos na lahat!
Sa puntong ito, matagumpay mong na-set up ang ESP-IDF development environment.
4.2.2 Pag-set up ng ESP-IDF Development Environment sa Windows
1. I-download ang ESP-IDF tools installer
TIP Inirerekomenda na i-set up ang ESP-IDF development environment sa Windows 10 o mas bago. Maaari mong i-download ang installer mula sa https://dl.espressif.com/dl/esp-idf/. Ang installer ay isa ring open-source na software, at maaaring ang source code nito viewed sa https: //github.com/espressif/idf-installer.
· Online na ESP-IDF tool installer
Ang installer na ito ay medyo maliit, humigit-kumulang 4 MB ang laki, at ang iba pang mga pakete at code ay mada-download sa panahon ng proseso ng pag-install. Ang advantage ng online installer ay hindi lamang maaaring ma-download ang mga software package at code kapag hinihiling sa panahon ng proseso ng pag-install, ngunit pinapayagan din ang pag-install ng lahat ng available na release ng ESP-IDF at ang pinakabagong sangay ng GitHub code (tulad ng master branch) . Ang disadvantage ay nangangailangan ito ng koneksyon sa network sa panahon ng proseso ng pag-install, na maaaring magdulot ng pagkabigo sa pag-install dahil sa mga problema sa network.
40 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

· Offline na ESP-IDF tools installer Mas malaki ang installer na ito, humigit-kumulang 1 GB ang laki, at naglalaman ng lahat ng software packages at code na kinakailangan para sa environment set up. Ang pangunahing advantage ng offline na installer ay maaari itong magamit sa mga computer na walang access sa Internet, at sa pangkalahatan ay may mas mataas na rate ng tagumpay sa pag-install. Dapat tandaan na ang offline installer ay maaari lamang mag-install ng mga stable na release ng ESP-IDF na kinilala ng v*.* o v*.*.*.
2. Patakbuhin ang ESP-IDF tools installer Pagkatapos mag-download ng angkop na bersyon ng installer (kunin ang ESP-IDF Tools Offline 4.3.2 para sa example here), i-double click ang exe file upang ilunsad ang interface ng pag-install ng ESP-IDF. Ipinapakita ng sumusunod kung paano i-install ang ESP-IDF stable na bersyon v4.3.2 gamit ang offline installer.
(1) Sa interface na "Piliin ang wika ng pag-install" na ipinapakita sa Figure 4.4, piliin ang wikang gagamitin mula sa drop-down na listahan.
Larawan 4.4. Interface ng “Piliin ang wika ng pag-install” (2) Pagkatapos piliin ang wika, i-click ang “OK” para i-pop up ang interface ng “Kasunduan sa lisensya”
(tingnan ang Larawan 4.5). Matapos maingat na basahin ang kasunduan sa lisensya sa pag-install, piliin ang "Tinatanggap ko ang kasunduan" at i-click ang "Next".
Larawan 4.5. Interface ng “Kasunduan sa lisensya” Kabanata 4. Pag-set Up ng Development Environment 41

(3) Review ang configuration ng system sa interface ng “Pre-installation system check” (tingnan ang Figure 4.6). Suriin ang bersyon ng Windows at ang naka-install na impormasyon ng antivirus software. I-click ang “Next” kung normal ang lahat ng configuration item. Kung hindi, maaari mong i-click ang "Buong log" para sa mga solusyon batay sa mga pangunahing item.
Larawan 4.6. Mga TIP sa interface ng “System check before installation”.
Maaari kang magsumite ng mga log sa https://github.com/espressif/idf-installer/issues para sa tulong. (4) Piliin ang direktoryo ng pag-install ng ESP-IDF. Dito, piliin ang D:/.espressif, gaya ng ipinapakita sa
Figure 4.7, at i-click ang "Next". Pakitandaan na ang .espressif dito ay isang nakatagong direktoryo. Matapos makumpleto ang pag-install, maaari mo view ang mga partikular na nilalaman ng direktoryong ito sa pamamagitan ng pagbubukas ng file manager at pagpapakita ng mga nakatagong item.
Larawan 4.7. Piliin ang direktoryo ng pag-install ng ESP-IDF 42 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

(5) Suriin ang mga sangkap na kailangang i-install, tulad ng ipinapakita sa Figure 4.8. Inirerekomenda na gamitin ang default na opsyon, iyon ay, kumpletong pag-install, at pagkatapos ay i-click ang "Next".
Larawan 4.8. Piliin ang mga sangkap na ii-install (6) Kumpirmahin ang mga sangkap na i-install at i-click ang "I-install" upang simulan ang awtomatikong pag-in-
proseso ng pagtigil, tulad ng ipinapakita sa Figure 4.9. Ang proseso ng pag-install ay maaaring tumagal ng sampu-sampung minuto at ang progress bar ng proseso ng pag-install ay ipinapakita sa Figure 4.10. Mangyaring maghintay nang matiyaga.
Larawan 4.9. Paghahanda para sa pag-install (7) Pagkatapos makumpleto ang pag-install, inirerekumenda na suriin ang “Irehistro ang ESP-IDF
Mga maipapatupad na tool bilang mga pagbubukod ng Windows Defender…” upang maiwasan ang pagtanggal ng antivirus software files. Ang pagdaragdag ng mga item sa pagbubukod ay maaari ding laktawan ang mga madalas na pag-scan ng antivirus
Kabanata 4. Pag-set up ng Development Environment 43

Larawan 4.10. Pag-install ng progress bar software, lubos na nagpapabuti sa kahusayan ng pag-compile ng code ng Windows system. I-click ang "Tapos na" upang makumpleto ang pag-install ng development environment, tulad ng ipinapakita sa Figure 4.11. Maaari mong piliing suriin ang “Patakbuhin ang ESP-IDF PowerShell environment” o “Run ESP-IDF command prompt”. Direktang patakbuhin ang compilation window pagkatapos ng pag-install upang matiyak na gumagana nang normal ang development environment.
Larawan 4.11. Nakumpleto ang pag-install (8) Buksan ang naka-install na development environment sa listahan ng program (alinman sa ESP-IDF 4.3
CMD o ESP-IDF 4.3 PowerShell terminal, tulad ng ipinapakita sa Figure 4.12), at ang ESP-IDF environment variable ay awtomatikong idaragdag kapag tumatakbo sa terminal. Pagkatapos nito, maaari mong gamitin ang idf.py command para sa mga operasyon. Ang binuksan na ESP-IDF 4.3 CMD ay ipinapakita sa Figure 4.13. 44 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Larawan 4.12. Naka-install ang development environment
Larawan 4.13. ESP-IDF 4.3 CMD
4.2.3 Pag-set up ng ESP-IDF Development Environment sa Mac
Ang proseso ng pag-install ng ESP-IDF development environment sa isang Mac system ay kapareho ng sa isang Linux system. Ang mga utos para sa pag-download ng repository code at pag-install ng tool chain ay eksaktong pareho. Ang mga utos lamang para sa pag-install ng mga dependency package ay bahagyang naiiba. 1. Mag-install ng mga dependency package Magbukas ng terminal, at mag-install ng pip, ang Python package management tool, sa pamamagitan ng pagpapatakbo ng sumusunod na command:
% sudo madaling pag-install ng pip
I-install ang Homebrew, isang tool sa pamamahala ng package para sa macOS, sa pamamagitan ng pagpapatakbo ng sumusunod na command:
% /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/ HEAD/install.sh)”
I-install ang mga kinakailangang dependency package sa pamamagitan ng pagpapatakbo ng sumusunod na command:
% brew python3 install cmake ninja ccache dfu-util
2. I-download ang ESP-IDF repository code Sundin ang mga tagubiling ibinigay sa seksyon 4.2.1 upang i-download ang ESP-IDF repository code. Ang mga hakbang ay pareho sa pag-download sa isang Linux system.
Kabanata 4. Pag-set up ng Development Environment 45

3. I-install ang ESP-IDF development tool chain
Sundin ang mga tagubiling ibinigay sa seksyon 4.2.1 para i-install ang ESP-IDF development tool chain. Ang mga hakbang ay kapareho ng para sa pag-install sa isang Linux system.
4.2.4 Pag-install ng VS Code
Bilang default, ang ESP-IDF SDK ay walang kasamang tool sa pag-edit ng code (bagama't ang pinakabagong installer ng ESP-IDF para sa Windows ay nag-aalok ng opsyong i-install ang ESP-IDF Eclipse). Maaari mong gamitin ang anumang tool sa pag-edit ng teksto na iyong pinili upang i-edit ang code at pagkatapos ay i-compile ito gamit ang mga terminal command.
Ang isang sikat na tool sa pag-edit ng code ay ang VS Code (Visual Studio Code), na isang libre at featurerich code editor na may interface na madaling gamitin. Nag-aalok ito ng iba't ibang plugins na nagbibigay ng mga functionality gaya ng code navigation, syntax highlighting, Git version control, at terminal integration. Bukod pa rito, nakabuo ang Espressif ng isang nakalaang plugin na tinatawag na Espressif IDF para sa VS Code, na pinapasimple ang pagsasaayos at pag-debug ng proyekto.
Maaari mong gamitin ang code command sa terminal upang mabilis na buksan ang kasalukuyang folder sa VS Code. Bilang kahalili, maaari mong gamitin ang shortcut na Ctrl+ upang buksan ang default na terminal console ng system sa loob ng VS Code.
TIP Inirerekomenda na gumamit ng VS Code para sa pagbuo ng ESP32-C3 code. I-download at i-install ang pinakabagong bersyon ng VS Code sa https://code.visualstudio.com/.
4.2.5 Panimula sa Third-Party Development Environment
Bilang karagdagan sa opisyal na kapaligiran sa pagpapaunlad ng ESP-IDF, na pangunahing gumagamit ng wikang C, sinusuportahan din ng ESP32-C3 ang iba pang mga pangunahing wika ng programming at isang malawak na hanay ng mga kapaligiran sa pag-unlad ng third-party. Ang ilang mga kapansin-pansing opsyon ay kinabibilangan ng:
Arduino: isang open-source na platform para sa parehong hardware at software, na sumusuporta sa iba't ibang microcontroller, kabilang ang ESP32-C3.
Gumagamit ito ng C++ na wika at nag-aalok ng pinasimple at standardized na API, na karaniwang tinutukoy bilang Arduino language. Ang Arduino ay malawakang ginagamit sa pagbuo ng prototype at mga kontekstong pang-edukasyon. Nagbibigay ito ng extensible software package at isang IDE na nagbibigay-daan para sa madaling compilation at flashing.
MicroPython: isang Python 3 language interpreter na idinisenyo upang tumakbo sa mga naka-embed na microcontroller platform.
Sa isang simpleng wika ng script, maaari nitong direktang ma-access ang mga peripheral na mapagkukunan ng ESP32-C3 (tulad ng UART, SPI, at I2C) at mga function ng komunikasyon (tulad ng Wi-Fi at Bluetooth LE).
46 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

Pinapasimple nito ang pakikipag-ugnayan sa hardware. Ang MicroPython, na sinamahan ng malawak na mathematical operation library ng Python, ay nagbibigay-daan sa pagpapatupad ng mga kumplikadong algorithm sa ESP32-C3, na nagpapadali sa pagbuo ng mga application na nauugnay sa AI. Bilang isang script language, hindi na kailangan ng paulit-ulit na compilation; maaaring gawin ang mga pagbabago at direktang maisagawa ang mga script.
NodeMCU: isang LUA language interpreter na binuo para sa ESP series chips.
Sinusuportahan nito ang halos lahat ng peripheral function ng ESP chips at mas magaan kaysa sa MicroPython. Katulad ng MicroPython, gumagamit ang NodeMCU ng script language, na inaalis ang pangangailangan para sa paulit-ulit na compilation.
Higit pa rito, sinusuportahan din ng ESP32-C3 ang NuttX at Zephyr operating system. Ang NuttX ay isang real-time na operating system na nagbibigay ng POSIX-compatible na mga interface, na nagpapahusay ng application portability. Ang Zephyr ay isang maliit na real-time na operating system na partikular na idinisenyo para sa mga application ng IoT. Kabilang dito ang maraming software library na kinakailangan sa pag-develop ng IoT, unti-unting umuusbong sa isang komprehensibong software ecosystem.
Ang aklat na ito ay hindi nagbibigay ng mga detalyadong tagubilin sa pag-install para sa mga nabanggit na kapaligiran sa pag-unlad. Maaari kang mag-install ng development environment batay sa iyong mga kinakailangan sa pamamagitan ng pagsunod sa kaukulang dokumentasyon at mga tagubilin.
4.3 ESP-IDF Compilation System
4.3.1 Pangunahing Konsepto ng Compilation System
Ang isang proyekto ng ESP-IDF ay isang koleksyon ng isang pangunahing programa na may isang entry function at maramihang independiyenteng functional na mga bahagi. Para kay exampAng isang proyekto na kumokontrol sa mga switch ng LED ay pangunahing binubuo ng isang pangunahing programa sa pagpasok at isang bahagi ng driver na kumokontrol sa GPIO. Kung gusto mong mapagtanto ang LED remote control, kailangan mo ring magdagdag ng Wi-Fi, TCP/IP protocol stack, atbp.
Ang compilation system ay maaaring mag-compile, mag-link, at bumuo ng executable files (.bin) para sa code sa pamamagitan ng isang hanay ng mga panuntunan sa gusali. Ang compilation system ng ESP-IDF v4.0 at mas mataas na mga bersyon ay batay sa CMake bilang default, at ang compilation script na CMakeLists.txt ay maaaring gamitin upang kontrolin ang compilation na gawi ng code. Bilang karagdagan sa pagsuporta sa pangunahing syntax ng CMake, tinutukoy din ng ESP-IDF compilation system ang isang set ng mga default na panuntunan sa compilation at CMake function, at maaari mong isulat ang compilation script gamit ang mga simpleng statement.
4.3.2 Proyekto File Istruktura
Ang isang proyekto ay isang folder na naglalaman ng pangunahing entry program, mga bahagi na tinukoy ng gumagamit, at files kinakailangan upang bumuo ng mga executable na application, tulad ng mga compilation script, configuration
Kabanata 4. Pag-set up ng Development Environment 47

files, mga partition table, atbp. Ang mga proyekto ay maaaring kopyahin at ipasa, at ang parehong maipapatupad file maaaring i-compile at mabuo sa mga makina na may parehong bersyon ng ESP-IDF development environment. Isang tipikal na proyekto ng ESP-IDF file ang istraktura ay ipinapakita sa Figure 4.14.
Larawan 4.14. Karaniwang proyekto ng ESP-IDF file istraktura Dahil sinusuportahan ng ESP-IDF ang maraming IoT chips mula sa Espressif, kabilang ang ESP32, ESP32-S series, ESP32-C series, ESP32-H series, atbp., kailangang matukoy ang isang target bago i-compile ang code. Ang target ay parehong hardware device na nagpapatakbo ng application program at ang build target ng compilation system. Depende sa iyong mga pangangailangan, maaari mong tukuyin ang isa o higit pang mga target para sa iyong proyekto. Para kay exampAt, sa pamamagitan ng command na idf.py set-target esp32c3, maaari mong itakda ang target ng compilation sa ESP32-C3, kung saan ilo-load ang mga default na parameter at compilation tool chain path para sa ESP32C3. Pagkatapos ng compilation, isang executable program ay maaaring mabuo para sa ESP32C3. Maaari mo ring patakbuhin muli ang command set-target upang magtakda ng ibang target, at awtomatikong maglilinis at mag-reconfigure ang compilation system. Mga bahagi
Ang mga bahagi sa ESP-IDF ay modular at independiyenteng mga unit ng code na pinamamahalaan sa loob ng compilation system. Nakaayos ang mga ito bilang mga folder, na ang pangalan ng folder ay kumakatawan sa pangalan ng bahagi bilang default. Ang bawat bahagi ay may sariling compilation script na 48 ESP32-C3 Wireless Adventure: Isang Comprehensive Guide to IoT

tumutukoy sa mga parameter ng compilation at dependency nito. Sa panahon ng proseso ng compilation, ang mga bahagi ay pinagsama-sama sa magkahiwalay na mga static na library (.a files) at kalaunan ay pinagsama sa iba pang mga bahagi upang mabuo ang programa ng aplikasyon.
Nagbibigay ang ESP-IDF ng mahahalagang function, tulad ng operating system, peripheral driver, at network protocol stack, sa anyo ng mga bahagi. Ang mga sangkap na ito ay naka-imbak sa direktoryo ng mga bahagi na matatagpuan sa loob ng direktoryo ng ugat ng ESP-IDF. Hindi kailangang kopyahin ng mga developer ang mga bahaging ito sa direktoryo ng mga bahagi ng myProject. Sa halip, kailangan lang nilang tukuyin ang mga ugnayan ng dependency ng mga bahaging ito sa CMakeLists.txt ng proyekto file gamit ang REQUIRES o PRIV_REQUIRES na mga direktiba. Awtomatikong hahanapin at ipunin ng compilation system ang mga kinakailangang bahagi.
Samakatuwid, ang direktoryo ng mga bahagi sa ilalim ng myProject ay hindi kinakailangan. Ginagamit lang ito para isama ang ilang custom na bahagi ng proyekto, na maaaring mga third-party na library o code na tinukoy ng user. Bukod pa rito, maaaring kunin ang mga bahagi mula sa anumang direktoryo maliban sa ESP-IDF o sa kasalukuyang proyekto, gaya ng mula sa isang open-source na proyekto na naka-save sa ibang direktoryo. Sa kasong ito, kailangan mo lang idagdag ang path ng component sa pamamagitan ng pagtatakda ng EXTRA_COMPONENT_DIRS variable sa CMakeLists.txt sa ilalim ng root directory. I-override ng direktoryo na ito ang anumang bahagi ng ESP-IDF na may parehong pangalan, na tinitiyak na ginagamit ang tamang bahagi.
Entry program main Ang pangunahing direktoryo sa loob ng proyekto ay sumusunod sa parehong file istraktura tulad ng iba pang mga bahagi (hal., component1). Gayunpaman, mayroon itong espesyal na kahalagahan dahil ito ay isang mandatoryong bahagi na dapat na umiiral sa bawat proyekto. Ang pangunahing direktoryo ay naglalaman ng source code ng proyekto at ang entry point ng user program, na karaniwang may pangalang app_main. Bilang default, ang pagpapatupad ng programa ng gumagamit ay nagsisimula mula sa entry point na ito. Naiiba din ang pangunahing bahagi dahil awtomatiko itong nakadepende sa lahat ng bahagi sa loob ng landas ng paghahanap. Samakatuwid, hindi na kailangang tahasang ipahiwatig ang mga dependency gamit ang REQUIRES o PRIV_REQUIRES na mga direktiba sa CMakeLists.txt file.
Configuration file Ang root directory ng proyekto ay naglalaman ng configuration file tinatawag na sdkconfig, na naglalaman ng mga parameter ng pagsasaayos para sa lahat ng mga bahagi sa loob ng proyekto. Ang sdkconfig file ay awtomatikong nabuo ng sistema ng compilation at maaaring mabago at muling buuin ng command na idf.py menuconfig. Ang mga opsyon sa menuconfig ay pangunahing nagmula sa Kconfig.projbuild ng proyekto at ang Kconfig ng mga bahagi. Ang mga developer ng bahagi ay karaniwang nagdaragdag ng mga item sa pagsasaayos sa Kconfig upang gawing flexible at ma-configure ang bahagi.
Bumuo ng direktoryo Bilang default, ang build directory sa loob ng proyekto ay nag-iimbak ng intermediate files at ang fi-
Kabanata 4. Pag-set up ng Development Environment 49

nal executable program na nabuo ng idf.py build command. Sa pangkalahatan, hindi kinakailangang direktang i-access ang mga nilalaman ng direktoryo ng build. Nagbibigay ang ESP-IDF ng mga paunang natukoy na command upang makipag-ugnayan sa direktoryo, tulad ng paggamit ng idf.py flash command upang awtomatikong mahanap ang pinagsama-samang binary file at i-flash ito sa tinukoy na flash address, o gamit ang idf.py fullclean command upang linisin ang buong build directory.
Partition table (partitions.csv) Ang bawat proyekto ay nangangailangan ng partition table para hatiin ang space ng flash at tukuyin ang laki at panimulang address ng executable program at user data space. Ang command idf.py flash o OTA upgrade program ay magpapa-flash ng firmware sa kaukulang address ayon sa talahanayang ito. Nagbibigay ang ESP-IDF ng ilang default na partition table sa mga component/ partition_table, gaya ng partitions_singleapp.csv at partitions_two_ ota.csv, na maaaring piliin sa menuconfig.
Kung hindi matugunan ng default na partition table ng system ang mga kinakailangan ng proyekto, maaaring magdagdag ng custom partitions.csv sa direktoryo ng proyekto at mapili sa menuconfig.
4.3.3 Default na Mga Panuntunan sa Pagbuo ng Compilation System
Mga panuntunan para sa pag-override ng mga bahagi na may parehong pangalan Sa panahon ng proseso ng paghahanap ng bahagi, ang compilation system ay sumusunod sa isang partikular na pagkakasunud-sunod. Hinahanap muna nito ang mga panloob na bahagi ng ESP-IDF, pagkatapos ay naghahanap ng mga bahagi ng proyekto ng user, at sa wakas ay naghahanap ng mga bahagi sa EXTRA_COMPONENT_DIRS. Sa mga kaso kung saan maraming mga direktoryo ang naglalaman ng mga bahagi na may parehong pangalan, ang sangkap na makikita sa huling direktoryo ay mag-o-override sa anumang mga nakaraang bahagi na may parehong pangalan. Ang panuntunang ito ay nagbibigay-daan para sa pag-customize ng mga bahagi ng ESP-IDF sa loob ng proyekto ng user, habang pinananatiling buo ang orihinal na ESP-IDF code.
Mga panuntunan para sa pagsasama ng mga karaniwang bahagi bilang default Gaya ng nabanggit sa seksyon 4.3.2, kailangang tahasang tukuyin ng mga bahagi ang kanilang mga dependency sa iba pang bahagi sa CMakeLists.txt. Gayunpaman, ang mga karaniwang bahagi gaya ng freertos ay awtomatikong kasama sa build system bilang default, kahit na ang kanilang mga dependency na relasyon ay hindi tahasang tinukoy sa compilation script. Kasama sa mga karaniwang bahagi ng ESP-IDF ang freertos, Newlib, heap, log, soc, esp_rom, esp_common, xtensa/riscv, at cxx. Ang paggamit ng mga karaniwang bahaging ito ay maiiwasan ang paulit-ulit na gawain kapag nagsusulat ng CMakeLists.txt at gawin itong mas maigsi.
Mga panuntunan para sa pag-override ng mga item sa configuration Maaaring magdagdag ang mga developer ng mga default na parameter ng configuration sa pamamagitan ng pagdaragdag ng default na configuration file pinangalanang sdkconfig.defaults sa proyekto. Para kay example, nagdaragdag ng CONFIG_LOG_
50 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

DEFAULT_LEVEL_NONE = y maaaring i-configure ang interface ng UART upang hindi mag-print ng data ng log bilang default. Higit pa rito, kung kailangang itakda ang mga partikular na parameter para sa isang partikular na target, isang configuration file na pinangalanang sdkconfig.defaults.TARGET_NAME ay maaaring idagdag, kung saan ang TARGET_NAME ay maaaring esp32s2, esp32c3, at iba pa. Ang mga pagsasaayos na ito files ay ini-import sa sdkconfig sa panahon ng compilation, na may pangkalahatang default na configuration file sdkconfig.defaults ang unang ini-import, na sinusundan ng configuration na tukoy sa target file, gaya ng sdkconfig.defaults.esp32c3. Sa mga kaso kung saan may mga configuration item na may parehong pangalan, ang huli na configuration file ay i-override ang dating.
4.3.4 Panimula sa Compilation Script
Kapag bumubuo ng isang proyekto gamit ang ESP-IDF, ang mga developer ay hindi lamang kailangang magsulat ng source code ngunit kailangan ding magsulat ng CMakeLists.txt para sa proyekto at mga bahagi. Ang CMakeLists.txt ay isang text file, na kilala rin bilang isang compilation script, na tumutukoy sa isang serye ng mga compilation object, compilation configuration item, at commands para gabayan ang compilation process ng source code. Ang compilation system ng ESP-IDF v4.3.2 ay batay sa CMake. Bilang karagdagan sa pagsuporta sa mga native na function at command ng CMake, tinutukoy din nito ang isang serye ng mga custom na function, na ginagawang mas madali ang pagsulat ng mga script ng compilation.
Ang mga compilation script sa ESP-IDF ay pangunahing kasama ang project compilation script at ang component compilation script. Ang CMakeLists.txt sa root directory ng proyekto ay tinatawag na project compilation script, na gumagabay sa proseso ng compilation ng buong proyekto. Karaniwang kasama sa isang pangunahing script ng compilation ng proyekto ang sumusunod na tatlong linya:
1. cmake_minimum_required(VERSION 3.5) 2. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 3. project(myProject)
Kabilang sa mga ito, ang cmake_minimum_required (VERSION 3.5) ay dapat ilagay sa unang linya, na ginagamit upang ipahiwatig ang minimum na numero ng bersyon ng CMake na kinakailangan ng proyekto. Ang mga mas bagong bersyon ng CMake ay karaniwang backward compatible sa mga mas lumang bersyon, kaya ayusin ang numero ng bersyon nang naaayon kapag gumagamit ng mas bagong mga command ng CMake upang matiyak ang pagiging tugma.
include($ENV {IDF_PATH}/tools/cmake/project.cmake) ay nag-i-import ng mga pre-defined na configuration item at command ng ESP-IDF compilation system, kabilang ang mga default na panuntunan sa pagbuo ng compilation system na inilalarawan sa Seksyon 4.3.3. project(myProject) ay lumilikha ng proyekto mismo at tinukoy ang pangalan nito. Gagamitin ang pangalang ito bilang panghuling output binary file pangalan, ibig sabihin, myProject.elf at myProject.bin.
Ang isang proyekto ay maaaring magkaroon ng maraming bahagi, kabilang ang pangunahing bahagi. Ang nangungunang antas na direktoryo ng bawat bahagi ay naglalaman ng isang CMakeLists.txt file, na tinatawag na component compilation script. Pangunahing ginagamit ang mga script ng compilation ng bahagi upang tukuyin ang mga dependency ng bahagi, mga parameter ng pagsasaayos, source code files, at kasama ang header filepara sa
Kabanata 4. Pag-set up ng Development Environment 51

compilation. Sa custom na function ng ESP-IDF na idf_component_register, ang minimum na kinakailangang code para sa script ng compilation ng component ay ang sumusunod:

1. idf_component_register(SRCS “src1.c”

2.

INCLUDE_DIRS "isama"

3.

KINAKAILANGAN ang bahagi1)

Ang parameter ng SRCS ay nagbibigay ng isang listahan ng pinagmulan files sa bahagi, na pinaghihiwalay ng mga puwang kung marami files. Ang parameter na INCLUDE_DIRS ay nagbibigay ng listahan ng pampublikong header file mga direktoryo para sa bahagi, na idaragdag sa isama ang landas ng paghahanap para sa iba pang mga bahagi na nakadepende sa kasalukuyang bahagi. Tinutukoy ng parameter na REQUIRES ang mga dependency ng pampublikong bahagi para sa kasalukuyang bahagi. Kinakailangan para sa mga bahagi na tahasang sabihin kung aling mga bahagi ang kanilang nakasalalay, tulad ng component2 depende sa component1. Gayunpaman, para sa pangunahing bahagi, na depende sa lahat ng mga bahagi bilang default, ang parameter na KINAKAILANGAN ay maaaring tanggalin.

Bilang karagdagan, ang mga native na command ng CMake ay maaari ding gamitin sa compilation script. Para kay example, gamitin ang command set para magtakda ng mga variable, gaya ng set(VARIABLE “VALUE”).

4.3.5 Panimula sa Mga Karaniwang Utos
Ang ESP-IDF ay gumagamit ng CMake (project configuration tool), Ninja (project building tool) at esptool (flash tool) sa proseso ng code compilation. Ang bawat tool ay gumaganap ng iba't ibang papel sa compilation, pagbuo, at proseso ng flash, at sinusuportahan din ang iba't ibang mga operating command. Upang mapadali ang pagpapatakbo ng user, nagdaragdag ang ESP-IDF ng pinag-isang front-end na idf.py na nagbibigay-daan sa mga command sa itaas na matawagan nang mabilis.
Bago gamitin ang idf.py, siguraduhin na:
· Ang environment variable na IDF_PATH ng ESP-IDF ay naidagdag sa kasalukuyang terminal. · Ang command execution directory ay ang root directory ng proyekto, na kinabibilangan ng
script ng compilation ng proyekto CMakeLists.txt.
Ang mga karaniwang utos ng idf.py ay ang mga sumusunod:
· idf.py –help: pagpapakita ng listahan ng mga command at mga tagubilin sa paggamit ng mga ito. · idf.py set-target : pagtatakda ng compilation taidf.py fullcleanrget, tulad
bilang pagpapalit na may esp32c3. · idf.py menuconfig: paglulunsad ng menuconfig, isang terminal na graphical na configuration
tool, na maaaring pumili o magbago ng mga opsyon sa pagsasaayos, at ang mga resulta ng pagsasaayos ay nai-save sa sdkconfig file. · idf.py build: pagsisimula ng code compilation. Ang intermediate files at ang panghuling executable program na nabuo ng compilation ay ise-save sa build directory ng proyekto bilang default. Ang proseso ng compilation ay incremental, na nangangahulugang kung isang source lamang file ay binago, tanging ang binago file ay isasama sa susunod na pagkakataon.

52 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

· idf.py clean: paglilinis ng intermediate files nabuo sa pamamagitan ng compilation ng proyekto. Ang buong proyekto ay mapipilitang mag-compile sa susunod na compilation. Tandaan na ang configuration ng CMake at ang mga pagbabago sa configuration na ginawa ng menuconfig ay hindi tatanggalin sa panahon ng paglilinis.
· idf.py fullclean: pagtanggal sa buong direktoryo ng build, kasama ang lahat ng output ng configuration ng CMake files. Kapag binuo muli ang proyekto, iko-configure ng CMake ang proyekto mula sa simula. Pakitandaan na ang utos na ito ay muling tatanggalin ang lahat files sa direktoryo ng build, kaya gamitin ito nang may pag-iingat, at ang pagsasaayos ng proyekto file hindi matatanggal.
· idf.py flash: pag-flash ng executable program binary file nabuo sa pamamagitan ng build sa target na ESP32-C3. Ang mga pagpipilian -p at -b ay ginagamit upang itakda ang pangalan ng device ng serial port at ang baud rate para sa pag-flash, ayon sa pagkakabanggit. Kung hindi tinukoy ang dalawang opsyong ito, awtomatikong matutukoy ang serial port at gagamitin ang default na baud rate.
· idf.py monitor: ipinapakita ang serial port output ng target na ESP32-C3. Ang opsyon -p ay maaaring gamitin upang tukuyin ang pangalan ng device ng host-side serial port. Habang nagpi-print ng serial port, pindutin ang key combination na Ctrl+] para lumabas sa monitor.
Ang mga utos sa itaas ay maaari ding pagsamahin kung kinakailangan. Para kay exampAt, ang command na idf.py build flash monitor ay magsasagawa ng code compilation, flash, at bubuksan ang serial port monitor sa pagkakasunod-sunod.
Maaari mong bisitahin ang https://bookc3.espressif.com/build-system upang malaman ang higit pa tungkol sa ESP-IDF compilation system.
4.4 Pagsasanay: Pagbubuo ng Halampang Programang "Blink"
4.4.1 Halampang Pagsusuri
Dadalhin ng seksyong ito ang program na Blink bilang isang example upang pag-aralan ang file istraktura at coding na mga panuntunan ng isang tunay na proyekto nang detalyado. Ang Blink program ay nagpapatupad ng LED blinking effect, at ang proyekto ay matatagpuan sa directory examples/get-started/blink, na naglalaman ng source file, pagsasaayos files, at ilang compilation script.
Ang smart light project na ipinakilala sa aklat na ito ay batay sa ex na itoampang programa. Ang mga function ay unti-unting idaragdag sa mga susunod na kabanata para sa wakas ay makumpleto ito.
Source code Upang maipakita ang buong proseso ng pag-develop, ang Blink program ay kinopya sa esp32c3-iot-projects/device firmware/1 blink.
Ang istraktura ng direktoryo ng blink project files ay ipinapakita sa Figure 4.15.
Ang blink project ay naglalaman lamang ng isang pangunahing direktoryo, na isang espesyal na bahagi na
Kabanata 4. Pag-set up ng Development Environment 53

Larawan 4.15. File istraktura ng direktoryo ng blink project

dapat isama gaya ng inilarawan sa seksyon 4.3.2. Ang pangunahing direktoryo ay pangunahing ginagamit upang iimbak ang pagpapatupad ng app_main() function, na siyang entry point sa user program.Ang blink project ay hindi kasama ang mga component directory, dahil ang ex na itoampKailangan lang gamitin ang mga sangkap na kasama ng ESP-IDF at hindi nangangailangan ng mga karagdagang bahagi. Ang CMakeLists.txt na kasama sa blink project ay ginagamit para gabayan ang proseso ng compilation, habang ang Kconfig.projbuild ay ginagamit para magdagdag ng mga configuration item para sa ex na itoampang programa sa menuconfig. Iba pang hindi kailangan files ay hindi makakaapekto sa compilation ng code, kaya hindi sila tatalakayin dito. Isang detalyadong panimula sa blink project files ay ang mga sumusunod.

1. Kasama sa /*blink.c ang sumusunod na header files*/

2. #isama

//Standard C library header file

3. #include “freeertos/freeRTOS.h” //FreeRTOS main header file

4. #include “freeertos/task.h”

//FreeRTOS Task header file

5. #include “sdkconfig.h”

//Configuration header file nabuo ng kconfig

6. #include “driver/gpio.h”

//header ng driver ng GPIO file

Ang pinagmulan file Ang blink.c ay naglalaman ng isang serye ng header files naaayon sa function na deklara-

tions. Karaniwang sinusunod ng ESP-IDF ang pagkakasunud-sunod ng pagsasama ng karaniwang header ng library files, LibreR-

Header ng TOS files, header ng driver files, iba pang header ng bahagi files, at header ng proyekto files.

Ang pagkakasunud-sunod sa kung aling header files ay kasama ay maaaring makaapekto sa huling resulta ng compilation, kaya subukan na

sundin ang mga default na panuntunan. Dapat tandaan na ang sdkconfig.h ay awtomatikong nabuo

sa pamamagitan ng kconfig at maaari lamang i-configure sa pamamagitan ng command na idf.py menuconfig.

Direktang pagbabago ng header na ito file ay mapapatungan.

1. /*Maaari mong piliin ang GPIO na naaayon sa LED sa idf.py menuconfig, at ang resulta ng pagbabago ng menuconfig ay ang halaga ng CONFIG_BLINK

_GPIO ay mababago. Maaari mo ring direktang baguhin ang macro definition

dito, at baguhin ang CONFIG_BLINK_GPIO sa isang nakapirming halaga.*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO

3. void app_main(void)

4. {

5.

/*I-configure ang IO bilang default na function ng GPIO, paganahin ang pull-up mode, at

6.

huwag paganahin ang input at output mode*/

7.

gpio_reset_pin(BLINK_GPIO);

54 ESP32-C3 Wireless Adventure: Isang Komprehensibong Gabay sa IoT

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

/*Itakda ang GPIO sa output mode*/ gpio_set_direction(BLINK_GPIO, GPIO_MODE_OUTPUT); habang(1) {
/*Print log*/ printf(“I-off ang LEDn”); /*I-off ang LED (mababang antas ng output)*/ gpio_set_level(BLINK_GPIO, 0); /*Delay (1000 ms)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf("Pag-on sa LEDn"); /*I-on ang LED (mataas na antas ng output)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay(1000 / portTICK_PERIOD_MS); }

Ang app_main() function sa Blink exampAng programa ay nagsisilbing entry point para sa mga programa ng gumagamit. Ito ay isang simpleng function na walang mga parameter at walang return value. Tinatawag ang function na ito pagkatapos makumpleto ng system ang initialization, na kinabibilangan ng mga gawain tulad ng pagsisimula ng log serial port, pag-configure ng single/dual core, at pag-configure ng watchdog.

Ang app_main() function ay tumatakbo sa konteksto ng isang gawain na pinangalanang main. Ang laki ng stack at priyoridad ng gawaing ito ay maaaring isaayos sa menuconfig Componentconfig Common ESP-related.

Para sa mga simpleng gawain tulad ng pag-blink ng LED, ang lahat ng kinakailangang code ay maaaring ipatupad nang direkta sa app_main() function. Ito ay karaniwang nagsasangkot ng pagsisimula ng GPIO na tumutugma sa LED at paggamit ng isang while(1) loop upang i-toggle ang LED sa on at off. Bilang kahalili, maaari mong gamitin ang FreeRTOS API upang lumikha ng isang bagong gawain na humahawak sa LED blinking. Kapag ang bagong gawain ay matagumpay na nalikha, maaari kang lumabas sa app_main() function.

Ang nilalaman ng main/CMakeLists.txt file, na gumagabay sa proseso ng compilation para sa pangunahing bahagi, ay ang mga sumusunod:

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

Kabilang sa mga ito, ang pangunahing/CMakeLists.txt ay tumatawag lamang sa isang function ng compilation system, iyon ay idf_component_register. Katulad ng CMakeLists.txt para sa karamihan ng iba pang mga bahagi, ang blink.c ay idinaragdag sa SRCS, at ang pinagmulan files idinagdag sa SRCS ay isasama. Kasabay nito, ang ".", na kumakatawan sa path kung saan matatagpuan ang CMakeLists.txt, ay dapat idagdag sa INCLUDE_DIRS bilang mga direktoryo ng paghahanap para sa header files. Ang nilalaman ng CMakeLists.txt ay ang mga sumusunod:
1. #Tukuyin ang v3.5 bilang ang pinakalumang bersyon ng CMake na sinusuportahan ng kasalukuyang proyekto 2. Dapat i-upgrade ang #Mga bersyon na mas mababa sa v3.5 bago magpatuloy ang compilation 3. cmake_minimum_required(VERSION 3.5) 4. #Isama ang default na configuration ng CMake ng ESP -IDF compilation system

Kabanata 4. Pag-set up ng Development Environment 55

5. isama ang($ENV{IDF_PATH}/tools/cmake/project.cmake) 6. #Gumawa ng proyektong pinangalanang “blink” 7. project(myProject)
Kabilang sa mga ito, ang CMakeLists.txt sa root directory ay pangunahing kinabibilangan ng $ENV{IDF_ PATH}/tools/cmake/project.cmake, na siyang pangunahing configuration ng CMake file ibinigay ng ESP-IDF. Ito ay ginagamit upang con

Mga Dokumento / Mga Mapagkukunan

Espressif Systems ESP32-C3 Wireless Adventure [pdf] Gabay sa Gumagamit
ESP32-C3 Wireless Adventure, ESP32-C3, Wireless Adventure, Adventure

Mga sanggunian

Mag-iwan ng komento

Ang iyong email address ay hindi maipa-publish. Ang mga kinakailangang field ay minarkahan *