ESP32-C3 הרפתקאות אלחוטיות
ESP32-C3 הרפתקאות אלחוטיות
מדריך מקיף ל-IoT
Espressif Systems 12 ביוני 2023
מפרטים
- מוצר: ESP32-C3 Wireless Adventure
- יצרן: Espressif Systems
- תאריך: 12 ביוני 2023
הוראות שימוש במוצר
הֲכָנָה
לפני השימוש ב-ESP32-C3 Wireless Adventure, ודא שכן
מכיר את המושגים והארכיטקטורה של IoT. זה יעזור
אתה מבין איך המכשיר משתלב במערכת האקולוגית הגדולה יותר של IoT
והיישומים הפוטנציאליים שלה בבתים חכמים.
מבוא ותרגול של פרויקטי IoT
בחלק זה תלמדו על פרויקטי IoT טיפוסיים,
כולל המודולים הבסיסיים עבור התקני IoT נפוצים, מודולים בסיסיים
של יישומי לקוח, ופלטפורמות ענן IoT נפוצות. זה יהיה
לספק לך בסיס להבנה וליצירת שלך
פרויקטי IoT משלו.
תרגול: פרויקט אור חכם
בפרויקט תרגול זה תלמדו כיצד ליצור חכם
אור באמצעות ה-ESP32-C3 Wireless Adventure. מבנה הפרויקט,
פונקציות, הכנת החומרה ותהליך הפיתוח יהיו
מוסבר בפירוט.
מבנה הפרויקט
הפרויקט מורכב ממספר מרכיבים, ביניהם
ESP32-C3 Wireless Adventure, נוריות, חיישנים וענן
אחורי.
פונקציות הפרויקט
פרויקט האור החכם מאפשר לך לשלוט בבהירות ו
צבע של נוריות הלד מרחוק באמצעות אפליקציה לנייד או web
מִמְשָׁק.
הכנת חומרה
כדי להתכונן לפרויקט, תצטרך לאסוף את
רכיבי חומרה נחוצים, כגון ESP32-C3 Wireless
לוח הרפתקאות, לדים, נגדים וספק כוח.
תהליך פיתוח
תהליך הפיתוח כולל הקמת הפיתוח
סביבה, כתיבת קוד לשליטה על נוריות הלד, חיבור ל-
ענן backend, ובדיקת הפונקציונליות של החכם
אוֹר.
היכרות עם ESP RainMaker
ESP RainMaker היא מסגרת רבת עוצמה לפיתוח IoT
מכשירים. בחלק זה תלמדו מהו ESP RainMaker ומהו
כיצד ניתן ליישם את זה בפרויקטים שלך.
מהו ESP RainMaker?
ESP RainMaker היא פלטפורמה מבוססת ענן המספקת סט של
כלים ושירותים לבנייה וניהול של מכשירי IoT.
היישום של ESP RainMaker
חלק זה מסביר את המרכיבים השונים המעורבים ב
הטמעת ESP RainMaker, כולל שירות התביעה,
RainMaker Agent, ענן backend ו-RainMaker Client.
תרגול: נקודות מפתח לפיתוח עם ESP RainMaker
בחלק התרגול הזה, תלמדו על נקודות המפתח
שקול בעת פיתוח עם ESP RainMaker. זה כולל מכשיר
תביעה, סנכרון נתונים וניהול משתמשים.
תכונות של ESP RainMaker
ESP RainMaker מציע תכונות שונות לניהול משתמשים, סוף
משתמשים ומנהלי מערכת. תכונות אלה מאפשרות מכשיר קל
הגדרה, שליטה מרחוק וניטור.
הגדרת סביבת פיתוח
סעיף זה מספק סוףview של ESP-IDF (Espressif IoT
מסגרת פיתוח), שהיא מסגרת הפיתוח הרשמית
עבור מכשירים מבוססי ESP32. זה מסביר את הגרסאות השונות של
ESP-IDF וכיצד להגדיר את סביבת הפיתוח.
פיתוח חומרה ודרייברים
עיצוב חומרה של מוצרי Smart Light מבוסס על ESP32-C3
חלק זה מתמקד בעיצוב החומרה של אור חכם
מוצרים המבוססים על ה-ESP32-C3 Wireless Adventure. זה מכסה את
תכונות והרכב של מוצרי אור חכמים, כמו גם את
עיצוב חומרה של מערכת הליבה ESP32-C3.
תכונות והרכב של מוצרי Smart Light
סעיף קטן זה מסביר את התכונות והרכיבים שיוצרים
מוצרי אור חכמים. הוא דן בפונקציות השונות
ושיקולי עיצוב ליצירת אורות חכמות.
עיצוב חומרה של מערכת הליבה ESP32-C3
עיצוב החומרה של מערכת הליבה ESP32-C3 כולל כוח
אספקה, רצף הפעלה, איפוס מערכת, פלאש SPI, מקור שעון,
ושיקולי RF ואנטנה. סעיף קטן זה מספק
מידע מפורט על היבטים אלה.
שאלות נפוצות
ש: מהו ESP RainMaker?
ת: ESP RainMaker היא פלטפורמה מבוססת ענן המספקת כלים
ושירותים לבנייה וניהול של מכשירי IoT. זה מפשט
תהליך הפיתוח ומאפשר התקנה קלה של המכשיר, מרחוק
בקרה, וניטור.
ש: איך אני יכול להגדיר את סביבת הפיתוח עבור
ESP32-C3?
ת: כדי להגדיר את סביבת הפיתוח עבור ESP32-C3, אתה צריך
להתקין ESP-IDF (מסגרת פיתוח IoT של Espressif) ו
להגדיר אותו לפי ההוראות שסופקו. ESP-IDF הוא
מסגרת פיתוח רשמית עבור מכשירים מבוססי ESP32.
ש: מהן התכונות של ESP RainMaker?
ת: ESP RainMaker מציע תכונות שונות, כולל משתמש
ניהול, תכונות משתמש קצה ותכונות אדמין. ניהול משתמשים
מאפשר תביעה קלה של מכשירים וסנכרון נתונים. משתמש קצה
תכונות מאפשרות שליטה מרחוק במכשירים באמצעות אפליקציה לנייד או
web מִמְשָׁק. תכונות הניהול מספקות כלים לניטור מכשירים
וניהול.
ESP32-C3 הרפתקאות אלחוטיות
מדריך מקיף ל-IoT
Espressif Systems 12 ביוני 2023
תוֹכֶן
I הכנה
1
1 מבוא ל-IoT
3
1.1 ארכיטקטורת IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 אפליקציית IoT בבתים חכמים. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 מבוא ותרגול של פרויקטי IoT
9
2.1 מבוא לפרויקטי IoT טיפוסיים. . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 מודולים בסיסיים עבור התקני IoT נפוצים . . . . . . . . . . . . . . . . . 9
2.1.2 מודולים בסיסיים של יישומי לקוח. . . . . . . . . . . . . . . . . . . 10
2.1.3 מבוא לפלטפורמות ענן IoT נפוצות . . . . . . . . . . . . . . 11
2.2 תרגול: פרויקט אור חכם . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 מבנה הפרויקט . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 פונקציות הפרויקט . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 הכנת חומרה . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 תהליך פיתוח . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 מבוא ל-ESP RainMaker
19
3.1 מהו ESP RainMaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 היישום של ESP RainMaker. . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 שירות תביעה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 סוכן RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 קצה ענן . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4 RainMaker Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 תרגול: נקודות מפתח לפיתוח עם ESP RainMaker . . . . . . . . . . . . 25
3.4 תכונות של ESP RainMaker. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 ניהול משתמשים . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 תכונות משתמש קצה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.3 תכונות ניהול . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 הגדרת סביבת פיתוח
31
4.1 ESP-IDF נגמרview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 גרסאות ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3
4.1.2 זרימת עבודה של ESP-IDF Git . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 בחירת גרסה מתאימה . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4 נגמרview של ESP-IDF SDK Directory . . . . . . . . . . . . . . . . . . . . 34 4.2 הגדרת סביבת פיתוח ESP-IDF . . . . . . . . . . . . . . . . . 38 4.2.1 הגדרת סביבת פיתוח ESP-IDF על לינוקס . . . . . . . . 38 4.2.2 הגדרת סביבת פיתוח ESP-IDF ב-Windows . . . . . . 40 4.2.3 הגדרת סביבת פיתוח ESP-IDF ב-Mac . . . . . . . . . 45 4.2.4 התקנת קוד VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 מבוא לסביבות פיתוח של צד שלישי . . . . . . . . 46 4.3 מערכת הידור ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 מושגים בסיסיים של מערכת קומפילציה . . . . . . . . . . . . . . . . . . 47 4.3.2 פרויקט File מבנה . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 כללי בנייה ברירת מחדל של מערכת הקומפילציה . . . . . . . . . . . . . 50 4.3.4 מבוא לתסריט הקומפילציה . . . . . . . . . . . . . . . . . . 51 4.3.5 מבוא לפקודות נפוצות . . . . . . . . . . . . . . . . . . . 52 4.4 תרגול: קומפילציה דוגמהampהתוכנית "מצמוץ". . . . . . . . . . . . . . . . . . 53 4.4.1 דוגמהampלניתוח. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2 הידור של תוכנית ה-Blink . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 מהבהב תוכנית ההבהוב . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 ניתוח יומן יציאות טוריות של תוכנית ההבהוב. . . . . . . . . . . . . . 60 4.5 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
II פיתוח חומרה ומנהלי התקנים
65
5 עיצוב חומרה של מוצרי Smart Light המבוססים על ESP32-C3
67
5.1 תכונות והרכב של מוצרי אור חכם. . . . . . . . . . . . . . . 67
5.2 עיצוב חומרה של מערכת הליבה ESP32-C3 . . . . . . . . . . . . . . . . . . . 70
5.2.1 אספקת חשמל . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.2 רצף הפעלה ואיפוס מערכת . . . . . . . . . . . . . . . . . . 74
5.2.3 פלאש SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.4 מקור שעון . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.5 RF ואנטנה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.6 סיכות רצועות . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.7 בקר GPIO ו-PWM . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 תרגול: בניית מערכת אור חכמה עם ESP32-C3 . . . . . . . . . . . . . 80
5.3.1 בחירת מודולים . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.2 הגדרת GPIO של אותות PWM. . . . . . . . . . . . . . . . . . . . 82
5.3.3 הורדת קושחה וממשק ניפוי באגים . . . . . . . . . . . . 82
5.3.4 הנחיות לתכנון RF . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 הנחיות לתכנון ספק כוח . . . . . . . . . . . . . . . . . . . 86 5.4 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6 פיתוח דרייברים
87
6.1 תהליך פיתוח דרייברים . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 יישומים היקפיים ESP32-C3 . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3 יסודות מנהל התקן LED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.1 מרחבי צבע . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.2 מנהל התקן LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3.3 עמעום LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3.4 מבוא ל-PWM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.4 פיתוח דרייבר לעמעום LED. . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.1 אחסון לא נדיף (NVS) . . . . . . . . . . . . . . . . . . . . . . . . 97
6.4.2 בקר LED PWM (LEDC) . . . . . . . . . . . . . . . . . . . . . . . 98
6.4.3 תכנות LED PWM . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.5 תרגול: הוספת דרייברים לפרויקט אור חכם . . . . . . . . . . . . . . . . . 103
6.5.1 מנהל התקן לחצנים . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.5.2 דרייבר לעמעום LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.6 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
III תקשורת ובקרה אלחוטית
109
7 תצורה וחיבור של Wi-Fi
111
7.1 יסודות ה-Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1.1 מבוא ל-Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1.2 התפתחות של IEEE 802.11. . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1.3 מושגי Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.1.4 חיבור Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2 יסודות בלוטות'. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.2.1 מבוא ל-Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.2.2 מושגי בלוטות' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.2.3 חיבור בלוטות' . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.3 תצורת רשת Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.3.1 מדריך תצורת רשת Wi-Fi . . . . . . . . . . . . . . . . . . . . 131
7.3.2 SoftAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.3.3 SmartConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.3.4 בלוטות' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.3.5 שיטות אחרות . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.4 תכנות Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 רכיבי Wi-Fi ב-ESP-IDF . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 תרגיל: חיבור Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 תרגיל: חיבור Wi-Fi חכם . . . . . . . . . . . . . . . . . . . . . 145
7.5 תרגול: תצורת Wi-Fi בפרויקט אור חכם . . . . . . . . . . . . . . . 156 7.5.1 חיבור Wi-Fi בפרויקט אור חכם . . . . . . . . . . . . . . . . . 156 7.5.2 תצורת Wi-Fi חכמה . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
8 שליטה מקומית
159
8.1 מבוא לבקרה מקומית. . . . . . . . . . . . . . . . . . . . . . . . . . . 159
8.1.1 יישום בקרה מקומית. . . . . . . . . . . . . . . . . . . . . . . . 161
8.1.2 אדוואןtages של שליטה מקומית. . . . . . . . . . . . . . . . . . . . . . . . 161
8.1.3 גילוי מכשירים מבוקרים באמצעות סמארטפונים . . . . . . . . . . 161
8.1.4 תקשורת נתונים בין סמארטפונים ומכשירים . . . . . . . . 162
8.2 שיטות גילוי מקומיות נפוצות. . . . . . . . . . . . . . . . . . . . . . . . 162
8.2.1 שידור . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.2.2 שידור רב . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.2.3 השוואה בין שידור למולטי שידור . . . . . . . . . . . . . . 176
8.2.4 Protocol Application Multicast mDNS לגילוי מקומי. . . . . . . . 176
8.3 פרוטוקולי תקשורת נפוצים עבור נתונים מקומיים. . . . . . . . . . . . . . . 179
8.3.1 פרוטוקול בקרת שידור (TCP) . . . . . . . . . . . . . . . . . . . 179
8.3.2 פרוטוקול HyperText Transfer (HTTP) . . . . . . . . . . . . . . . . . . . 185
8.3.3 משתמש דאtagפרוטוקול ram (UDP) . . . . . . . . . . . . . . . . . . . . . . 189
8.3.4 פרוטוקול יישום מוגבל (CoAP) . . . . . . . . . . . . . . . . 192
8.3.5 פרוטוקול בלוטות' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
8.3.6 סיכום פרוטוקולי תקשורת נתונים. . . . . . . . . . . . . . . 203
8.4 אחריות לאבטחת מידע . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8.4.1 מבוא לאבטחת שכבת תחבורה (TLS) . . . . . . . . . . . . . 207
8.4.2 מבוא לדאtagRam Transport Layer Security (DTLS) . . . . . . . 213
8.5 תרגול: שליטה מקומית בפרויקט אור חכם. . . . . . . . . . . . . . . . . . 217
8.5.1 יצירת שרת בקרה מקומי מבוסס Wi-Fi . . . . . . . . . . . . . . . 217
8.5.2 אימות פונקציונליות הבקרה המקומית באמצעות סקריפטים. . . . . . . . . . . 221
8.5.3 יצירת שרת בקרה מקומי מבוסס Bluetooth . . . . . . . . . . . . 222
8.6 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
9 בקרת ענן
225
9.1 מבוא לשלט רחוק . . . . . . . . . . . . . . . . . . . . . . . . . . 225
9.2 פרוטוקולי תקשורת נתונים בענן . . . . . . . . . . . . . . . . . . . . . . 226
9.2.1 מבוא MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 9.2.2 עקרונות MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.3 פורמט הודעה MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.4 השוואת פרוטוקולים . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5 הגדרת MQTT Broker ב-Linux ו-Windows. . . . . . . . . . . . 233 9.2.6 הגדרת לקוח MQTT בהתבסס על ESP-IDF . . . . . . . . . . . . . . . . 235 9.3 הבטחת אבטחת מידע MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.1 משמעות התעודות ותפקודן. . . . . . . . . . . . . . . . . . . 237 9.3.2 הפקת תעודות באופן מקומי . . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 הגדרת ברוקר MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 הגדרת לקוח MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.4 תרגול: שלט רחוק באמצעות ESP RainMaker . . . . . . . . . . . . . . . . 243 9.4.1 יסודות ESP RainMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.2 פרוטוקול תקשורת קצה וענן עורפי. . . . . . . . . . . 244 9.4.3 תקשורת בין הלקוח ל-Cloud Backend . . . . . . . . . . . 249 9.4.4 תפקידי משתמש . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 שירותים בסיסיים . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.4.6 אור חכם Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.7 יישום RainMaker ושילובים של צד שלישי . . . . . . . . . . . . . . . 262 9.5 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
10 פיתוח אפליקציות לסמארטפון
269
10.1 מבוא לפיתוח אפליקציות לסמארטפון . . . . . . . . . . . . . . . . . . 269
10.1.1 נגמרview של פיתוח אפליקציות לסמארטפון. . . . . . . . . . . . . . . 270
10.1.2 מבנה פרויקט אנדרואיד . . . . . . . . . . . . . . . . . . . . . . 270
10.1.3 מבנה פרויקט iOS . . . . . . . . . . . . . . . . . . . . . . . . 271
10.1.4 מחזור החיים של פעילות אנדרואיד . . . . . . . . . . . . . . . . . . . . . . 272
10.1.5 מחזור החיים של iOS Viewבקר . . . . . . . . . . . . . . . . . . . . . . 273
10.2 יצירת פרויקט אפליקציה חדש לסמארטפון . . . . . . . . . . . . . . . . . . . . . 275
10.2.1 הכנה לפיתוח אנדרואיד . . . . . . . . . . . . . . . . . . . 275
10.2.2 יצירת פרויקט אנדרואיד חדש . . . . . . . . . . . . . . . . . . . . . . 275
10.2.3 הוספת תלות עבור MyRainmaker . . . . . . . . . . . . . . . . . 276
10.2.4 בקשת הרשאה באנדרואיד . . . . . . . . . . . . . . . . . . . . . . 277
10.2.5 הכנה לפיתוח iOS . . . . . . . . . . . . . . . . . . . . . . 277
10.2.6 יצירת פרויקט iOS חדש . . . . . . . . . . . . . . . . . . . . . . . . 278
10.2.7 הוספת תלות עבור MyRainmaker . . . . . . . . . . . . . . . . . 279
10.2.8 בקשת הרשאה ב-iOS . . . . . . . . . . . . . . . . . . . . . . . . . 280
10.3 ניתוח הדרישות הפונקציונליות של האפליקציה . . . . . . . . . . . . . . . . . . 281
10.3.1 ניתוח הדרישות הפונקציונליות של הפרויקט . . . . . . . . . . . . 282
10.3.2 ניתוח דרישות ניהול משתמשים . . . . . . . . . . . . . . . 282 10.3.3 ניתוח דרישות אספקת מכשירים ומחייבים. . . . . . . 283 10.3.4 ניתוח דרישות שליטה מרחוק . . . . . . . . . . . . . . . . 283 10.3.5 ניתוח דרישות תזמון . . . . . . . . . . . . . . . . . . . 284 10.3.6 ניתוח דרישות מרכז המשתמשים . . . . . . . . . . . . . . . . . . 285 10.4 פיתוח ניהול משתמשים . . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.1 מבוא לממשקי API של RainMaker . . . . . . . . . . . . . . . . . . . . . . 285 10.4.2 ייזום תקשורת באמצעות הטלפון החכם . . . . . . . . . . . . . . . . 286 10.4.3 רישום חשבון . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 10.4.4 התחברות לחשבון . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 10.5 פיתוח אספקת התקנים . . . . . . . . . . . . . . . . . . . . . . . 292 10.5.1 התקני סריקה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 10.5.2 חיבור התקנים . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.5.3 יצירת מפתחות סודיים . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.4 קבלת מזהה צומת . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.5 התקני אספקה . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 10.6 פיתוח בקרת התקנים . . . . . . . . . . . . . . . . . . . . . . . . . . 302 10.6.1 קישור התקנים לחשבונות ענן . . . . . . . . . . . . . . . . . . . . 303 10.6.2 קבלת רשימת התקנים . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.6.3 קבלת מצב המכשיר . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 10.6.4 שינוי מצב מכשיר . . . . . . . . . . . . . . . . . . . . . . . . . . 310 10.7 פיתוח תזמון ומרכז משתמשים . . . . . . . . . . . . . . . . . . . 313 10.7.1 יישום פונקציית תזמון . . . . . . . . . . . . . . . . . . . . 313 10.7.2 יישום מרכז משתמשים . . . . . . . . . . . . . . . . . . . . . . . . . 315 10.7.3 עוד ממשקי API של ענן . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.8 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
11 שדרוג קושחה וניהול גרסאות
321
11.1 שדרוג קושחה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
11.1.1 נגמרview של טבלאות מחיצות. . . . . . . . . . . . . . . . . . . . . . . . 322
11.1.2 תהליך אתחול קושחה . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
11.1.3 נגמרview של מנגנון OTA. . . . . . . . . . . . . . . . . . . . . 326
11.2 ניהול גרסאות קושחה . . . . . . . . . . . . . . . . . . . . . . . . . . 329
11.2.1 סימון קושחה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
11.2.2 החזרה ומניעת החזרה . . . . . . . . . . . . . . . . . . . . . . . . 331
11.3 תרגול: באוויר (OTA) דוגמהample . . . . . . . . . . . . . . . . . . . . . . . 332
11.3.1 שדרוג קושחה באמצעות מארח מקומי . . . . . . . . . . . . . . . . . 332
11.3.2 שדרוג קושחה באמצעות ESP RainMaker . . . . . . . . . . . . . . . 335
11.4 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
IV אופטימיזציה וייצור המוני
343
12 ניהול צריכת חשמל ואופטימיזציה בהספק נמוך
345
12.1 ESP32-C3 ניהול צריכת חשמל . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
12.1.1 קנה מידה תדר דינמי . . . . . . . . . . . . . . . . . . . . . . . . 346
12.1.2 תצורת ניהול צריכת חשמל . . . . . . . . . . . . . . . . . . . . 348
12.2 ESP32-C3 מצב צריכת חשמל נמוכה . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
12.2.1 מצב שינה מודם . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
12.2.2 מצב שינה קלה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
12.2.3 מצב שינה עמוקה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
12.2.4 צריכת זרם במצבי חשמל שונים. . . . . . . . . . . . . 358
12.3 ניהול צריכת חשמל ואיתור באגים בהספק נמוך . . . . . . . . . . . . . . . . . 359
12.3.1 איתור באגים ביומן . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
12.3.2 איתור באגים GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
12.4 תרגול: ניהול חשמל בפרויקט אור חכם. . . . . . . . . . . . . . . 363
12.4.1 הגדרת תכונת ניהול צריכת חשמל . . . . . . . . . . . . . . . . . 364
12.4.2 שימוש במנעולי ניהול צריכת חשמל . . . . . . . . . . . . . . . . . . . . . . 365
12.4.3 אימות צריכת חשמל . . . . . . . . . . . . . . . . . . . . . . . 366
12.5 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
13 תכונות אבטחת מכשיר משופרות
369
13.1 נגמרview של אבטחת נתונים של מכשירי IoT. . . . . . . . . . . . . . . . . . . . . . . 369
13.1.1 מדוע אבטחת נתוני מכשירי IoT? . . . . . . . . . . . . . . . . . . . . . . 370
13.1.2 דרישות בסיסיות לאבטחת נתונים של מכשירי IoT . . . . . . . . . . . . 371
13.2 הגנת שלמות נתונים . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.2.1 מבוא לשיטת אימות יושרה. . . . . . . . . . . . . . 372
13.2.2 אימות תקינות של נתוני קושחה . . . . . . . . . . . . . . . . . . 373
13.2.3 דוגמאותample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
13.3 הגנת סודיות נתונים . . . . . . . . . . . . . . . . . . . . . . . . . . 374
13.3.1 מבוא להצפנת נתונים . . . . . . . . . . . . . . . . . . . . . . 374
13.3.2 מבוא לתוכנית הצפנת פלאש. . . . . . . . . . . . . . . . . 376
13.3.3 אחסון מפתח הצפנת פלאש . . . . . . . . . . . . . . . . . . . . . . . 379
13.3.4 מצב עבודה של הצפנת פלאש . . . . . . . . . . . . . . . . . . . . 380
13.3.5 תהליך הצפנת פלאש . . . . . . . . . . . . . . . . . . . . . . . . . . 381
13.3.6 מבוא להצפנת NVS . . . . . . . . . . . . . . . . . . . . . . 383
13.3.7 דוגמאותampמידע על הצפנת פלאש והצפנת NVS. . . . . . . . . . . 384
13.4 הגנה על חוקיות נתונים . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
13.4.1 מבוא לחתימה דיגיטלית . . . . . . . . . . . . . . . . . . . . . 386
13.4.2 נגמרview של Secure Boot Scheme . . . . . . . . . . . . . . . . . . . . . 388
13.4.3 מבוא לאתחול מאובטח של תוכנה. . . . . . . . . . . . . . . . . . . 388 13.4.4 מבוא לאתחול מאובטח של חומרה . . . . . . . . . . . . . . . . . . 390 13.4.5 דוגמהamples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 13.5 תרגול: תכונות אבטחה בייצור המוני . . . . . . . . . . . . . . . . . . 396 13.5.1 הצפנת פלאש ואתחול מאובטח . . . . . . . . . . . . . . . . . . . . . 396 13.5.2 הפעלת הצפנת פלאש ואתחול מאובטח עם כלי פלאש אצווה . . 397 13.5.3 הפעלת הצפנת פלאש ואתחול מאובטח בפרויקט אור חכם . . . 398 13.6 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
14 צריבת קושחה ובדיקות לייצור המוני
399
14.1 צריבת קושחה בייצור המוני . . . . . . . . . . . . . . . . . . . . . . 399
14.1.1 הגדרת מחיצות נתונים . . . . . . . . . . . . . . . . . . . . . . . . . . 399
14.1.2 צריבת קושחה . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
14.2 בדיקות ייצור המוני . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
14.3 תרגול: נתוני ייצור המוני בפרויקט אור חכם. . . . . . . . . . . . . 404
14.4 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
15 תובנות ESP: פלטפורמת ניטור מרחוק
405
15.1 מבוא ל-ESP Insights. . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
15.2 תחילת העבודה עם ESP Insights . . . . . . . . . . . . . . . . . . . . . . . . . 409
15.2.1 תחילת העבודה עם ESP Insights בפרויקט esp-insights . . . . . . 409
15.2.2 דוגמה להפעלהample בפרויקט esp-insights . . . . . . . . . . . . . . . 411
15.2.3 דיווח על מידע Coredump . . . . . . . . . . . . . . . . . . . . . 411
15.2.4 התאמה אישית של יומני עניין . . . . . . . . . . . . . . . . . . . . . . . . 412
15.2.5 דיווח על סיבת אתחול מחדש . . . . . . . . . . . . . . . . . . . . . . . . . 413
15.2.6 דיווח על מדדים מותאמים אישית . . . . . . . . . . . . . . . . . . . . . . . . . 413
15.3 תרגול: שימוש בתובנות ESP בפרויקט אור חכם. . . . . . . . . . . . . . . 416
15.4 סיכום . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
מָבוֹא
ESP32-C3 הוא מיקרו-בקר SoC של Wi-Fi ליבה אחת ו-Bluetooth 5 (LE), המבוסס על ארכיטקטורת RISC-V בקוד פתוח. הוא יוצר את האיזון הנכון בין כוחות, יכולות קלט/פלט ואבטחה, ובכך מציע את הפתרון האופטימלי וחסכוני עבור התקנים מחוברים. כדי להראות יישומים שונים של משפחת ה-ESP32-C3, ספר זה מאת Espressif ייקח אותך למסע מעניין דרך AIoT, החל מהיסודות של פיתוח פרויקטים של IoT והגדרת סביבה ועד אקס מעשיamples. ארבעת הפרקים הראשונים מדברים על IoT, ESP RainMaker ו-ESP-IDF. פרק 5 ו-6 קצר על עיצוב חומרה ופיתוח מנהלי התקנים. ככל שתתקדם, תגלה כיצד להגדיר את הפרויקט שלך באמצעות רשתות Wi-Fi ואפליקציות לנייד. לבסוף, תלמד לייעל את הפרויקט שלך ולהכניס אותו לייצור המוני.
אם אתה מהנדס בתחומים קשורים, ארכיטקט תוכנה, מורה, סטודנט או כל אחד שיש לו עניין ב-IoT, הספר הזה הוא בשבילך.
אתה יכול להוריד את הקוד למשלampהשתמשו בספר זה מהאתר של Espressif ב-GitHub. למידע עדכני על פיתוח IoT, עקוב אחר החשבון הרשמי שלנו.
הַקדָמָה
עולם מידע
כשהיא רוכבת על גל האינטרנט, Internet of Things (IoT) עשתה את הופעת הבכורה הגדולה שלה והפכה לסוג חדש של תשתית בכלכלה הדיגיטלית. כדי לקרב את הטכנולוגיה לציבור, Espressif Systems פועלת למען החזון לפיו מפתחים מכל תחומי החיים יכולים להשתמש ב-IoT כדי לפתור כמה מהבעיות הדוחקות ביותר של זמננו. עולם של "רשת אינטליגנטית של כל הדברים" הוא מה שאנו מצפים מהעתיד.
עיצוב השבבים שלנו מהווה מרכיב קריטי בחזון זה. זה אמור להיות מרתון, הדורש פריצות דרך מתמדות מול גבולות טכנולוגיים. מ-"Game Changer" ESP8266 לסדרת ESP32 המשלבת קישוריות Wi-Fi ו-Bluetoothr (LE), ואחריה ESP32-S3 המצוידת בהאצת AI, Espressif לא מפסיקה לחקור ולפתח מוצרים לפתרונות AIoT. עם תוכנת הקוד הפתוח שלנו, כגון IoT Development Framework ESP-IDF, Mesh Development Framework ESP-MDF ו-Device Connectivity Platform ESP RainMaker, יצרנו מסגרת עצמאית לבניית יישומי AIoT.
נכון ליולי 2022, המשלוחים המצטברים של ערכות ה-IoT של Espressif עלו על 800 מיליון, מה שמוביל בשוק ה-Wi-Fi MCU ומפעיל מספר עצום של מכשירים מחוברים ברחבי העולם. השאיפה למצוינות הופכת כל מוצר Espressif ללהיט גדול בשל רמת האינטגרציה הגבוהה שלו ויעילות העלות שלו. שחרורו של ESP32-C3 מסמן אבן דרך משמעותית בטכנולוגיה שפותחה בעצמה של Espressif. זהו MCU בעל ליבה אחת, 32 סיביות, מבוסס RISC-V עם 400KB של SRAM, שיכול לפעול במהירות של 160MHz. הוא משולב 2.4 GHz Wi-Fi ו-Bluetooth 5 (LE) עם תמיכה לטווח ארוך. הוא יוצר איזון דק של כוח, יכולות קלט/פלט ואבטחה, ובכך מציע את הפתרון החסכוני האופטימלי עבור מכשירים מחוברים. בהתבסס על ESP32-C3 חזק כל כך, ספר זה נועד לעזור לקוראים להבין את הידע הקשור ל-IoT עם המחשה מפורטת ואקס מעשיamples.
למה כתבנו את הספר הזה?
Espressif Systems היא יותר מחברת מוליכים למחצה. זוהי גם חברת פלטפורמת IoT, שתמיד שואפת לפריצות דרך וחידושים בתחום הטכנולוגיה. במקביל, Espressif פיתחה קוד פתוח ושיתפה את מערכת ההפעלה ומסגרת התוכנה שפותחה בעצמה עם הקהילה, ויצרה מערכת אקולוגית ייחודית. מהנדסים, יצרנים וחובבי טכנולוגיה מפתחים באופן פעיל יישומי תוכנה חדשים המבוססים על המוצרים של Espressif, מתקשרים בחופשיות ומשתפים את הניסיון שלהם. אתה יכול לראות רעיונות מרתקים של מפתחים בפלטפורמות שונות כל הזמן, כמו YouTube ו-GitHub. הפופולריות של מוצרי Espressif עוררה מספר גדל והולך של סופרים שהפיקו למעלה מ-100 ספרים המבוססים על ערכות שבבים של Espressif, ביותר מעשר שפות, כולל אנגלית, סינית, גרמנית, צרפתית ויפנית.
התמיכה והאמון של שותפים בקהילה הם שמעודדים את החדשנות המתמשכת של Espressif. "אנו שואפים להפוך את השבבים, מערכות ההפעלה, המסגרות, הפתרונות, הענן, הפרקטיקות העסקיות, הכלים, התיעוד, הכתבים, הרעיונות וכו', לרלוונטיים מתמיד לתשובות שאנשים צריכים בבעיות הקשות ביותר של החיים העכשוויים. זהו השאיפה והמצפן המוסרי הגבוהים ביותר של אספרסייף". אמר מר Teo Swee Ann, מייסד ומנכ"ל Espressif.
אספרסיף מעריך קריאה ורעיונות. מכיוון שהשדרוג המתמשך של טכנולוגיית ה-IoT מציב דרישות גבוהות יותר למהנדסים, כיצד נוכל לעזור ליותר אנשים לשלוט במהירות בשבבי IoT, מערכות הפעלה, מסגרות תוכנה, תוכניות יישומים ומוצרי שירותי ענן? כמו שנאמר, עדיף ללמד אדם לדוג מאשר לתת לו דגים. בפגישת סיעור מוחות, עלה בדעתנו שאנחנו יכולים לכתוב ספר כדי למיין באופן שיטתי את הידע המרכזי של פיתוח IoT. הצלחנו, אספנו במהירות קבוצה של מהנדסים בכירים, ושילבנו את הניסיון של הצוות הטכני בתכנות משובצות, פיתוח חומרה ותוכנה של IoT, כולם תרמו לפרסום הספר הזה. בתהליך הכתיבה ניסינו כמיטב יכולתנו להיות אובייקטיביים והוגנים, פשטנו מהפקעת, ולהשתמש בביטויים תמציתיים כדי לספר את המורכבות והקסם של האינטרנט של הדברים. סיכמנו בקפידה את השאלות הנפוצות, התייחסנו למשוב ולהצעות של הקהילה, על מנת לענות בבירור על השאלות שנתקלנו בתהליך הפיתוח, ולספק הנחיות מעשיות לפיתוח IoT עבור טכנאים ומקבלי החלטות רלוונטיים.
מבנה הספר
ספר זה לוקח נקודת מבט ממוקדת מהנדס ומסביר את הידע הדרוש לפיתוח פרויקט IoT צעד אחר צעד. הוא מורכב מארבעה חלקים, כדלקמן:
· הכנה (פרק 1): חלק זה מציג את הארכיטקטורה של IoT, מסגרת פרויקט IoT טיפוסית, פלטפורמת הענן ESP RainMakerr, וסביבת הפיתוח ESP-IDF, כדי להניח בסיס איתן לפיתוח פרויקט IoT.
· פיתוח חומרה ומנהלי התקנים (פרק 5): בהתבסס על ערכת השבבים ESP6-C32, חלק זה מרחיב את המינימום של פיתוח מערכת החומרה ומנהלי ההתקן, ומיישם את השליטה בעמעום, דירוג צבעים ותקשורת אלחוטית.
· תקשורת ובקרה אלחוטית (פרק 7): חלק זה מסביר את ערכת תצורת ה-Wi-Fi החכמה המבוססת על שבב ESP11-C32, פרוטוקולי שליטה מקומיים וענן, ושליטה מקומית ומרוחקת של התקנים. הוא גם מספק תוכניות לפיתוח אפליקציות לסמארטפון, שדרוג קושחה וניהול גרסאות.
· אופטימיזציה וייצור המוני (פרק 12-15): חלק זה מיועד ליישומי IoT מתקדמים, תוך התמקדות באופטימיזציה של מוצרים בניהול צריכת חשמל, אופטימיזציה בהספק נמוך ואבטחה משופרת. הוא גם מציג צריבה ובדיקה של קושחה בייצור המוני, וכיצד לאבחן את מצב הריצה והיומנים של קושחת המכשיר באמצעות פלטפורמת הניטור מרחוק ESP Insights.
לגבי קוד המקור
קוראים יכולים להפעיל את האקסampהתוכניות בספר זה, על ידי הזנת הקוד באופן ידני או על ידי שימוש בקוד המקור הנלווה לספר. אנו שמים דגש על השילוב בין תיאוריה ופרקטיקה, וכך קובעים פרק תרגול המבוסס על פרויקט Smart Light כמעט בכל פרק. כל הקודים הם בקוד פתוח. הקוראים מוזמנים להוריד את קוד המקור ולדון בו בסעיפים הקשורים לספר זה ב-GitHub ובפורום הרשמי שלנו esp32.com. הקוד בקוד פתוח של ספר זה כפוף לתנאי Apache License 2.0.
הערת המחבר
ספר זה הופק רשמית על ידי Espressif Systems ונכתב על ידי המהנדסים הבכירים של החברה. זה מתאים למנהלים ואנשי מו"פ בתעשיות הקשורות ל-IoT, מורים וסטודנטים של מגמות קשורות, וחובבי תחום האינטרנט של הדברים. אנו מקווים שספר זה יכול לשמש כמדריך עבודה, עזר וספר ליד המיטה, להיות כמו מורה טוב וחבר.
במהלך עריכת ספר זה, התייחסנו לכמה תוצאות מחקר רלוונטיות של מומחים, חוקרים וטכנאים מבית ומחוץ, ועשינו כמיטב יכולתנו לצטט אותן על פי נורמות אקדמיות. עם זאת, אין מנוס מכך שיהיו כמה השמטות, אז כאן ברצוננו להביע כבוד עמוק ותודתנו לכל הכותבים הרלוונטיים. בנוסף, ציטטנו מידע מהאינטרנט, ולכן ברצוננו להודות לכותבים ולמפרסמים המקוריים ולהתנצל שאיננו יכולים לציין את המקור של כל פיסת מידע.
על מנת להפיק ספר באיכות גבוהה, ארגנו סבבים של דיונים פנימיים, ולמדנו מההצעות והמשוב של קוראי הניסיון ועורכי ההוצאה לאור. כאן, ברצוננו להודות לך שוב על עזרתך אשר תרמה כולם לעבודה מוצלחת זו.
אחרון, אבל הכי חשוב, תודה לכל מי באספרסיף שעבד כל כך קשה למען הלידה והפופולריות של המוצרים שלנו.
פיתוח פרויקטי IoT כרוך במגוון רחב של ידע. מוגבל לאורכו של הספר, כמו גם לרמתו ולנסיונו של המחבר, השמטות בלתי נמנעות. לכן, אנו מבקשים ממומחים וקוראים לבקר ולתקן את הטעויות שלנו. אם יש לך הצעות לספר זה, אנא צור איתנו קשר בכתובת book@espressif.com. אנו מצפים למשוב שלך.
איך להשתמש בספר הזה?
הקוד של הפרויקטים בספר זה היה בקוד פתוח. אתה יכול להוריד אותו ממאגר GitHub שלנו ולשתף את המחשבות והשאלות שלך בפורום הרשמי שלנו. GitHub: https://github.com/espressif/book-esp32c3-iot-projects Forum: https://www.esp32.com/bookc3 לאורך הספר, יהיו חלקים מודגשים כפי שמוצג להלן.
קוד המקור בספר זה, אנו שמים דגש על השילוב של תיאוריה ופרקטיקה, וכך קובעים פרק תרגול על פרויקט האור החכם כמעט בכל פרק. השלבים המתאימים ודף המקור יסומנו בין שתי שורות המתחילות ב- tag קוד מקור.
הערה/טיפים זה המקום שבו תוכל למצוא מידע קריטי ותזכורת לניפוי באגים בהצלחה בתוכנית שלך. הם יסומנו בין שני קווים עבים המתחילים ב- tag הערה או טיפים.
רוב הפקודות בספר זה מבוצעות תחת לינוקס, הנחיה על ידי התו "$". אם הפקודה דורשת הרשאות משתמש-על לביצוע, ההנחיה תוחלף ב-"#". שורת הפקודה במערכות Mac היא "%", כפי שנעשה בה שימוש בסעיף 4.2.3 התקנת ESP-IDF ב-Mac.
גוף הטקסט בספר זה יודפס ב-Charter, בעוד שהקוד examples, רכיבים, פונקציות, משתנים, קוד file שמות, ספריות קוד ומחרוזות יהיו ב-Courier New.
פקודות או טקסטים שצריך להזין על ידי המשתמש, ופקודות שניתן להזין על ידי לחיצה על מקש "Enter" יודפסו באותיות Courier New מודגשות. יומנים ובלוקי קוד יוצגו בקופסאות תכלת.
Exampעל:
שנית, השתמש ב-esp-idf/components/nvs flash/nvs מחיצת מחולל/nvs partition gen.py כדי ליצור את המחיצה הבינארית של NVS file על מארח הפיתוח עם הפקודה הבאה:
$ python $IDF PATH/components/nvs מחולל מחיצות flash/nvs/מחיצת nvs gen.py –input mass prod.csv –output mass prod.bin –size NVS PARTITION SIZE
פרק 1
מָבוֹא
אֶל
IoT
בסוף המאה ה-20, עם עליית רשתות המחשבים וטכנולוגיות התקשורת, האינטרנט השתלב במהירות בחייהם של אנשים. ככל שטכנולוגיית האינטרנט ממשיכה להתבגר, הרעיון של האינטרנט של הדברים (IoT) נולד. פשוטו כמשמעו, IoT פירושו אינטרנט שבו דברים מחוברים. בעוד שהאינטרנט המקורי שובר את גבולות המרחב והזמן ומצמצם את המרחק בין "אדם לאדם", IoT הופך את "הדברים" למשתתף חשוב, ומקרב בין "אנשים" ל"דברים". בעתיד הנראה לעין, IoT אמור להפוך לכוח המניע של תעשיית המידע.
אז מה זה האינטרנט של הדברים?
קשה להגדיר במדויק את האינטרנט של הדברים, מכיוון שמשמעותו והיקפו מתפתחים כל הזמן. בשנת 1995, ביל גייטס העלה לראשונה את רעיון ה-IoT בספרו The Road Ahead. במילים פשוטות, IoT מאפשר לאובייקטים להחליף מידע זה עם זה דרך האינטרנט. המטרה הסופית שלה היא להקים "אינטרנט של הכל". זוהי פרשנות מוקדמת של IoT, כמו גם פנטזיה של טכנולוגיה עתידית. שלושים שנה לאחר מכן, עם ההתפתחות המהירה של הכלכלה והטכנולוגיה, הפנטזיה מתממשת. ממכשירים חכמים, בתים חכמים, ערים חכמות, אינטרנט של כלי רכב ומכשירים לבישים, ועד ל-"metaverse" הנתמך על ידי טכנולוגיות IoT, מושגים חדשים צצים כל הזמן. בפרק זה נתחיל בהסבר על הארכיטקטורה של האינטרנט של הדברים, ולאחר מכן נציג את אפליקציית ה-IoT הנפוצה ביותר, הבית החכם, על מנת לעזור לכם לקבל הבנה ברורה של IoT.
1.1 ארכיטקטורת IoT
האינטרנט של הדברים כולל טכנולוגיות מרובות שיש להן צורכי יישום שונים וצורות שונות בתעשיות שונות. על מנת למיין את המבנה, טכנולוגיות המפתח ומאפייני היישום של ה-IoT, יש צורך להקים ארכיטקטורה מאוחדת ומערכת טכנית סטנדרטית. בספר זה, הארכיטקטורה של IoT מחולקת בפשטות לארבע שכבות: שכבת תפיסה ובקרה, שכבת רשת, שכבת פלטפורמה ושכבת יישום.
שכבת תפיסה ובקרה כמרכיב הבסיסי ביותר בארכיטקטורת ה-IoT, שכבת התפיסה והשליטה היא הליבה למימוש החישה המקיפה של IoT. תפקידו העיקרי הוא לאסוף, לזהות ולשלוט במידע. הוא מורכב ממגוון מכשירים בעלי יכולת תפיסה,
3
זיהוי, בקרה וביצוע, ואחראי לאחזור וניתוח נתונים כגון תכונות החומר, מגמות התנהגות ומצב המכשיר. בדרך זו, IoT זוכה לזהות את העולם הפיזי האמיתי. חוץ מזה, השכבה מסוגלת גם לשלוט על מצב המכשיר.
המכשירים הנפוצים ביותר בשכבה זו הם חיישנים שונים, אשר ממלאים תפקיד חשוב באיסוף וזיהוי מידע. חיישנים דומים לאיברי חישה אנושיים, כמו חיישנים רגישים לאור השווים לראייה, חיישנים אקוסטיים לשמיעה, חיישני גז לריח, וחיישנים רגישים ללחץ וטמפרטורה למגע. עם כל "איברי החישה" הללו, אובייקטים הופכים ל"חיים" ומסוגלים לתפיסה, הכרה ומניפולציה אינטליגנטית של העולם הפיזי.
שכבת הרשת התפקיד העיקרי של שכבת הרשת הוא להעביר מידע, כולל נתונים המתקבלים משכבת התפיסה והבקרה ליעד שצוין, כמו גם פקודות המונפקות משכבת היישום חזרה לשכבת התפיסה והשליטה. הוא משמש כגשר תקשורת חשוב המחבר בין שכבות שונות של מערכת IoT. כדי להקים מודל בסיסי של האינטרנט של הדברים, זה כרוך בשני שלבים לשילוב אובייקטים ברשת: גישה לאינטרנט ושידור דרך האינטרנט.
גישה לאינטרנט באינטרנט מאפשרת חיבור בין אדם לאדם, אך לא מצליחה לכלול דברים במשפחה הגדולה. לפני הופעת ה-IoT, רוב הדברים לא היו "ניתנים לרשת". הודות להתפתחות מתמשכת של הטכנולוגיה, ה-IoT מצליח לחבר דברים לאינטרנט, ובכך מממש חיבור בין "אנשים ודברים", ל"דברים ודברים". ישנן שתי דרכים נפוצות ליישם חיבור לאינטרנט: גישה לרשת קווית וגישה לרשת אלחוטית.
שיטות גישה לרשת קווית כוללות Ethernet, תקשורת טורית (למשל, RS-232, RS-485) ו-USB, בעוד שגישה לרשת אלחוטית תלויה בתקשורת אלחוטית, אותה ניתן לחלק עוד יותר לתקשורת אלחוטית לטווח קצר ותקשורת אלחוטית לטווח ארוך.
תקשורת אלחוטית לטווח קצר כוללת ZigBee, Bluetoothr, Wi-Fi, תקשורת קרובה לשדה (NFC) וזיהוי תדר רדיו (RFID). תקשורת אלחוטית ארוכת טווח כוללת תקשורת מסוג מכונה משופרת (eMTC), LoRa, Narrow Band Internet of Things (NB-IoT), 2G, 3G, 4G, 5G וכו'.
שידור דרך האינטרנט שיטות שונות של גישה לאינטרנט מובילות לקישור שידור פיזי תואם של נתונים. הדבר הבא הוא להחליט באיזה פרוטוקול תקשורת להשתמש כדי להעביר את הנתונים. בהשוואה למסופי אינטרנט, ברוב מסופי ה-IoT יש כיום פחות
4 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
משאבים זמינים, כגון ביצועי עיבוד, קיבולת אחסון, קצב רשת וכו', ולכן יש צורך לבחור בפרוטוקול תקשורת שתופס פחות משאבים ביישומי IoT. ישנם שני פרוטוקולי תקשורת שנמצאים בשימוש נרחב כיום: Message Queuing Telemetry Transport (MQTT) ו-Constrained Application Protocol (CoAP).
שכבת הפלטפורמה שכבת הפלטפורמה מתייחסת בעיקר לפלטפורמות ענן של IoT. כאשר כל מסופי ה-IoT מחוברים לרשת, הנתונים שלהם צריכים להיות מצטברים בפלטפורמת ענן IoT כדי לחשב ולאחסן. שכבת הפלטפורמה תומכת בעיקר ביישומי IoT בהקלת גישה וניהול של מכשירים מסיביים. הוא מחבר מסופי IoT לפלטפורמת הענן, אוסף נתוני מסוף ומנפיק פקודות למסופים, כדי ליישם שליטה מרחוק. כשירות ביניים להקצאת ציוד ליישומי תעשייה, שכבת הפלטפורמה ממלאת תפקיד מקשר בארכיטקטורת ה-IoT כולה, נושאת לוגיקה עסקית מופשטת ומודל נתוני ליבה סטנדרטי, שיכולים לא רק לממש גישה מהירה למכשירים, אלא גם לספק יכולות מודולריות חזקות. כדי לענות על צרכים שונים בתרחישי יישומים בתעשייה. שכבת הפלטפורמה כוללת בעיקר מודולים פונקציונליים כגון גישה למכשירים, ניהול מכשירים, ניהול אבטחה, תקשורת מסרים, ניטור תפעול ותחזוקה, ויישומי נתונים.
· גישה למכשיר, מימוש החיבור והתקשורת בין מסופים ופלטפורמות ענן IoT.
· ניהול התקנים, לרבות פונקציות כגון יצירת מכשירים, תחזוקת מכשירים, המרת נתונים, סנכרון נתונים והפצת מכשירים.
· ניהול אבטחה, הבטחת אבטחת העברת הנתונים של IoT מנקודות מבט של אימות אבטחה ואבטחת תקשורת.
· תקשורת הודעות, כולל שלושה כיווני שידור, כלומר הטרמינל שולח נתונים לפלטפורמת הענן של ה-IoT, פלטפורמת הענן של ה-IoT שולחת נתונים לצד השרת או לפלטפורמות ענן אחרות של IoT, וצד השרת שולט מרחוק במכשירי IoT.
· ניטור O&M, הכולל ניטור ואבחון, שדרוג קושחה, איתור באגים מקוון, שירותי יומן וכו'.
· יישומי נתונים, הכוללים אחסון, ניתוח ויישום של נתונים.
שכבת היישום שכבת היישום משתמשת בנתונים משכבת הפלטפורמה לניהול היישום, סינון ועיבודם בכלים כגון מסדי נתונים ותוכנות ניתוח. ניתן להשתמש בנתונים המתקבלים עבור יישומי IoT בעולם האמיתי כגון בריאות חכמה, חקלאות חכמה, בתים חכמים וערים חכמות.
כמובן שניתן לחלק את הארכיטקטורה של IoT לשכבות נוספות, אבל לא משנה כמה שכבות היא מורכבת מהן, העיקרון הבסיסי נשאר זהה. לְמִידָה
פרק 1. מבוא ל-IoT 5
על הארכיטקטורה של IoT עוזרת להעמיק את ההבנה שלנו בטכנולוגיות IoT ולבנות פרויקטי IoT פונקציונליים במלואם.
1.2 אפליקציית IoT בבתים חכמים
IoT חדר לכל תחומי החיים, ואפליקציית ה-IoT הקשורה לנו ביותר היא הבית החכם. מכשירי חשמל מסורתיים רבים מצוידים כעת במכשיר IoT אחד או יותר, ובתים רבים שנבנו לאחרונה מתוכננים עם טכנולוגיות IoT מההתחלה. איור 1.1 מציג כמה התקני בית חכם נפוצים.
איור 1.1. מכשירי בית חכם נפוצים ניתן לחלק את הפיתוח של בית חכם פשוט למוצרים חכמיםtagה, חיבור סצנה סtagה ו אינטליגנטי סtagה, כפי שמוצג באיור 1.2.
איור 1.2. פיתוח סtage of smart home 6 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
הס' הראשוןtage עוסק במוצרים חכמים. בשונה מבתים מסורתיים, בבתים חכמים, מכשירי IoT מקבלים אותות עם חיישנים, ומקושרים ברשת באמצעות טכנולוגיות תקשורת אלחוטיות כגון Wi-Fi, Bluetooth LE ו-ZigBee. משתמשים יכולים לשלוט במוצרים חכמים במגוון דרכים, כגון אפליקציות לסמארטפון, עוזרות קוליות, שליטה ברמקולים חכמים וכו'.tage מתמקד בחיבור בין סצנה. בס' זהtagה, מפתחים כבר לא שוקלים לשלוט במוצר חכם בודד, אלא לחבר שני מוצרים חכמים או יותר, לבצע אוטומציה במידה מסוימת ולבסוף ליצור מצב סצנה מותאם אישית. למשלampאם כן, כאשר המשתמש לוחץ על כפתור מצב סצנה כלשהו, האורות, הווילונות והמזגנים יותאמו אוטומטית להגדרות המוגדרות מראש. כמובן, יש תנאי מוקדם שהלוגיקת הקישור תהיה מוגדרת בקלות, כולל תנאי טריגר ופעולות ביצוע. תארו לעצמכם שמצב חימום מיזוג האוויר מופעל כאשר הטמפרטורה הפנימית יורדת מתחת ל-10 מעלות צלזיוס; שבשעה 7 בבוקר מושמעת מוזיקה כדי להעיר את המשתמש, פותחים וילונות חכמים וסיר האורז או טוסטר הלחם מתחילים דרך שקע חכם; כשהמשתמש קם ומסיים לשטוף, ארוחת הבוקר כבר מוגשת, כך שלא יהיה עיכוב ביציאה לעבודה. כמה נוחים הפכו החיים שלנו! הס' השלישיתtage הולך למודיעין stagה. ככל שניגשים ליותר מכשירי בית חכם, כך גם סוגי הנתונים שנוצרו. בעזרת מחשוב ענן, ביג דאטה ובינה מלאכותית, זה כמו שנשתל "מוח חכם יותר" בבתים חכמים, שאינם דורשים עוד פקודות תכופות מהמשתמש. הם אוספים נתונים מאינטראקציות קודמות ולומדים את דפוסי ההתנהגות וההעדפות של המשתמש, כדי להפוך פעילויות לאוטומטיות, כולל מתן המלצות לקבלת החלטות. נכון לעכשיו, רוב הבתים החכמים נמצאים בזירת הקישוריותtagה. ככל שקצב החדירה והאינטליגנציה של מוצרים חכמים גדלים, מחסומים בין פרוטוקולי תקשורת מוסרים. בעתיד, בתים חכמים עתידים להפוך ל"חכמים" ממש, בדיוק כמו מערכת ה-AI Jarvis ב-Iron Man, שיכולה לא רק לעזור למשתמש לשלוט במכשירים שונים, לטפל בענייני היומיום, אלא גם להיות בעלת כוח מחשוב ויכולת חשיבה סופר. בס' האינטליגנטיtagה, בני אדם יקבלו שירותים טובים יותר הן בכמות והן באיכות.
פרק 1. מבוא ל-IoT 7
8 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
פרק מבוא ותרגול של 2 פרויקטי IoT
בפרק 1, הצגנו את הארכיטקטורה של ה-IoT, ואת התפקידים ויחסי הגומלין של שכבת התפיסה והשליטה, שכבת הרשת, שכבת הפלטפורמה ושכבת האפליקציה, כמו גם את הפיתוח של בית חכם. עם זאת, בדיוק כמו כשאנחנו לומדים לצייר, הכרת הידע התיאורטי רחוקה מלהספיק. עלינו "ללכלך את הידיים" כדי ליישם פרויקטים של IoT כדי לשלוט באמת בטכנולוגיה. בנוסף, כאשר פרויקט עובר למחלקת הייצור ההמוניtagה, יש צורך לשקול גורמים נוספים כגון חיבור לרשת, תצורה, אינטראקציה של פלטפורמת ענן IoT, ניהול קושחה ועדכונים, ניהול ייצור המוני ותצורת אבטחה. אז למה אנחנו צריכים לשים לב כשאנחנו מפתחים פרויקט IoT שלם? בפרק 1, הזכרנו כי בית חכם הוא אחד מתרחישי יישומי ה-IoT הנפוצים ביותר, ונורות חכמות הן אחד המכשירים הבסיסיים והמעשיים ביותר, שניתן להשתמש בהם בבתים, בתי מלון, חדרי כושר, בתי חולים וכו'. בספר זה, ניקח את הבנייה של פרויקט אור חכם כנקודת ההתחלה, נסביר את מרכיביו ותכונותיו, ונספק הנחיות לגבי פיתוח הפרויקט. אנו מקווים שתוכל להסיק מסקנות מהמקרה הזה כדי ליצור יישומי IoT נוספים.
2.1 מבוא לפרויקטי IoT טיפוסיים
במונחים של פיתוח, ניתן לסווג מודולים פונקציונליים בסיסיים של פרויקטי IoT לפיתוח תוכנה וחומרה של התקני IoT, פיתוח אפליקציות לקוח ופיתוח פלטפורמת ענן IoT. חשוב להבהיר את המודולים הפונקציונליים הבסיסיים, שיתוארו עוד בסעיף זה.
2.1.1 מודולים בסיסיים עבור התקני IoT נפוצים
פיתוח תוכנה וחומרה של התקני IoT כולל את המודולים הבסיסיים הבאים: איסוף נתונים
כשכבה התחתונה של ארכיטקטורת ה-IoT, מכשירי ה-IoT של שכבת התפיסה והבקרה מחברים חיישנים והתקנים דרך השבבים והציוד ההיקפי שלהם כדי להשיג איסוף נתונים ובקרת פעולה.
9
קשירת חשבון ותצורה ראשונית עבור רוב מכשירי ה-IoT, קשירת חשבון ותצורה ראשונית מתבצעת בתהליך תפעולי אחד, למשלample, חיבור מכשירים עם משתמשים על ידי הגדרת רשת Wi-Fi.
אינטראקציה עם פלטפורמות ענן של IoT כדי לנטר ולשלוט במכשירי IoT, יש צורך גם לחבר אותם לפלטפורמות ענן של IoT, על מנת לתת פקודות ולדווח על סטטוס באמצעות אינטראקציה זה עם זה.
בקרת מכשירים כאשר הם מחוברים לפלטפורמות ענן של IoT, מכשירים יכולים לתקשר עם הענן ולהיות רשומים, קשורים או נשלטים. משתמשים יכולים לשאול את מצב המוצר ולבצע פעולות אחרות באפליקציית הטלפון החכם באמצעות פלטפורמות ענן של IoT או פרוטוקולי תקשורת מקומיים.
שדרוג קושחה התקני IoT יכולים גם להשיג שדרוג קושחה בהתבסס על צרכי היצרנים. על ידי קבלת פקודות שנשלחות על ידי הענן, יתממשו שדרוג קושחה וניהול גרסאות. עם תכונת שדרוג קושחה זו, אתה יכול לשפר ללא הרף את הפונקציות של מכשירי IoT, לתקן פגמים ולשפר את חווית המשתמש.
2.1.2 מודולים בסיסיים של יישומי לקוח
יישומי לקוח (למשל, אפליקציות לסמארטפון) כוללות בעיקר את המודולים הבסיסיים הבאים:
מערכת חשבון והרשאה זה תומך בהרשאת חשבון ומכשיר.
שליטה במכשיר אפליקציות לסמארטפון מצוידות בדרך כלל בפונקציות שליטה. משתמשים יכולים להתחבר בקלות למכשירי IoT, ולנהל אותם בכל עת ובכל מקום באמצעות אפליקציות לסמארטפון. בבית חכם בעולם האמיתי, המכשירים נשלטים בעיקר באמצעות אפליקציות לסמארטפון, מה שמאפשר לא רק ניהול חכם של מכשירים, אלא גם חוסך בעלויות כוח האדם. לכן, בקרת מכשיר היא חובה עבור יישומי לקוח, כגון בקרת תכונות פונקציית המכשיר, בקרת סצנה, תזמון, שלט רחוק, קישור מכשיר וכו'. משתמשי בית חכם יכולים גם להתאים סצנות לפי צרכים אישיים, שליטה בתאורה, מכשירי חשמל ביתיים, כניסה וכו', כדי להפוך את חיי הבית לנוחים ונוחים יותר. הם יכולים לתזמן את מיזוג האוויר, לכבות אותו מרחוק, להדליק את האור במסדרון באופן אוטומטי לאחר פתיחת הדלת, או לעבור למצב "תיאטרון" עם כפתור בודד אחד.
יישומי Notification Client מעדכנים את סטטוס מכשירי ה-IoT בזמן אמת ושולחים התראות כאשר מכשירים לא תקינים.
10 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
שירות לקוחות לאחר המכירה אפליקציות לסמארטפון יכולות לספק שירותים לאחר המכירה למוצרים, כדי לפתור בעיות הקשורות לתקלות במכשירי IoT ופעולות טכניות בזמן.
פונקציות מומלצות כדי לענות על הצרכים של משתמשים שונים, ניתן להוסיף פונקציות אחרות, כגון Shake, NFC, GPS וכו'. GPS יכול לעזור להגדיר את הדיוק של פעולות הסצנה בהתאם למיקום ולמרחק, בעוד שפונקציית Shake מאפשרת למשתמשים להגדיר את פקודות לביצוע עבור מכשיר או סצנה ספציפיים על ידי רעד.
2.1.3 מבוא לפלטפורמות ענן IoT נפוצות
פלטפורמת ענן IoT היא פלטפורמת הכל באחד המשלבת פונקציות כמו ניהול מכשירים, תקשורת אבטחת נתונים וניהול התראות. על פי קבוצת היעד והנגישות שלהן, ניתן לחלק את פלטפורמות הענן של IoT לפלטפורמות ענן IoT ציבוריות (להלן "ענן ציבורי") ופלטפורמות ענן IoT פרטיות (להלן "ענן פרטי").
ענן ציבורי מציין בדרך כלל פלטפורמות ענן IoT משותפות לארגונים או יחידים, המופעלות ומתוחזקות על ידי ספקי פלטפורמות ומשותפות דרך האינטרנט. זה יכול להיות בחינם או בעלות נמוכה, ומספק שירותים בכל הרשת הציבורית הפתוחה, כגון Alibaba Cloud, Tencent Cloud, Baidu Cloud, AWS IoT, Google IoT וכו'. כפלטפורמה תומכת, ענן ציבורי יכול לשלב ספקי שירותים במעלה הזרם משתמשי קצה במורד הזרם כדי ליצור שרשרת ערך ומערכת אקולוגית חדשה.
ענן פרטי בנוי לשימוש ארגוני בלבד, ובכך מבטיח את השליטה הטובה ביותר על נתונים, אבטחה ואיכות השירות. השירותים והתשתיות שלה מתוחזקות בנפרד על ידי ארגונים, והחומרה והתוכנה התומכות מוקדשות גם למשתמשים ספציפיים. ארגונים יכולים להתאים אישית שירותי ענן כדי לענות על הצרכים של העסק שלהם. נכון לעכשיו, חלק מיצרני הבית החכם כבר קיבלו פלטפורמות ענן IoT פרטיות ופיתחו אפליקציות בית חכם המבוססות עליהן.
לענן ציבורי ולענן פרטי יש יתרון משלהםtages, שיוסבר בהמשך.
כדי להשיג קישוריות תקשורת, יש צורך להשלים לפחות פיתוח מוטבע בצד המכשיר, לצד שרתים עסקיים, פלטפורמות ענן IoT ואפליקציות לסמארטפון. מול פרויקט כה ענק, הענן הציבורי מספק בדרך כלל ערכות פיתוח תוכנה עבור אפליקציות בצד המכשיר והסמארטפון כדי להאיץ את התהליך. ענן ציבורי ופרטי כאחד מספקים שירותים הכוללים גישה למכשיר, ניהול מכשירים, צל מכשיר ותפעול ותחזוקה.
גישה למכשירים פלטפורמות ענן של IoT צריכות לספק לא רק ממשקים לגישה למכשיר באמצעות פרוטוקולים
פרק 2. מבוא ותרגול של פרויקטי IoT 11
כגון MQTT, CoAP, HTTPS ו WebSocket, אלא גם הפונקציה של אימות אבטחת המכשיר לחסום מכשירים מזויפים ולא חוקיים, ומפחיתה למעשה את הסיכון להיפגע. אימות כזה תומך בדרך כלל במנגנונים שונים, ולכן כאשר מכשירים מיוצרים בייצור המוני, יש צורך להקצות מראש את תעודת המכשיר בהתאם למנגנון האימות הנבחר ולצרוב אותו במכשירים.
ניהול מכשירים פונקציית ניהול המכשירים שמסופקת על ידי פלטפורמות הענן של IoT יכולה לא רק לעזור ליצרנים לנטר את מצב ההפעלה והסטטוס המקוון של המכשירים שלהם בזמן אמת, אלא גם מאפשרת אפשרויות כגון הוספה/הסרה של מכשירים, אחזור, הוספה/מחיקה של קבוצות, שדרוג קושחה. , וניהול גרסאות.
Device Shadow IoT ענן פלטפורמות יכולות ליצור גרסה וירטואלית מתמשכת (device shadow) עבור כל מכשיר, וניתן לסנכרן את מצב הצל של המכשיר ולהשיג באמצעות אפליקציית סמארטפון או מכשירים אחרים באמצעות פרוטוקולי שידור באינטרנט. Device shadow מאחסן את הסטטוס המדווח והסטטוס הצפוי של כל מכשיר, וגם אם המכשיר לא מקוון, הוא עדיין יכול לקבל את הסטטוס על ידי קריאה לממשקי API. Device Shadow מספק ממשקי API שפועלים תמיד, מה שמקל על בניית אפליקציות לסמארטפון המקיימות אינטראקציה עם מכשירים.
תפעול ותחזוקה פונקציית ה-O&M כוללת שלושה היבטים: · הדגמת מידע סטטיסטי על התקני IoT והודעות. · ניהול יומן מאפשר אחזור מידע על התנהגות המכשיר, זרימת הודעות מעלה / מטה ותוכן הודעות. · איתור באגים במכשיר תומך בהעברת פקודות, עדכון תצורה ובדיקת האינטראקציה בין פלטפורמות ענן IoT והודעות מכשירים.
2.2 תרגול: פרויקט אור חכם
לאחר ההקדמה התיאורטית בכל פרק, תמצאו קטע תרגול הקשור לפרויקט Smart Light כדי לעזור לכם להתנסות מעשית. הפרויקט מבוסס על שבב ESP32-C3 ו-ESP RainMaker IoT Cloud Platform של Espressif, ומכסה חומרת מודול אלחוטי במוצרי אור חכמים, תוכנות משובצות למכשירים חכמים המבוססים על ESP32C3, אפליקציות לסמארטפון ואינטראקציה של ESP RainMaker.
קוד מקור לשיפור למידה ופיתוח חווית, הפרויקט בספר זה עבר בקוד פתוח. אתה יכול להוריד את קוד המקור ממאגר GitHub שלנו בכתובת https://github. com/espressif/book-esp32c3-iot-projects.
12 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
2.2.1 מבנה הפרויקט
פרויקט Smart Light מורכב משלושה חלקים: i. מכשירי אור חכמים המבוססים על ESP32-C3, אחראים על אינטראקציה עם פלטפורמות ענן IoT, ושליטה במתג, בהירות וטמפרטורת הצבע של LED lamp חרוזים. ii. אפליקציות לסמארטפון (כולל אפליקציות טאבלט הפועלות על אנדרואיד ו-iOS), אחראיות על תצורת הרשת של מוצרי תאורה חכמה, כמו גם שאילתה ושליטה בסטטוס שלהם.
iii. פלטפורמת ענן IoT המבוססת על ESP RainMaker. לשם הפשטות, אנו רואים בספר זה את פלטפורמת הענן והשרת העסקי של IoT כמכלול. פרטים על ESP RainMaker יסופקו בפרק 3.
ההתאמה בין מבנה פרויקט Smart Light לבין הארכיטקטורה של IoT מוצגת באיור 2.1.
איור 2.1. מבנה של פרויקט אור חכם
2.2.2 פונקציות הפרויקט
מחולקים לפי המבנה, הפונקציות של כל חלק הן כדלקמן. מכשירי אור חכמים
· תצורת רשת וחיבור. · בקרת LED PWM, כגון מתג, בהירות, טמפרטורת צבע וכו'. · אוטומציה או בקרת סצנה, למשל, מתג זמן. · הצפנה ואתחול מאובטח של הפלאש. · שדרוג קושחה וניהול גרסאות.
פרק 2. מבוא ותרגול של פרויקטי IoT 13
אפליקציות לסמארטפון · תצורת רשת וקשירת מכשירים. · בקרת מוצר אור חכמה, כגון מתג, בהירות, טמפרטורת צבע וכו'. · הגדרות אוטומציה או סצנה, למשל, מתג זמן. · שלט מקומי/מרחוק. · רישום משתמש, התחברות וכו'.
ESP RainMaker IoT פלטפורמת ענן · מתן גישה למכשירי IoT. · אספקת ממשקי API לתפעול המכשיר הנגישים לאפליקציות לסמארטפון. · שדרוג קושחה וניהול גרסאות.
2.2.3 הכנת חומרה
אם מעוניינים להוציא את הפרויקט לפועל, תזדקקו גם לחומרה הבאה: נורות חכמות, סמארטפונים, נתבי Wi-Fi ומחשב העומד בדרישות ההתקנה של סביבת הפיתוח. אורות חכמות
נורות חכמות הן סוג חדש של נורות, שצורתן זהה לנורת הליבון הכללית. אור חכם מורכב מאספקת כוח מווסתת קבלים, מודול אלחוטי (עם ESP32-C3 מובנה), בקר LED ומטריצת LED RGB. כאשר מחובר לחשמל, 15 V DC voltagהפלט לאחר הורדת הקבלים, תיקון דיודות וויסות מספק אנרגיה לבקר ה-LED ולמטריקס ה-LED. בקר ה-LED יכול לשלוח רמות גבוהות ונמוכות באופן אוטומטי במרווחים מסוימים, ולהעביר את מטריצת LED RGB בין סגורה (אורות דולקים) ופתוחה (אורות כבויים), כך שהיא יכולה לפלוט ציאן, צהוב, ירוק, סגול, כחול, אדום, ו אור לבן. המודול האלחוטי אחראי לחיבור לנתב ה-Wi-Fi, קליטה ודיווח על מצב הנורות החכמות ושליחת פקודות לשליטה ב-LED.
איור 2.2. אור חכם מדומה
בפיתוח מוקדם סtagה, אתה יכול לדמות אור חכם באמצעות לוח ESP32-C3DevKitM-1 המחובר עם RGB LED lamp חרוזים (ראה איור 2.2). אבל אתה צריך
14 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
שימו לב שזו לא הדרך היחידה להרכיב אור חכם. עיצוב החומרה של הפרויקט בספר זה מכיל רק מודול אלחוטי (עם ESP32-C3 מובנה), אך לא עיצוב חומרה חכם של אור חכם. בנוסף, Espressif מייצרת גם לוח פיתוח אודיו מבוסס ESP32-C3 ESP32C3-Lyra לשליטה באור עם אודיו. ללוח יש ממשקים למיקרופונים ורמקולים ויכול לשלוט בפסי LED. זה יכול לשמש לפיתוח שידורי אודיו בעלות נמוכה במיוחד ובעלי ביצועים גבוהים ורצועות אור קצב. איור 2.3 מציג לוח ESP32-C3Lyra המקושר לרצועה של 40 נורות LED.
איור 2.3. ESP32-C3-Lyra מקושר עם רצועה של 40 נורות LED
סמארטפונים (אנדרואיד/iOS) פרויקט Smart Light כולל פיתוח אפליקציה לסמארטפון להגדרה ושליטה במוצרי אור חכם.
נתבי Wi-Fi נתבי Wi-Fi ממירים אותות רשת קווית ואותות רשת סלולרית לאותות רשת אלחוטית, עבור מחשבים, סמארטפונים, טאבלטים והתקנים אלחוטיים אחרים להתחבר לרשת. למשלampלמען האמת, פס רחב בבית צריך להיות מחובר רק לנתב Wi-Fi כדי להשיג רשת אלחוטית של התקני Wi-Fi. תקן הפרוטוקול המיינסטרים הנתמך על ידי נתבי Wi-Fi הוא IEEE 802.11n, עם קצב TxRate ממוצע של 300 Mbps, או 600 Mbps לכל היותר. הם תואמים לאחור עם IEEE 802.11b ו-IEEE 802.11g. שבב ESP32-C3 של Espressif תומך ב-IEEE 802.11b/g/n, כך שתוכל לבחור נתב Wi-Fi בפס יחיד (2.4 GHz) או דו-פס (2.4 GHz ו-5 GHz).
סביבת פיתוח מחשב (Linux/macOS/Windows) תוצג בפרק 4. פרק 2. מבוא ותרגול של פרויקטי IoT 15
2.2.4 תהליך פיתוח
איור 2.4. שלבי פיתוח פרויקט Smart Light
עיצוב חומרה עיצוב חומרה של התקני IoT חיוני לפרויקט IoT. פרויקט אור חכם שלם נועד לייצר אלamp עובד תחת אספקת חשמל. יצרנים שונים מייצרים lampסגנונות וסוגי מנהלי התקנים שונים, אך המודולים האלחוטיים שלהם הם בדרך כלל באותה פונקציה. כדי לפשט את תהליך הפיתוח של פרויקט Smart Ligh, ספר זה מכסה רק את עיצוב החומרה ופיתוח התוכנה של מודולים אלחוטיים.
תצורת פלטפורמת ענן IoT כדי להשתמש בפלטפורמות ענן של IoT, עליך להגדיר פרויקטים בקצה העורפי, כגון יצירת מוצרים, יצירת מכשירים, הגדרת מאפייני מכשיר וכו'.
פיתוח תוכנה משובצת עבור מכשירי IoT הטמעת פונקציות צפויות עם ESP-IDF, SDK בצד המכשיר של Espressif, כולל חיבור לפלטפורמות ענן IoT, פיתוח מנהלי התקן LED ושדרוג קושחה.
פיתוח אפליקציות לסמארטפון פתח אפליקציות לסמארטפון למערכות אנדרואיד ו-iOS למימוש רישום וכניסה של משתמשים, בקרת מכשיר ופונקציות אחרות.
אופטימיזציה של מכשירי IoT לאחר השלמת הפיתוח הבסיסי של פונקציות מכשירי IoT, תוכל לפנות למשימות אופטימיזציה, כגון אופטימיזציה של צריכת חשמל.
בדיקות ייצור המוני בצע בדיקות ייצור המוני לפי תקנים קשורים, כגון בדיקת תפקוד ציוד, בדיקת הזדקנות, בדיקת RF וכו'.
למרות השלבים המפורטים לעיל, פרויקט Smart Light אינו כפוף בהכרח לנוהל כזה שכן ניתן לבצע גם משימות שונות בו זמנית. למשלample, תוכנות משובצות ואפליקציות לסמארטפון ניתן לפתח במקביל. ייתכן שיהיה צורך לחזור על כמה שלבים, כגון אופטימיזציה של מכשירי IoT ובדיקות ייצור המוני.
16 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
2.3 סיכום
בפרק זה, הסברנו תחילה את הרכיבים הבסיסיים והמודולים הפונקציונליים של פרויקט IoT, ולאחר מכן הצגנו את מקרה Smart Light לתרגול, תוך התייחסות למבנה, פונקציות, הכנת החומרה ותהליך הפיתוח שלו. הקוראים יכולים להסיק מסקנות מהתרגול ולהיות בטוחים לבצע פרויקטי IoT עם מינימום טעויות בעתיד.
פרק 2. מבוא ותרגול של פרויקטי IoT 17
18 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
פרק 3
מָבוֹא
אֶל
ESP
מַגשִׁים
האינטרנט של הדברים (IoT) מציע אינסוף אפשרויות לשנות את הדרך שבה אנשים חיים, ובכל זאת הפיתוח של הנדסת IoT מלא באתגרים. עם עננים ציבוריים, יצרני מסופים יכולים ליישם פונקציונליות של מוצר באמצעות הפתרונות הבאים:
בהתבסס על פלטפורמות הענן של ספקי הפתרונות בדרך זו, יצרני מסופים צריכים רק לתכנן את חומרת המוצר, לאחר מכן לחבר את החומרה לענן באמצעות מודול התקשורת שסופק, ולהגדיר את פונקציות המוצר בהתאם להנחיות. זוהי גישה יעילה מכיוון שהיא מבטלת את הצורך בפיתוח ותפעול ותחזוקה בצד השרת ובצד היישום (O&M). זה מאפשר ליצרני מסופים להתמקד בעיצוב חומרה מבלי לשקול הטמעת ענן. עם זאת, פתרונות כאלה (למשל, קושחה ואפליקציה) אינם קוד פתוח בדרך כלל, ולכן פונקציות המוצר יוגבלו על ידי פלטפורמת הענן של הספק אשר לא ניתנת להתאמה אישית. בינתיים, נתוני המשתמש והמכשיר שייכים גם לפלטפורמת הענן.
בהתבסס על מוצרי ענן בפתרון זה, לאחר השלמת תכנון החומרה, יצרני מסופים צריכים לא רק ליישם פונקציות ענן באמצעות מוצר ענן אחד או יותר שמסופק על ידי הענן הציבורי, אלא גם לקשר את החומרה עם הענן. למשלample, כדי להתחבר לאמזון Web שירותים (AWS), יצרני מסופים צריכים להשתמש במוצרי AWS כגון Amazon API Gateway, AWS IoT Core ו-AWS Lambda כדי לאפשר גישה למכשיר, שליטה מרחוק, אחסון נתונים, ניהול משתמשים ופונקציות בסיסיות אחרות. זה לא רק מבקש מיצרני מסופים להשתמש ולהגדיר במוצרי ענן בצורה גמישה עם הבנה מעמיקה וניסיון עשיר, אלא גם דורש מהם לשקול את עלות הבנייה והתחזוקה עבור פעולות ראשוניות ומאוחר יותר.tagזה מציב אתגרים גדולים לאנרגיה ולמשאבים של החברה.
בהשוואה לעננים ציבוריים, עננים פרטיים נבנים בדרך כלל עבור פרויקטים ומוצרים ספציפיים. מפתחי ענן פרטיים מקבלים את רמת החופש הגבוהה ביותר בעיצוב פרוטוקולים והטמעת לוגיקה עסקית. יצרני טרמינלים יכולים לייצר מוצרים ותכניות עיצוב כרצונם, ולשלב בקלות ולהעצים נתוני משתמשים. שילוב האבטחה הגבוהה, המדרגיות והאמינות של הענן הציבורי עם ה-advantagמהענן הפרטי, Espressif השיקה את ESP
19
RainMaker, פתרון ענן פרטי משולב עמוק המבוסס על ענן אמזון. משתמשים יכולים לפרוס את ESP RainMaker ולבנות ענן פרטי פשוט עם חשבון AWS.
3.1 מהו ESP RainMaker?
ESP RainMaker היא פלטפורמת AIoT שלמה הבנויה עם מספר מוצרי AWS בוגרים. הוא מספק שירותים שונים הנדרשים לייצור המוני כגון גישה למכשירים בענן, שדרוג מכשירים, ניהול אחורי, התחברות של צד שלישי, אינטגרציה קולית וניהול משתמשים. על ידי שימוש במאגר היישומים ללא שרתים (SAR) המסופק על ידי AWS, יצרני מסופים יכולים לפרוס במהירות את ESP RainMaker לחשבונות ה-AWS שלהם, שהוא יעיל בזמן וקל לתפעול. מנוהל ומתוחזק על ידי Espressif, ה-SAR המשמש את ESP RainMaker עוזר למפתחים להפחית את עלויות תחזוקה בענן ולהאיץ את הפיתוח של מוצרי AIoT, ובכך לבנות פתרונות AIoT מאובטחים, יציבים וניתנים להתאמה אישית. איור 3.1 מציג את הארכיטקטורה של ESP RainMaker.
איור 3.1. ארכיטקטורה של ESP RainMaker
השרת הציבורי ESP RainMaker מאת Espressif הוא בחינם לכל חובבי ESP, יצרנים ומחנכים להערכת פתרונות. מפתחים יכולים להיכנס עם חשבונות אפל, גוגל או GitHub, ולבנות במהירות אבות טיפוס משלהם של יישומי IoT. השרת הציבורי משלב את Alexa ו-Google Home, ומספק שירותי שליטה קולית, הנתמכים על ידי Alexa Skill ו-Google Actions. פונקציית הזיהוי הסמנטי שלו מופעלת גם על ידי צדדים שלישיים. מכשירי IoT של RainMaker מגיבים רק לפעולות ספציפיות. לרשימה ממצה של פקודות קוליות נתמכות, בדוק את הפלטפורמות של צד שלישי. בנוסף, Espressif מציעה אפליקציית RainMaker ציבורית למשתמשים לשלוט במוצרים באמצעות סמארטפונים. 20 הרפתקאות אלחוטיות ESP32-C3: מדריך מקיף ל-IoT
3.2 היישום של ESP RainMaker
כפי שמוצג באיור 3.2, ESP RainMaker מורכב מארבעה חלקים: · שירות תביעה, המאפשר למכשירי RainMaker לקבל באופן דינמי אישורים. · RainMaker Cloud (מכונה גם ענן backend), מספקת שירותים כגון סינון הודעות, ניהול משתמשים, אחסון נתונים ואינטגרציות של צד שלישי. · RainMaker Agent, המאפשר למכשירי RainMaker להתחבר ל-RainMaker Cloud. · RainMaker Client (סקריפטים של RainMaker App או CLI), להקצאה, יצירת משתמשים, שיוך ובקרת מכשירים וכו'.
איור 3.2. מבנה של ESP RainMaker
ESP RainMaker מספקת סט שלם של כלים לפיתוח מוצר וייצור המוני, כולל: RainMaker SDK
RainMaker SDK מבוסס על ESP-IDF ומספק את קוד המקור של הסוכן בצד המכשיר וממשקי API קשורים של C לפיתוח קושחה. מפתחים צריכים רק לכתוב את היגיון האפליקציה ולהשאיר את השאר למסגרת RainMaker. למידע נוסף על ממשקי API של C, בקר בכתובת https://bookc3.espressif.com/rm/c-api-reference. RainMaker App הגרסה הציבורית של RainMaker App מאפשרת למפתחים להשלים אספקת מכשירים, ולשלוט ולשאול את מצב המכשירים (למשל, מוצרי תאורה חכמה). זה זמין גם בחנויות האפליקציות של iOS וגם לאנדרואיד. לפרטים נוספים, עיין בפרק 10. REST APIs REST APIs עוזרים למשתמשים לבנות יישומים משלהם בדומה לאפליקציית RainMaker. למידע נוסף, בקר בכתובת https://swaggerapis.rainmaker.espressif.com/.
פרק 3. מבוא ל-ESP RainMaker 21
Python APIs CLI מבוסס Python, שמגיע עם ה-RainMaker SDK, מסופק כדי ליישם את כל הפונקציות הדומות לתכונות הסמארטפון. למידע נוסף על ממשקי API של Python, בקר בכתובת https://bookc3.espressif.com/rm/python-api-reference.
Admin CLI Admin CLI, עם רמת גישה גבוהה יותר, מסופק לפריסה פרטית של ESP RainMaker להפקת אישורי מכשיר בכמות גדולה.
3.2.1 שירות תביעות
כל התקשורת בין מכשירי RainMaker לבין ה-backend של הענן מתבצעת באמצעות MQTT+TLS. בהקשר של ESP RainMaker, "תביעה" הוא התהליך שבו מכשירים מקבלים אישורים משירות התביעה לחיבור ל-backend של הענן. שים לב ששירות התביעה חל רק על שירות RainMaker הציבורי, בעוד שלפריסה פרטית, יש להפיק את אישורי המכשיר בכמות גדולה דרך Admin CLI. ESP RainMaker תומך בשלושה סוגים של שירות תביעה: תביעה עצמית
המכשיר עצמו מביא את האישורים דרך מפתח סודי שתוכנת מראש ב-eFuse לאחר התחברות לאינטרנט. תביעה מונעת מארח האישורים מתקבלים ממארח הפיתוח עם חשבון RainMaker. תביעה בסיוע האישורים מתקבלים באמצעות יישומי סמארטפון במהלך ההקצאה.
3.2.2 סוכן RainMaker
איור 3.3. המבנה של RainMaker SDK התפקיד העיקרי של RainMaker Agent הוא לספק קישוריות ולסייע לשכבת האפליקציה לעבד נתוני ענן מעלה/למטה. הוא נבנה באמצעות ה-RainMaker SDK 22 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT
ופותח על בסיס המסגרת המוכחת של ESP-IDF, תוך שימוש ברכיבי ESP-IDF כגון RTOS, NVS ו-MQTT. איור 3.3 מציג את המבנה של RainMaker SDK.
ה-RainMaker SDK כולל שתי תכונות עיקריות.
קֶשֶׁר
אני. שיתוף פעולה עם שירות התביעה להשגת אישורי מכשיר.
ii. התחברות לענן העורפי באמצעות פרוטוקול MQTT המאובטח כדי לספק קישוריות מרחוק ולהטמיע שליטה מרחוק, דיווח הודעות, ניהול משתמשים, ניהול מכשירים וכו'. הוא משתמש ברכיב MQTT ב-ESP-IDF כברירת מחדל ומספק שכבת הפשטה להתממשקות עם אחרים ערימות פרוטוקול.
iii. אספקת רכיב אספקת wifi עבור חיבור והקצאת Wi-Fi, רכיב https ota במיוחד עבור שדרוגי OTA, ורכיב ctrl מקומי במיוחד עבור גילוי וחיבור מכשירים מקומיים. ניתן להשיג את כל המטרות הללו באמצעות תצורה פשוטה.
עיבוד נתונים
אני. אחסון אישורי המכשיר שהונפקו על ידי Claiming Service והנתונים הדרושים בעת הפעלת RainMaker, כברירת מחדל באמצעות הממשק המסופק על ידי רכיב ה-nvs flash, ומתן ממשקי API למפתחים לשימוש ישיר.
ii. שימוש במנגנון ה-callback לעיבוד נתוני ענן uplink/downlink וביטול אוטומטי של חסימת הנתונים לשכבת האפליקציה לעיבוד קל על ידי מפתחים. למשלampלמעשה, ה-RainMaker SDK מספק ממשקים עשירים ליצירת נתוני TSL (שפת מפרט דבר), אשר נדרשים להגדרת מודלים של TSL לתיאור התקני IoT ויישום פונקציות כגון תזמון, ספירה לאחור ושליטה קולית. עבור תכונות אינטראקטיביות בסיסיות כגון תזמון, RainMaker SDK מספקת פתרון נטול פיתוח שניתן פשוט להפעיל אותו בעת הצורך. לאחר מכן, ה-RainMaker Agent יעבד ישירות את הנתונים, ישלח אותם לענן דרך נושא ה-MQTT המשויך, ויחזיר את השינויים בנתונים ב-backend של הענן באמצעות מנגנון התקשרות חוזרת.
3.2.3 ענן אחורי
ה-backend של הענן בנוי על AWS Serverless Computing והושג באמצעות AWS Cognito (מערכת ניהול זהויות), Amazon API Gateway, AWS Lambda (שירות מחשוב ללא שרת), Amazon DynamoDB (בסיס נתונים NoSQL), AWS IoT Core (ליבת גישה ל-IoT המספקת גישה ל-MQTT וסינון כללים), Amazon Simple Email Service (שירות דואר פשוט של SES), Amazon CloudFront (רשת מסירה מהירה), Amazon Simple Queue Service (תור הודעות SQS), ו-Amazon S3 (שירות אחסון דלי). מטרתו היא לייעל יכולת מדרגיות ואבטחה. עם ESP RainMaker, מפתחים יכולים לנהל מכשירים מבלי לכתוב קוד בענן. הודעות שמדווחות על ידי מכשירים מועברות בשקיפות אל
פרק 3. מבוא ל-ESP RainMaker 23
לקוחות יישומים או שירותי צד שלישי אחרים. טבלה 3.1 מציגה את מוצרי הענן והפונקציות של AWS בשימוש ב-backend של הענן, עם עוד מוצרים ותכונות בפיתוח.
טבלה 3.1. מוצרים ופונקציות בענן של AWS המשמשות את ה-backend של הענן
מוצר ענן AWS בשימוש על ידי RainMaker
פוּנקצִיָה
AWS Cognito
ניהול אישורי משתמש ותמיכה בכניסות של צד שלישי
AWS למבדה
יישום ההיגיון העסקי הליבה של ה-backend של הענן
Amazon Timestream אחסון נתוני סדרות זמן
Amazon DynamoDB אחסון מידע פרטי של לקוחות
AWS IoT Core
תומך בתקשורת MQTT
אמזון SES
מתן שירותי שליחת דואר אלקטרוני
Amazon CloudFront האצת ניהול ה-backend webגישה לאתר
אמזון SQS
העברת הודעות מ-AWS IoT Core
3.2.4 RainMaker Client
לקוחות RainMaker, כגון App ו-CLI, מתקשרים עם ה-backend של הענן באמצעות ממשקי API של REST. מידע מפורט והוראות לגבי ממשקי API של REST ניתן למצוא בתיעוד של Swagger שסופק על ידי Espressif. לקוח האפליקציה לנייד של RainMaker זמין עבור מערכות iOS ו- Android כאחד. הוא מאפשר הקצאת מכשירים, שליטה ושיתוף, כמו גם יצירה ואפשרות של משימות ספירה לאחור וחיבור לפלטפורמות של צד שלישי. זה יכול לטעון אוטומטית ממשק משתמש ואייקונים בהתאם לתצורה שדווחה על ידי המכשירים ולהציג באופן מלא את ה-TSL של המכשיר.
למשלample, אם אור חכם נבנה על ה-RainMaker SDK המסופק examples, הסמל והממשק של נורית הנורה ייטענו אוטומטית עם השלמת ההקצאה. משתמשים יכולים לשנות את הצבע והבהירות של האור דרך הממשק ולהשיג שליטה של צד שלישי על ידי קישור Alexa Smart Home Skill או Google Smart Home Actions לחשבונות ה-ESP RainMaker שלהם. איור 3.4 מציג את הסמל ואת ממשק המשתמש למשלampחלקים של אור הנורה בהתאמה ב-Alexa, Google Home ו-ESP RainMaker App.
24 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
(א) דוגמהample – אלכסה
(ב) דוגמהample – Google Home
(ג) דוגמהample – ESP RainMaker
איור 3.4. דוגמאampסמלים וממשק משתמש של נורת הנורה ב-Alexa, Google Home ו-ESP RainMaker App
3.3 תרגול: נקודות מפתח לפיתוח עם ESP RainMaker
לאחר השלמת שכבת מנהל ההתקן, מפתחים עשויים להתחיל ליצור מודלים של TSL ולעבד נתוני קישור מטה באמצעות ממשקי ה-API המסופקים על ידי RainMaker SDK, ולאפשר את השירותים הבסיסיים של ESP RainMaker בהתבסס על הגדרת המוצר והדרישות.
פרק 3. מבוא ל-ESP RainMaker 25
סעיף 9.4 בספר זה יסביר את היישום של אור LED חכם ב-RainMaker. במהלך איתור באגים, מפתחים יכולים להשתמש בכלי CLI ב-RainMaker SDK כדי לתקשר עם האור החכם (או לקרוא ל-REST APIs מ-Swagger).
פרק 10 ירחיב את השימוש בממשקי API של REST בפיתוח יישומי סמארטפון. שדרוגי OTA של נורות LED חכמות יכוסו בפרק 11. אם מפתחים אפשרו את הניטור מרחוק של ESP Insights, הקצה האחורי של ניהול ESP RainMaker יציג את נתוני ה-ESP Insights. פרטים יוצגו בפרק 15.
ESP RainMaker תומך בפריסה פרטית, השונה משרת RainMaker הציבורי בדרכים הבאות:
שירות תביעה כדי להפיק אישורים בפריסות פרטיות, יש צורך להשתמש ב-RainMaker Admin CLI במקום בטענה. עם שרת ציבורי, יש לתת למפתחים זכויות אדמין ליישום שדרוג קושחה, אך זה לא רצוי בפריסות מסחריות. לכן, לא ניתן לספק שירות אימות נפרד לתביעה עצמית, וגם לא ניתן לספק זכויות מנהל עבור תביעה מונעת מארח או בסיוע.
אפליקציות טלפון בפריסות פרטיות, יש להגדיר ולהרכיב יישומים בנפרד כדי להבטיח שמערכות החשבונות אינן פועלות הדדית.
כניסות ושילוב קולי של צד שלישי מפתחים צריכים להגדיר בנפרד דרך חשבונות Google ו-Apple Developer כדי לאפשר התחברות של צד שלישי, כמו גם את השילוב של Alexa Skill ו-Google Voice Assistant.
טיפים לפרטים על פריסת ענן, בקר בכתובת https://customer.rainmaker.espressif. com. מבחינת קושחה, העברה משרת ציבורי לשרת פרטי דורשת רק החלפת אישורי מכשיר, מה שמשפר מאוד את יעילות ההגירה ומפחית את עלות ההעברה ואיתור באגים משני.
3.4 תכונות של ESP RainMaker
תכונות ESP RainMaker ממוקדות בעיקר לשלושה היבטים - ניהול משתמשים, משתמשי קצה ומנהלים. כל התכונות נתמכות בשרתים ציבוריים ופרטיים כאחד, אלא אם צוין אחרת.
3.4.1 ניהול משתמשים
תכונות ניהול המשתמשים מאפשרות למשתמשי קצה להירשם, להיכנס, לשנות סיסמאות, לאחזר סיסמאות וכו'.
26 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
הרשמה והתחברות שיטות הרישום והכניסה הנתמכות על ידי RainMaker כוללות: · מזהה דוא"ל + סיסמה · מספר טלפון + סיסמה · חשבון גוגל · חשבון אפל · חשבון GitHub (שרת ציבורי בלבד) · חשבון אמזון (שרת פרטי בלבד)
הערה הרשמה באמצעות Google/Amazon משתפת את כתובת האימייל של המשתמש עם RainMaker. הרשמה באמצעות אפל חולקת כתובת דמה שאפל מקצה למשתמש במיוחד עבור שירות RainMaker. חשבון RainMaker ייווצר אוטומטית עבור משתמשים שייכנסו עם חשבון גוגל, אפל או אמזון בפעם הראשונה.
שנה סיסמה תקף רק עבור כניסות מבוססות מזהה דוא"ל/מספר טלפון. כל שאר ההפעלות הפעילות ינותקו לאחר שינוי הסיסמה. בהתאם להתנהגות AWS Cognito, הפעלות המנותקות יכולות להישאר פעילות עד שעה אחת.
אחזר סיסמה תקפה רק עבור כניסות מבוססות מזהה דוא"ל/מספר טלפון.
3.4.2 תכונות משתמש קצה
תכונות הפתוחות למשתמשי קצה כוללות שליטה וניטור מקומיים ומרוחקים, תזמון, קיבוץ מכשירים, שיתוף מכשירים, הודעות דחיפה ושילובים של צד שלישי.
שליטה וניטור מרחוק · תצורת שאילתה, ערכי פרמטרים ומצב חיבור עבור אחד או כל המכשירים. · הגדר פרמטרים עבור מכשירים בודדים או מרובים.
שליטה וניטור מקומיים הטלפון הנייד והמכשיר צריכים להיות מחוברים לאותה רשת לצורך שליטה מקומית.
תזמון · משתמשים מגדירים מראש פעולות מסוימות בזמן מסוים. · אין צורך בחיבור אינטרנט למכשיר בזמן ביצוע לוח הזמנים. · פעם אחת או חזרה (על ידי ציון ימים) עבור מכשירים בודדים או מרובים.
קיבוץ התקנים תומך בקיבוץ רב-רמות מופשט ניתן להשתמש במטא נתונים של קבוצות כדי ליצור מבנה של חדר בית.
פרק 3. מבוא ל-ESP RainMaker 27
שיתוף מכשירים ניתן לשתף מכשיר אחד או יותר עם משתמש אחד או יותר.
הודעות דחיפה משתמשי קצה יקבלו הודעות דחיפה עבור אירועים כגון · מכשיר(ים) חדשים נוספו/הוסרו · מכשיר מחובר לענן · מכשיר מנותק מהענן · בקשות שיתוף מכשיר שנוצרו/אושרו/נדחו · הודעות התראה שדווחו על ידי מכשירים
שילובים של צד שלישי Alexa ו-Google Voice Assistant נתמכים לשליטה במכשירי RainMaker, כולל אורות, מתגים, שקעים, מאווררים וחיישני טמפרטורה.
3.4.3 תכונות ניהול
תכונות הניהול מאפשרות למנהלי מערכת ליישם רישום מכשירים, קיבוץ מכשירים ושדרוגי OTA, וכן view נתונים סטטיסטיים ונתוני ESP Insights.
רישום מכשיר הפק אישורי מכשיר והירשם ב-Admin CLI (שרת פרטי בלבד).
קיבוץ מכשירים צור קבוצות מופשטות או מובנות על סמך מידע על המכשיר (שרת פרטי בלבד).
שדרוגים דרך האוויר (OTA) העלה קושחה על סמך גרסה ודגם, למכשיר אחד או יותר או לקבוצה מעקב, בטל או אחסן משרות OTA.
View סטָטִיסטִיקָה Viewנתונים סטטיסטיים אפשריים כוללים: · רישומי מכשירים (אישורים שנרשמו על ידי המנהל) · הפעלת מכשירים (המכשיר מחובר בפעם הראשונה) · חשבונות משתמש · שיוך משתמש-מכשיר
View נתוני ESP Insights Viewנתוני ESP Insights מסוגלים כוללים: · שגיאות, אזהרות ויומנים מותאמים אישית · דוחות קריסה וניתוח · סיבות אתחול מחדש · מדדים כמו שימוש בזיכרון, RSSI וכו'. · מדדים ומשתנים מותאמים אישית
28 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
3.5 סיכום
בפרק זה, הצגנו כמה הבדלים מרכזיים בין פריסת RainMaker הציבורית לפריסה הפרטית. פתרון ESP RainMaker הפרטי שהשיקה Espressif הוא אמין ביותר וניתן להרחבה. כל השבבים מסדרת ESP32 חוברו והותאמו ל-AWS, מה שמוזיל מאוד את העלות. מפתחים יכולים להתמקד באימות אב טיפוס מבלי ללמוד על מוצרי הענן של AWS. הסברנו גם את היישום והתכונות של ESP RainMaker, וכמה נקודות מפתח לפיתוח באמצעות הפלטפורמה.
סרוק כדי להוריד את ESP RainMaker עבור אנדרואיד סרוק כדי להוריד את ESP RainMaker עבור iOS
פרק 3. מבוא ל-ESP RainMaker 29
30 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
פרק הקמה 4 סביבת פיתוח
פרק זה מתמקד ב-ESP-IDF, מסגרת פיתוח התוכנה הרשמית עבור ESP32-C3. נסביר כיצד להגדיר את הסביבה על מערכות הפעלה שונות, ונציג את מבנה הפרויקט ומערכת הבנייה של ESP-IDF, כמו גם את השימוש בכלי פיתוח נלווים. לאחר מכן נציג את תהליך ההידור והריצה של אקסample project, תוך מתן הסבר מפורט על יומן הפלט בכל stage.
4.1 ESP-IDF נגמרview
ESP-IDF (Espressif IoT Development Framework) היא מסגרת פיתוח IoT חד-פעמית המסופקת על ידי Espressif Technology. הוא משתמש ב-C/C++ כשפת הפיתוח העיקרית ותומך בהידור צולב במערכות הפעלה מיינסטרים כגון לינוקס, מק ו-Windows. האקסampתוכניות הכלולות בספר זה מפותחות באמצעות ESP-IDF, המציע את התכונות הבאות: · מנהלי התקנים ברמת מערכת SoC. ESP-IDF כולל מנהלי התקנים עבור ESP32, ESP32-S2, ESP32-C3,
ועוד צ'יפס. מנהלי התקנים אלה כוללים ספרייה היקפית ברמה נמוכה (LL), ספריית שכבת הפשטת חומרה (HAL), תמיכה ב-RTOS ותוכנת מנהלי התקן בשכבה עליונה וכו'. · רכיבים חיוניים. ESP-IDF משלבת רכיבים בסיסיים הנדרשים לפיתוח IoT. זה כולל ערימות מרובות של פרוטוקולי רשת כגון HTTP ו-MQTT, מסגרת לניהול צריכת חשמל עם אפנון תדר דינמי, ותכונות כמו Flash Encryption ואתחול מאובטח וכו'. · כלי פיתוח וייצור. ESP-IDF מספקת כלים נפוצים לבנייה, הבזק וניפוי באגים במהלך פיתוח וייצור המוני (ראה איור 4.1), כגון מערכת הבנייה המבוססת על CMake, שרשרת הכלים ההקומפילציה המבוססת על GCC וה-JTAG כלי איתור באגים המבוסס על OpenOCD וכו'. ראוי לציין שקוד ה-ESP-IDF תואם בעיקר לרישיון הקוד הפתוח של Apache 2.0. משתמשים יכולים לפתח תוכנה אישית או מסחרית ללא הגבלות תוך עמידה בתנאי רישיון הקוד הפתוח. בנוסף, למשתמשים מוענקים רישיונות פטנט קבועים ללא תשלום, ללא חובה לבצע קוד פתוח כל שינוי שנעשה בקוד המקור.
31
איור 4.1.
בנייה, מהבהב וניפוי באגים-
גינג כלים לפיתוח וייצור המוני
4.1.1 גרסאות ESP-IDF
קוד ESP-IDF מתארח ב- GitHub כפרויקט קוד פתוח. נכון לעכשיו, קיימות שלוש גרסאות עיקריות זמינות: v3, v4 ו-v5. כל גרסה עיקרית מכילה בדרך כלל חתרניות שונות, כגון v4.2, v4.3 וכן הלאה. Espressif Systems מבטיחה תמיכה של 30 חודשים בתיקוני באגים ותיקוני אבטחה עבור כל תת-גרסת המשוחררת. לכן, גרסאות חתרניות משוחררות גם הן באופן קבוע, כגון v4.3.1, v4.2.2 וכו'. טבלה 4.1 מציגה את מצב התמיכה של גרסאות ESP-IDF שונות עבור שבבי Espressif, ומציינת אם הם נמצאים בגרסה מוקדמתview stagה (המציע תמיכה עבור preview גרסאות, שעשויות להיעדר תכונות או תיעוד מסוימים) או שהן נתמכות רשמית.
טבלה 4.1. סטטוס תמיכה של גרסאות ESP-IDF שונות עבור שבבי Espressif
סדרה ESP32 ESP32-S2 ESP32-C3 ESP32-S3 ESP32-C2 ESP32-H2
גרסה 4.1 נתמכת
גרסה 4.2 נתמכת
גרסה 4.3 נתמכת נתמכת נתמכת
גרסה 4.4 נתמכת נתמכת נתמכת נתמכת
מִרֹאשׁview
v5.0 נתמך נתמך נתמך נתמך נתמך מראשview
32 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
האיטרציה של גרסאות מרכזיות כרוכה לרוב בהתאמות למבנה המסגרת ועדכונים למערכת ההידור. למשלample, השינוי העיקרי מ-v3.* ל-v4.* היה ההעברה ההדרגתית של מערכת ה-build מ-Make ל-CMake. מצד שני, איטרציה של גרסאות מינוריות כרוכה בדרך כלל בהוספת תכונות חדשות או תמיכה בשבבים חדשים.
חשוב להבחין ולהבין את הקשר בין גרסאות יציבות וסניפי GitHub. גרסאות המסומנות כ-v*.* או v*.*.* מייצגות גרסאות יציבות שעברו בדיקות פנימיות מלאות על ידי Espressif. לאחר תיקון, הקוד, שרשרת הכלים ומסמכי השחרור עבור אותה גרסה נשארים ללא שינוי. עם זאת, סניפי GitHub (למשל, סניף release/v4.3) עוברים התחייבויות קוד תכופות, לעתים קרובות על בסיס יומי. לכן, שני קטעי קוד תחת אותו ענף עשויים להיות שונים, מה שמחייב מפתחים לעדכן את הקוד שלהם בהתאם.
4.1.2 זרימת עבודה של ESP-IDF Git
Espressif עוקבת אחר זרימת עבודה ספציפית של Git עבור ESP-IDF, המתוארת כדלקמן:
· מתבצעים שינויים חדשים בסניף המאסטר המשמש כסניף הפיתוח הראשי. גרסת ה-ESP-IDF בסניף הראשי תמיד נושאת -dev tag כדי לציין שהוא נמצא כעת בפיתוח, כגון v4.3-dev. שינויים בסניף הראשי יתבצעו תחילה מחדשviewעורך ונבדק במאגר הפנימי של Espressif, ולאחר מכן נדחף ל-GitHub לאחר השלמת הבדיקות האוטומטיות.
· לאחר שגרסה חדשה השלימה פיתוח תכונה בענף המאסטר ועמדה בקריטריונים לכניסה לבדיקות בטא, היא עוברת לענף חדש, כגון release/v4.3. בנוסף, הסניף החדש הזה הוא tagged כגרסה מוקדמת, כמו v4.3-beta1. מפתחים יכולים לפנות לפלטפורמת GitHub כדי לגשת לרשימה המלאה של סניפים ו tags עבור ESP-IDF. חשוב לציין שגרסת הבטא (גרסת הגרסה המוקדמת) עדיין עשויה להכיל מספר לא מבוטל של בעיות ידועות. מכיוון שגרסת הבטא עוברת בדיקות מתמשכות, תיקוני באגים מתווספים הן לגרסה זו והן לסניף המאסטר בו זמנית. בינתיים, ייתכן שענף המאסטר כבר החל בפיתוח תכונות חדשות עבור הגרסה הבאה. כאשר הבדיקה כמעט הושלמה, מתווספת לסניף תווית מועמד לשחרור (rc), המציינת שהוא מועמד פוטנציאלי לגרסה הרשמית, כגון v4.3-rc1. בס' זהtagה, הסניף נשאר גרסת טרום-הפצה.
· אם לא מתגלים או מדווחים באגים גדולים, גרסת טרום ההפצה מקבלת בסופו של דבר תווית גרסה ראשית (למשל, v5.0) או תווית גרסה משנית (למשל, v4.3) והופכת לגרסת מהדורה רשמית, המתועדת בדף הערות השחרור. לאחר מכן, כל הבאגים המזוהים בגרסה זו יתוקנו בענף השחרור. לאחר השלמת הבדיקה הידנית, מוקצית לסניף תווית גרסת תיקון באגים (למשל, v4.3.2), המשתקפת גם בדף הערות השחרור.
פרק 4. הגדרת סביבת פיתוח 33
4.1.3 בחירת גרסה מתאימה
מאז ESP-IDF החלה לתמוך רשמית ב-ESP32-C3 מגרסה v4.3, ו-v4.4 עדיין לא שוחררה רשמית בזמן כתיבת ספר זה, הגרסה המשמשת בספר זה היא v4.3.2, שהיא גרסה מתוקנת של v4.3. עם זאת, חשוב לציין שעד שתקראו את הספר הזה, ייתכן שגרסאות 4.4 או חדשות יותר כבר יהיו זמינות. בעת בחירת גרסה, אנו ממליצים על הדברים הבאים:
· למפתחים ברמת התחלה, רצוי לבחור בגרסת v4.3 היציבה או בגרסה המתוקנת שלה, המתיישרת עם האקסיתampהגרסה המשמשת בספר זה.
· למטרות ייצור המוני, מומלץ להשתמש בגרסה היציבה העדכנית ביותר כדי ליהנות מהתמיכה הטכנית העדכנית ביותר.
· אם אתה מתכוון להתנסות עם שבבים חדשים או לחקור תכונות מוצר חדשות, אנא השתמש בסניף המאסטר. הגרסה העדכנית ביותר מכילה את כל התכונות העדכניות ביותר, אך זכור שייתכן שיש באגים ידועים או לא ידועים.
· אם הגרסה היציבה שבה נעשה שימוש אינה כוללת את התכונות החדשות הרצויות וברצונך למזער את הסיכונים הכרוכים בסניף הראשי, שקול להשתמש בענף ההפצה המתאים, כגון סניף המהדורה/v4.4. מאגר GitHub של Espressif יצור תחילה את ה-release/v4.4 סניף ובהמשך ישחרר את גרסת v4.4 היציבה בהתבסס על תמונת מצב היסטורית ספציפית של ענף זה, לאחר השלמת כל פיתוח ובדיקות תכונות.
4.1.4 נגמרview של ESP-IDF SDK Directory
ESP-IDF SDK מורכב משתי ספריות עיקריות: esp-idf ו-.espressif. הראשון מכיל את קוד המקור של מאגר ESP-IDF files ותסריטי קומפילציה, בעוד שהאחרון מאחסן בעיקר רשתות כלי קומפילציה ותוכנות אחרות. היכרות עם שתי הספריות הללו תעזור למפתחים לנצל טוב יותר את המשאבים הזמינים ולהאיץ את תהליך הפיתוח. מבנה הספריות של ESP-IDF מתואר להלן:
(1) ספריית קוד מאגר ESP-IDF (/esp/esp-idf), כפי שמוצג באיור 4.2.
א. רכיבי ספריית רכיבים
ספריית הליבה הזו משלבת רכיבי תוכנה חיוניים רבים של ESP-IDF. לא ניתן להרכיב קוד פרויקט מבלי להסתמך על הרכיבים שבתיקייה זו. זה כולל תמיכה במנהלי התקנים עבור שבבי Espressif שונים. ממשקי ספריית LL וספריית HAL עבור ציוד היקפי ועד למנהלי התקן וירטואליים ברמה העליונה File תמיכת שכבת מערכת (VFS), מפתחים יכולים לבחור את הרכיבים המתאימים ברמות שונות לצרכי הפיתוח שלהם. ESP-IDF תומך גם בערימות פרוטוקול רשת סטנדרטיות מרובות כגון TCP/IP, HTTP, MQTT, WebSocket וכו'. מפתחים יכולים להשתמש בממשקים מוכרים כמו Socket לבניית יישומי רשת. רכיבים מספקים הבנה-
34 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
איור 4.2. ספריית קודים של מאגר ESP-IDF
פונקציונליות sive וניתן לשלב אותה בקלות באפליקציות, מה שמאפשר למפתחים להתמקד אך ורק בלוגיקה העסקית. כמה רכיבים נפוצים כוללים: · מנהל התקן: רכיב זה מכיל תוכניות מנהלי התקן היקפיות עבור Espressif שונות
סדרות שבבים, כגון GPIO, I2C, SPI, UART, LEDC (PWM) וכו'. תוכניות מנהל ההתקן ההיקפי ברכיב זה מציעות ממשקים מופשטים בלתי תלויים בשבב. לכל ציוד היקפי יש כותרת משותפת file (כגון gpio.h), ומבטל את הצורך להתמודד עם שאלות תמיכה שונות ספציפיות לשבב. · esp_wifi: Wi-Fi, כאל ציוד היקפי מיוחד, מטופל כרכיב נפרד. זה כולל מספר ממשקי API כגון אתחול של מצבי מנהלי התקן Wi-Fi שונים, תצורת פרמטרים ועיבוד אירועים. פונקציות מסוימות של רכיב זה מסופקות בצורה של ספריות קישורים סטטיות. ESP-IDF מספק גם תיעוד מקיף של מנהלי התקנים לנוחות השימוש.
פרק 4. הגדרת סביבת פיתוח 35
· freertos: רכיב זה מכיל את קוד FreeRTOS המלא. מלבד מתן תמיכה מקיפה למערכת הפעלה זו, Espressif הרחיבה את התמיכה שלה גם לשבבי ליבה כפולה. עבור שבבים דו-ליבים כמו ESP32 ו-ESP32-S3, משתמשים יכולים ליצור משימות על ליבות ספציפיות.
ב. מסמכי ספריית מסמכים
ספרייה זו מכילה מסמכי פיתוח הקשורים ל-ESP-IDF, כולל מדריך התחלת העבודה, מדריך עזר ל-API, מדריך פיתוח וכו'.
הערה לאחר הידור על ידי כלים אוטומטיים, התוכן של ספרייה זו נפרס בכתובת https://docs.espressif.com/projects/esp-idf. אנא הקפד להעביר את יעד המסמך ל-ESP32-C3 ובחר את גרסת ה-ESP-IDF שצוינה.
ג. כלי כלי סקריפט
ספרייה זו מכילה כלי חזית קומפילציה נפוצים כגון idf.py, וכלי מסוף המוניטור idf_monitor.py וכו'. ספריית המשנה cmake מכילה גם סקריפט ליבה files של מערכת הקומפילציה, המשמשת כבסיס ליישום כללי הידור ESP-IDF. בעת הוספת משתני הסביבה, התוכן בתוך ספריית הכלים מתווסף למשתנה סביבת המערכת, מה שמאפשר להפעיל את idf.py ישירות מתחת לנתיב הפרויקט.
ד. לְשֶׁעָבַרampספריית התוכניות לדוגמאamples
ספרייה זו כוללת אוסף עצום של ESP-IDF לשעברampתוכניות המדגימות את השימוש בממשקי API של רכיבים. האקסampהקבצים מאורגנים בספריות משנה שונות בהתבסס על הקטגוריות שלהם:
· התחלה: ספריית משנה זו כוללת דוגמה ברמת הכניסהampדברים כמו "שלום עולם" ו"מצמוץ" כדי לעזור למשתמשים להבין את היסודות.
· Bluetooth: אתה יכול למצוא דוגמה הקשורה ל-Bluetoothampכאן, כולל Bluetooth LE Mesh, Bluetooth LE HID, BluFi ועוד.
· wifi: ספריית משנה זו מתמקדת ב-Wi-Fi למשלamples, כולל תוכניות בסיסיות כמו Wi-Fi SoftAP, Wi-Fi Station, espnow, כמו גם פרוטוקול תקשורת קנייני לשעברamples מאספרסיף. זה כולל גם שכבות יישום מרובות למשלamples מבוסס על Wi-Fi, כגון Iperf, Sniffer ו-Smart Config.
· ציוד היקפי: ספריית משנה נרחבת זו מחולקת למספר רב של תיקיות משנה המבוססות על שמות היקפיים. הוא מכיל בעיקר דרייבר היקפי לשעברamples עבור צ'יפס אספרסיבי, עם כל אקסample המציג כמה תת-עברותamples. לדוגמה, ספריית המשנה gpio כוללת שנייםamples: מקלדת מטריצת GPIO ו-GPIO. חשוב לציין שלא כל האקסampהקבצים בספרייה זו ישימים ל-ESP32-C3.
36 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
למשלampלה, האקסamples ב-usb/host חלים רק על ציוד היקפי עם חומרת מארח USB (כגון ESP32-S3), ול-ESP32-C3 אין ציוד היקפי זה. מערכת הקומפילציה מספקת בדרך כלל הנחיות בעת הגדרת היעד. ה-README file של כל אקסample מפרט את השבבים הנתמכים. · פרוטוקולים: ספריית משנה זו מכילה למשלamples עבור פרוטוקולי תקשורת שונים, כולל MQTT, HTTP, HTTP Server, PPPoS, Modbus, mDNS, SNTP, המכסים מגוון רחב של פרוטוקולי תקשורת, למשלampנתונים הנדרשים לפיתוח IoT. · הקצאה: כאן תמצא למשל הקצאהamples עבור שיטות שונות, כגון הקצאת Wi-Fi והקצאת Bluetooth LE. · מערכת: ספריית משנה זו כוללת איתור באגים במערכת למשלamples (למשל, מעקב מחסנית, מעקב אחר זמן ריצה, ניטור משימות), ניהול צריכת חשמל למשלamples (למשל, מצבי שינה שונים, מעבדים משותפים), ודוגמאותampמידע הקשור לרכיבי מערכת נפוצים כמו מסוף מסוף, לולאת אירועים וטיימר מערכת. · אחסון: בתוך ספריית משנה זו, תגלו דוגמאampפחות מכולם file מערכות ומנגנוני אחסון הנתמכים על ידי ESP-IDF (כגון קריאה וכתיבה של פלאש, כרטיס SD ואמצעי אחסון אחרים), כמו גם לשעברampחומרי אחסון לא נדיפים (NVS), FatFS, SPIFFS ואחרים file פעולות המערכת. · אבטחה: ספריית משנה זו מכילה למשלampמסמכים הקשורים להצפנת פלאש. (2) ספריית שרשרת כלי הידור ESP-IDF (/.espressif), כפי שמוצג באיור 4.3.
איור 4.3. ספריית שרשרת כלי הידור ESP-IDF
פרק 4. הגדרת סביבת פיתוח 37
א. מרחק ספריית הפצת תוכנה
שרשרת הכלים ESP-IDF ותוכנות נוספות מופצות בצורה של חבילות דחוסות. במהלך תהליך ההתקנה, כלי ההתקנה מוריד תחילה את החבילה הדחוסה לספריית dist, ולאחר מכן מחלץ אותה לספרייה שצוינה. לאחר השלמת ההתקנה, ניתן להסיר בבטחה את התוכן בספרייה זו.
ב. ספריית הסביבה הווירטואלית של Python python env
גרסאות שונות של ESP-IDF מסתמכות על גרסאות ספציפיות של חבילות Python. התקנת חבילות אלו ישירות על אותו מארח עלולה להוביל להתנגשויות בין גרסאות החבילות. כדי להתמודד עם זה, ESP-IDF משתמש בסביבות וירטואליות של Python כדי לבודד גרסאות חבילה שונות. בעזרת מנגנון זה, מפתחים יכולים להתקין גרסאות מרובות של ESP-IDF על אותו מארח ולעבור בקלות ביניהן על ידי ייבוא משתני סביבה שונים.
ג. כלי ספריית שרשרת כלי הידור ESP-IDF
ספרייה זו מכילה בעיקר כלי קומפילציה צולבים הנדרשים להידור פרויקטים של ESP-IDF, כגון כלי CMake, כלי בניית Ninja ושרשרת הכלים gcc המייצרת את תוכנית ההפעלה הסופית. בנוסף, ספרייה זו מכילה את הספרייה הסטנדרטית של שפת C/C++ יחד עם הכותרת המתאימה fileס. אם תוכנית מפנה לכותרת מערכת file כמו #include , שרשרת כלי ההידור תאתר את ה-stdio.h file בתוך ספרייה זו.
4.2 הקמת סביבת פיתוח ESP-IDF
סביבת הפיתוח של ESP-IDF תומכת במערכות הפעלה מיינסטרים כגון Windows, Linux ו-macOS. חלק זה יציג כיצד להגדיר את סביבת הפיתוח בכל מערכת. מומלץ לפתח את ESP32-C3 על מערכת לינוקס, אשר יוצג בפירוט כאן. הוראות רבות ישימות על פני פלטפורמות בשל הדמיון של כלי הפיתוח. לכן, מומלץ לקרוא בעיון את התוכן של סעיף זה.
הערה אתה יכול לעיין במסמכים המקוונים הזמינים בכתובת https://bookc3.espressif.com/esp32c3, המספקים את הפקודות המוזכרות בסעיף זה.
4.2.1 הגדרת סביבת פיתוח ESP-IDF על לינוקס
כלי הפיתוח והניפוי של GNU הנדרשים עבור סביבת הפיתוח של ESP-IDF הם מקוריים למערכת לינוקס. בנוסף, מסוף שורת הפקודה בלינוקס הוא חזק וידידותי למשתמש, מה שהופך אותו לבחירה אידיאלית לפיתוח ESP32-C3. אתה יכול
38 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
בחר את הפצת הלינוקס המועדפת עליך, אך אנו ממליצים להשתמש באובונטו או במערכות אחרות מבוססות Debian. סעיף זה מספק הנחיות לגבי הגדרת סביבת הפיתוח ESP-IDF ב-Ubuntu 20.04.
1. התקן את החבילות הנדרשות
פתח מסוף חדש והפעל את הפקודה הבאה כדי להתקין את כל החבילות הדרושות. הפקודה תדלג אוטומטית על חבילות שכבר מותקנות.
$ sudo apt-get install git wget flex bison gperf python3 python3-pip python3setuptools cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0
טיפים עליך להשתמש בחשבון המנהל והסיסמה עבור הפקודה למעלה. כברירת מחדל, לא יוצג מידע בעת הזנת הסיסמה. פשוט לחץ על מקש "Enter" כדי להמשיך בהליך.
Git הוא כלי ניהול קוד מפתח ב-ESP-IDF. לאחר הגדרת סביבת הפיתוח בהצלחה, תוכל להשתמש בפקודה git log כדי view כל שינויי הקוד שבוצעו מאז הקמת ESP-IDF. בנוסף, נעשה שימוש ב-Git גם ב-ESP-IDF כדי לאשר את פרטי הגרסה, הנחוצים להתקנת שרשרת הכלים הנכונה התואמת לגרסאות ספציפיות. יחד עם Git, כלי מערכת חשובים נוספים כוללים את Python. ESP-IDF משלבת סקריפטים אוטומציה רבים שנכתבו ב- Python. כלים כגון CMake, Ninja-build ו-Ccache נמצאים בשימוש נרחב בפרויקטים של C/C++ ומשמשים ככלי ברירת המחדל לאיסוף ובניית קוד ב-ESP-IDF. libusb-1.0-0 ו-dfu-util הם מנהלי ההתקן העיקריים המשמשים לתקשורת USB טורית וצריבת קושחה. לאחר התקנת חבילות התוכנה, תוכל להשתמש ב-apt show פקודה לקבלת תיאורים מפורטים של כל חבילה. למשלample, השתמש ב-apt show git כדי להדפיס את מידע התיאור עבור הכלי Git.
ש: מה לעשות אם גרסת Python אינה נתמכת? ת: ESP-IDF v4.3 דורש גרסת Python שאינה נמוכה מ-v3.6. עבור גרסאות ישנות יותר של אובונטו, אנא הורד והתקן ידנית גרסה גבוהה יותר של Python והגדר את Python3 כסביבת Python ברירת המחדל. תוכל למצוא הוראות מפורטות על ידי חיפוש מילת המפתח update-alternatives python.
2. הורד את קוד מאגר ESP-IDF
פתח מסוף וצור תיקיה בשם esp בספריית הבית שלך באמצעות הפקודה mkdir. אתה יכול לבחור שם אחר לתיקיה אם אתה מעדיף. השתמש בפקודה cd כדי להיכנס לתיקיה.
פרק 4. הגדרת סביבת פיתוח 39
$ mkdir -p /esp $ cd /esp
השתמש בפקודה git clone כדי להוריד את קוד מאגר ESP-IDF, כפי שמוצג להלן:
$ git clone -b v4.3.2 – רקורסיבי https://github.com/espressif/esp-idf.git
בפקודה למעלה, הפרמטר -b v4.3.2 מציין את הגרסה להורדה (במקרה זה, גרסה 4.3.2). הפרמטר –recursive מבטיח שכל מאגרי המשנה של ESP-IDF יורדים באופן רקורסיבי. מידע על מאגרי משנה ניתן למצוא ב-.gitmodules file.
3. התקן את שרשרת כלי הפיתוח של ESP-IDF
Espressif מספקת סקריפט אוטומטי install.sh להורדה והתקנה של שרשרת הכלים. סקריפט זה בודק את גרסת ה-ESP-IDF ואת סביבת מערכת ההפעלה הנוכחית, ולאחר מכן מוריד ומתקין את הגרסה המתאימה של חבילות כלי Python ושרשרות כלי הידור. נתיב ההתקנה המוגדר כברירת מחדל עבור שרשרת הכלים הוא /.espressif. כל מה שאתה צריך לעשות הוא לנווט לספריית esp-idf ולהפעיל את install.sh.
$ cd /esp/esp-idf $ ./install.sh
אם תתקין את שרשרת הכלים בהצלחה, המסוף יציג:
הכל נעשה!
בשלב זה, הגדרת בהצלחה את סביבת הפיתוח של ESP-IDF.
4.2.2 הגדרת סביבת פיתוח ESP-IDF ב-Windows
1. הורד את מתקין הכלים של ESP-IDF
טיפים מומלץ להגדיר את סביבת הפיתוח ESP-IDF ב-Windows 10 ומעלה. אתה יכול להוריד את תוכנית ההתקנה מ https://dl.espressif.com/dl/esp-idf/. תוכנית ההתקנה היא גם תוכנת קוד פתוח, וקוד המקור שלה יכול להיות viewעורך בכתובת https: //github.com/espressif/idf-installer.
· מתקין כלי ESP-IDF מקוון
מתקין זה קטן יחסית, בגודל של בסביבות 4 מגה-בייט, וחבילות וקוד אחרים יורדו במהלך תהליך ההתקנה. האדוואןtage של המתקין המקוון הוא שלא רק שניתן להוריד חבילות תוכנה וקוד לפי דרישה במהלך תהליך ההתקנה, אלא גם מאפשר התקנה של כל המהדורות הזמינות של ESP-IDF והענף העדכני ביותר של קוד GitHub (כגון סניף המאסטר) . החיסרוןtage היא שזה דורש חיבור רשת במהלך תהליך ההתקנה, מה שעלול לגרום לכשל בהתקנה עקב בעיות רשת.
40 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
· מתקין כלים לא מקוון ESP-IDF מתקין זה גדול יותר, בגודל של כ-1 GB, ומכיל את כל חבילות התוכנה והקוד הנדרשים להגדרת הסביבה. האדוואן הראשיtagאחד של מתקין ההתקנה הלא מקוון הוא שניתן להשתמש בו במחשבים ללא גישה לאינטרנט, ובדרך כלל יש לו שיעור הצלחה גבוה יותר בהתקנה. יש לציין שהמתקין הלא מקוון יכול להתקין רק מהדורות יציבות של ESP-IDF המזוהות על ידי v*.* או v*.*.*.
2. הפעל את מתקין הכלים של ESP-IDF לאחר הורדת גרסה מתאימה של המתקין (קח את ESP-IDF Tools Offline 4.3.2 למשלampכאן), לחץ פעמיים על ה-exe file כדי להפעיל את ממשק ההתקנה של ESP-IDF. להלן מדגים כיצד להתקין את הגרסה היציבה של ESP-IDF v4.3.2 באמצעות תוכנית ההתקנה הלא מקוונת.
(1) בממשק "בחר שפת התקנה" המוצג באיור 4.4, בחר את השפה שתשמש מהרשימה הנפתחת.
איור 4.4. ממשק "בחר שפת התקנה" (2) לאחר בחירת השפה, לחץ על "אישור" כדי לקפוץ את ממשק "הסכם הרישיון"
(ראה איור 4.5). לאחר קריאת הסכם רישיון ההתקנה בקפידה, בחר "אני מקבל את ההסכם" ולחץ על "הבא".
איור 4.5. ממשק "הסכם רישיון" פרק 4. הגדרת סביבת פיתוח 41
(3) Review תצורת המערכת בממשק "בדיקת מערכת לפני התקנה" (ראה איור 4.6). בדוק את גרסת Windows ואת המידע על תוכנת האנטי-וירוס המותקנת. לחץ על "הבא" אם כל פריטי התצורה תקינים. אחרת, תוכל ללחוץ על "יומן מלא" לקבלת פתרונות המבוססים על פריטי מפתח.
איור 4.6. TIPS ממשק "בדיקת מערכת לפני ההתקנה".
אתה יכול לשלוח יומנים אל https://github.com/espressif/idf-installer/issues לקבלת עזרה. (4) בחר את ספריית ההתקנה של ESP-IDF. כאן, בחר D:/.espressif, כפי שמוצג ב
איור 4.7, ולחץ על "הבא". שימו לב ש-.espressif הנה ספרייה נסתרת. לאחר השלמת ההתקנה, אתה יכול view התוכן הספציפי של ספרייה זו על ידי פתיחת ה file מנהל והצגת פריטים מוסתרים.
איור 4.7. בחר את ספריית ההתקנה של ESP-IDF 42 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT
(5) בדוק את הרכיבים שיש להתקין, כפי שמוצג באיור 4.8. מומלץ להשתמש באפשרות ברירת המחדל, כלומר להשלים את ההתקנה, ולאחר מכן ללחוץ על "הבא".
איור 4.8. בחר את הרכיבים להתקנה (6) אשר את הרכיבים להתקנה ולחץ על "התקן" כדי להפעיל את ה-
תהליך הסטייה, כפי שמוצג באיור 4.9. תהליך ההתקנה עשוי להימשך עשרות דקות וסרגל ההתקדמות של תהליך ההתקנה מוצג באיור 4.10. אנא המתן בסבלנות.
איור 4.9. הכנה להתקנה (7) לאחר סיום ההתקנה, מומלץ לסמן "רשום את ה-ESP-IDF
כלים קובצי הפעלה כהחרגות של Windows Defender..." כדי למנוע מחיקה של תוכנת אנטי-וירוס fileס. הוספת פריטי אי הכללה יכולה גם לדלג על סריקות תכופות על ידי אנטי וירוס
פרק 4. הגדרת סביבת פיתוח 43
איור 4.10. תוכנת פס התקדמות ההתקנה, משפרת מאוד את יעילות הידור הקוד של מערכת Windows. לחץ על "סיום" כדי להשלים את ההתקנה של סביבת הפיתוח, כפי שמוצג באיור 4.11. אתה יכול לבחור לסמן "הפעל סביבת ESP-IDF PowerShell" או "הפעל שורת הפקודה של ESP-IDF". הפעל את חלון ההידור ישירות לאחר ההתקנה כדי להבטיח שסביבת הפיתוח פועלת כרגיל.
איור 4.11. ההתקנה הושלמה (8) פתח את סביבת הפיתוח המותקנת ברשימת התוכניות (או ESP-IDF 4.3
מסוף CMD או ESP-IDF 4.3 PowerShell, כפי שמוצג באיור 4.12), ומשתנה הסביבה ESP-IDF יתווספו אוטומטית בעת הפעלה במסוף. לאחר מכן, תוכל להשתמש בפקודה idf.py לפעולות. ה-ESP-IDF 4.3 CMD שנפתח מוצג באיור 4.13. 44 הרפתקאות אלחוטיות ESP32-C3: מדריך מקיף ל-IoT
איור 4.12. הותקנה סביבת פיתוח
איור 4.13. ESP-IDF 4.3 CMD
4.2.3 הגדרת סביבת פיתוח ESP-IDF ב-Mac
תהליך התקנת סביבת הפיתוח ESP-IDF על מערכת Mac זהה לזה של מערכת לינוקס. הפקודות להורדת קוד המאגר ולהתקנת שרשרת הכלים זהות לחלוטין. רק הפקודות להתקנת חבילות תלות שונות במקצת. 1. התקנת חבילות תלות פתחו מסוף והתקינו את pip, כלי ניהול החבילות של Python, על ידי הפעלת הפקודה הבאה:
% sudo התקנה קלה pip
התקן את Homebrew, כלי ניהול חבילות עבור macOS, על ידי הפעלת הפקודה הבאה:
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/ HEAD/install.sh)"
התקן את חבילות התלות הנדרשות על ידי הפעלת הפקודה הבאה:
% brew python3 להתקין cmake נינג'ה ccache dfu-util
2. הורד את קוד מאגר ESP-IDF עקוב אחר ההוראות בסעיף 4.2.1 כדי להוריד את קוד מאגר ESP-IDF. השלבים זהים להורדה במערכת לינוקס.
פרק 4. הגדרת סביבת פיתוח 45
3. התקן את שרשרת כלי הפיתוח של ESP-IDF
עקוב אחר ההוראות המפורטות בסעיף 4.2.1 כדי להתקין את שרשרת כלי הפיתוח של ESP-IDF. השלבים זהים להתקנה על מערכת לינוקס.
4.2.4 התקנת קוד VS
כברירת מחדל, ה-ESP-IDF SDK אינו כולל כלי לעריכת קוד (אם כי המתקין העדכני ביותר של ESP-IDF עבור Windows מציע את האפשרות להתקין את ESP-IDF Eclipse). אתה יכול להשתמש בכל כלי עריכת טקסט לבחירתך כדי לערוך את הקוד ולאחר מכן לקמפל אותו באמצעות פקודות מסוף.
כלי עריכת קוד פופולרי אחד הוא VS Code (Visual Studio Code), שהוא עורך קוד חינמי ועתיר תכונות עם ממשק ידידותי למשתמש. הוא מציע מגוון plugins המספקות פונקציונליות כגון ניווט קוד, הדגשת תחביר, בקרת גרסאות Git ושילוב מסוף. בנוסף, Espressif פיתחה תוסף ייעודי בשם Espressif IDF עבור VS Code, אשר מפשט את תצורת הפרויקט ואיתור באגים.
אתה יכול להשתמש בפקודת הקוד בטרמינל כדי לפתוח במהירות את התיקיה הנוכחית בקוד VS. לחלופין, תוכל להשתמש בקיצור Ctrl+ כדי לפתוח את קונסולת המסוף המוגדרת כברירת מחדל של המערכת בתוך VS Code.
טיפים מומלץ להשתמש בקוד VS לפיתוח קוד ESP32-C3. הורד והתקן את הגרסה העדכנית ביותר של VS Code בכתובת https://code.visualstudio.com/.
4.2.5 מבוא לסביבות פיתוח של צד שלישי
בנוסף לסביבת הפיתוח הרשמית של ESP-IDF, המשתמשת בעיקר בשפת C, ESP32-C3 תומך גם בשפות תכנות אחרות מיינסטרים ובמגוון רחב של סביבות פיתוח של צד שלישי. כמה אפשרויות בולטות כוללות:
Arduino: פלטפורמת קוד פתוח לחומרה ותוכנה כאחד, התומכת במיקרו-בקרים שונים, כולל ESP32-C3.
הוא משתמש בשפת C++ ומציע API פשוט וסטנדרטי, המכונה בדרך כלל שפת Arduino. ארדואינו נמצא בשימוש נרחב בפיתוח אב טיפוס ובהקשרים חינוכיים. הוא מספק חבילת תוכנה הניתנת להרחבה ו-IDE המאפשר קומפילציה והבהבה קלים.
MicroPython: מתורגמן לשפה Python 3 שנועד לפעול על פלטפורמות מיקרו-בקר משובצות.
עם שפת סקריפט פשוטה, הוא יכול לגשת ישירות למשאבים ההיקפיים של ESP32-C3 (כגון UART, SPI ו-I2C) ולפונקציות התקשורת (כגון Wi-Fi ו-Bluetooth LE).
46 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
זה מפשט את האינטראקציה עם החומרה. MicroPython, בשילוב עם ספריית הפעולות המתמטיות הנרחבות של Python, מאפשרים הטמעה של אלגוריתמים מורכבים ב-ESP32-C3, מה שמקל על פיתוח יישומים הקשורים לבינה מלאכותית. כשפת תסריט, אין צורך בהידור חוזר; ניתן לבצע שינויים ולהפעיל סקריפטים ישירות.
NodeMCU: מתורגמן לשפת LUA שפותח עבור שבבים מסדרת ESP.
הוא תומך כמעט בכל הפונקציות ההיקפיות של שבבי ESP והוא קל יותר מ-MicroPython. בדומה ל-MicroPython, NodeMCU משתמש בשפת סקריפט, ומבטל את הצורך בהידור חוזר.
יתר על כן, ESP32-C3 תומך גם במערכות ההפעלה NuttX ו-Zephyr. NuttX היא מערכת הפעלה בזמן אמת המספקת ממשקים תואמי POSIX, ומשפרת את ניידות האפליקציות. Zephyr היא מערכת הפעלה קטנה בזמן אמת שתוכננה במיוחד עבור יישומי IoT. הוא כולל מספר רב של ספריות תוכנה הנדרשות בפיתוח IoT, ומתפתח בהדרגה לאקוסיסטם תוכנה מקיף.
ספר זה אינו מספק הוראות התקנה מפורטות עבור סביבות הפיתוח הנ"ל. אתה יכול להתקין סביבת פיתוח בהתבסס על הדרישות שלך על ידי ביצוע התיעוד וההוראות המתאימים.
4.3 מערכת הידור ESP-IDF
4.3.1 מושגים בסיסיים של מערכת קומפילציה
פרויקט ESP-IDF הוא אוסף של תוכנית ראשית עם פונקציית כניסה ורכיבים פונקציונליים מרובים עצמאיים. למשלample, פרויקט השולט במתגי LED מורכב בעיקר מתוכנית כניסה ראשית ורכיב דרייבר השולט ב-GPIO. אם אתה רוצה לממש את שלט רחוק LED, אתה צריך גם להוסיף Wi-Fi, מחסנית פרוטוקול TCP/IP וכו '.
מערכת הקומפילציה יכולה להדר, לקשר וליצור קובץ הפעלה files (.bin) עבור הקוד באמצעות קבוצה של כללי בנייה. מערכת הקומפילציה של גרסאות ESP-IDF v4.0 ומעלה מבוססת על CMake כברירת מחדל, וניתן להשתמש בסקריפט הקומפילציה CMakeLists.txt כדי לשלוט בהתנהגות הקומפילציה של הקוד. בנוסף לתמיכה בתחביר הבסיסי של CMake, מערכת הקומפילציה ESP-IDF מגדירה גם קבוצה של כללי הידור ופונקציות CMake ברירת מחדל, וניתן לכתוב את סקריפט ההידור עם הצהרות פשוטות.
4.3.2 פרויקט File מִבְנֶה
פרויקט הוא תיקייה המכילה תוכנית כניסה ראשית, רכיבים מוגדרים על ידי משתמש ו fileנדרשים לבניית יישומי הפעלה, כגון סקריפטים להידור, תצורה
פרק 4. הגדרת סביבת פיתוח 47
files, טבלאות מחיצות וכו'. ניתן להעתיק ולהעביר פרויקטים, ובאותו קובץ הפעלה file ניתן להידור וליצור במכונות עם אותה גרסה של סביבת פיתוח ESP-IDF. פרויקט טיפוסי של ESP-IDF file המבנה מוצג באיור 4.14.
איור 4.14. פרויקט ESP-IDF טיפוסי file מבנה מכיוון ש-ESP-IDF תומך במספר שבבי IoT מבית Espressif, כולל סדרת ESP32, ESP32-S, סדרת ESP32-C, סדרת ESP32-H וכו', יש לקבוע יעד לפני קומפילציה של הקוד. היעד הוא גם התקן החומרה המריץ את תוכנית האפליקציה וגם יעד הבנייה של מערכת ההידור. בהתאם לצרכים שלך, אתה יכול לציין יעד אחד או יותר עבור הפרויקט שלך. למשלample, באמצעות הפקודה idf.py set-target esp32c3, אתה יכול להגדיר את יעד ההידור ל-ESP32-C3, שבמהלכו ייטענו פרמטרי ברירת המחדל ונתיב שרשרת כלי ההידור עבור ESP32C3. לאחר ההידור, ניתן ליצור תוכנית הפעלה עבור ESP32C3. אתה יכול גם להפעיל שוב את הפקודה set-target כדי להגדיר יעד אחר, ומערכת ההידור תתנקה אוטומטית ותקבע מחדש. רכיבים
רכיבים ב-ESP-IDF הם יחידות קוד מודולריות ועצמאיות המנוהלות בתוך מערכת ההידור. הם מאורגנים כתיקיות, כאשר שם התיקיה מייצג את שם הרכיב כברירת מחדל. לכל רכיב יש סקריפט אוסף משלו ש-48 ESP32-C3 Wireless Adventure: A Comprehensive Guide to IoT
מפרט את פרמטרי ההידור והתלות שלו. במהלך תהליך הקומפילציה, רכיבים מורכבים לספריות סטטיות נפרדות (.a files) ובסופו של דבר בשילוב עם רכיבים אחרים כדי ליצור את תוכנית היישום.
ESP-IDF מספק פונקציות חיוניות, כגון מערכת ההפעלה, מנהלי התקנים היקפיים וערימת פרוטוקולי רשת, בצורה של רכיבים. רכיבים אלו מאוחסנים בספריית הרכיבים הנמצאת בתוך ספריית השורש של ESP-IDF. מפתחים אינם צריכים להעתיק את הרכיבים הללו לספריית הרכיבים של myProject. במקום זאת, הם צריכים רק לציין את יחסי התלות של רכיבים אלה ב-CMakeLists.txt של הפרויקט file באמצעות הוראות REQUIRES או PRIV_REQUIRES. מערכת הקומפילציה תאתר ותקומיל באופן אוטומטי את הרכיבים הנדרשים.
לכן, ספריית הרכיבים תחת myProject אינה נחוצה. הוא משמש רק כדי לכלול כמה רכיבים מותאמים אישית של הפרויקט, שיכולים להיות ספריות של צד שלישי או קוד מוגדר על ידי משתמש. בנוסף, ניתן לקבל רכיבים מכל ספרייה מלבד ESP-IDF או הפרויקט הנוכחי, כגון מפרויקט קוד פתוח שנשמר בספרייה אחרת. במקרה זה, אתה רק צריך להוסיף את הנתיב של הרכיב על ידי הגדרת המשתנה EXTRA_COMPONENT_DIRS ב-CMakeLists.txt תחת ספריית השורש. ספרייה זו תעקוף כל רכיב של ESP-IDF בעל אותו שם, ותבטיח שהרכיב הנכון יהיה בשימוש.
תוכנית הכניסה הראשית הספרייה הראשית בתוך הפרויקט פועלת בהתאם file מבנה כרכיבים אחרים (למשל, רכיב 1). עם זאת, יש לה משמעות מיוחדת שכן מדובר ברכיב חובה שחייב להתקיים בכל פרויקט. הספרייה הראשית מכילה את קוד המקור של הפרויקט ואת נקודת הכניסה של תוכנית המשתמש, הנקראת בדרך כלל app_main. כברירת מחדל, ההפעלה של תוכנית המשתמש מתחילה מנקודת כניסה זו. הרכיב הראשי שונה גם בכך שהוא תלוי אוטומטית בכל הרכיבים בנתיב החיפוש. לכן, אין צורך לציין במפורש תלות באמצעות הוראות REQUIRES או PRIV_REQUIRES בקובץ CMakeLists.txt file.
תְצוּרָה file ספריית הבסיס של הפרויקט מכילה תצורה file שנקרא sdkconfig, המכיל את פרמטרי התצורה של כל הרכיבים בתוך הפרויקט. ה-sdkconfig file נוצר אוטומטית על ידי מערכת ההידור וניתן לשנות וליצור מחדש על ידי הפקודה idf.py menuconfig. האפשרויות של menuconfig מקורן בעיקר ב-Kconfig.projbuild של הפרויקט וב-Kconfig של הרכיבים. מפתחי רכיבים בדרך כלל מוסיפים פריטי תצורה ב-Kconfig כדי להפוך את הרכיב לגמיש וניתן להגדרה.
ספריית Build כברירת מחדל, ספריית הבנייה בתוך הפרויקט מאחסנת ביניים files והפי-
פרק 4. הגדרת סביבת פיתוח 49
תוכניות הפעלה סופיות שנוצרו על ידי הפקודה idf.py build. באופן כללי, אין צורך לגשת ישירות לתוכן של ספריית ה-build. ESP-IDF מספק פקודות מוגדרות מראש לאינטראקציה עם הספרייה, כגון שימוש בפקודה idf.py flash לאיתור אוטומטי של הקובץ הבינארי המהודר file והבהב אותו לכתובת הפלאש שצוינה, או באמצעות הפקודה idf.py fullclean כדי לנקות את כל ספריית ה-build.
טבלת מחיצות (partitions.csv) כל פרויקט דורש טבלת מחיצות כדי לחלק את שטח ה-Flash ולציין את הגודל וכתובת ההתחלה של תוכנית ההפעלה ומרחב נתוני המשתמש. הפקודה idf.py flash או תוכנית השדרוג OTA תבהב את הקושחה לכתובת המתאימה לפי טבלה זו. ESP-IDF מספק מספר טבלאות מחיצות ברירת מחדל ברכיבים/partition_table, כגון partitions_singleapp.csv ו-partitions_two_ ota.csv, שניתן לבחור ב-menuconfig.
אם טבלת המחיצות המוגדרת כברירת מחדל של המערכת אינה יכולה לעמוד בדרישות הפרוייקט, ניתן להוסיף partitions.csv מותאם אישית לספריית הפרוייקט ולבחור ב-menuconfig.
4.3.3 כללי בנייה ברירת מחדל של מערכת הקומפילציה
כללים לעקוף רכיבים בעלי אותו שם במהלך תהליך חיפוש הרכיבים, מערכת ההידור פועלת לפי סדר מסוים. תחילה הוא מחפש רכיבים פנימיים של ESP-IDF, אחר כך מחפש רכיבים של פרויקט המשתמש, ולבסוף מחפש רכיבים ב-EXTRA_COMPONENT_DIRS. במקרים בהם מספר ספריות מכילות רכיבים בעלי אותו שם, הרכיב שנמצא בספריה האחרונה יעקוף את כל הרכיבים הקודמים בעלי אותו שם. כלל זה מאפשר התאמה אישית של רכיבי ESP-IDF בתוך פרויקט המשתמש, תוך שמירה על קוד ESP-IDF המקורי ללא פגע.
כללים להכללת רכיבים נפוצים כברירת מחדל כפי שהוזכר בסעיף 4.3.2, רכיבים צריכים לציין במפורש את התלות שלהם ברכיבים אחרים בקובץ CMakeLists.txt. עם זאת, רכיבים נפוצים כגון freertos נכללים אוטומטית במערכת הבנייה כברירת מחדל, גם אם קשרי התלות שלהם אינם מוגדרים במפורש בסקריפט ההידור. הרכיבים הנפוצים של ESP-IDF כוללים freertos, Newlib, heap, log, soc, esp_rom, esp_common, xtensa/riscv ו-cxx. שימוש ברכיבים נפוצים אלה מונע עבודה חוזרת בעת כתיבת CMakeLists.txt והופך אותו לתמציתי יותר.
כללים לעקוף פריטי תצורה מפתחים יכולים להוסיף פרמטרים של תצורת ברירת מחדל על ידי הוספת תצורת ברירת מחדל file בשם sdkconfig.defaults לפרויקט. למשלample, הוספת CONFIG_LOG_
50 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
DEFAULT_LEVEL_NONE = y יכול להגדיר את ממשק UART כך שלא ידפיס נתוני יומן כברירת מחדל. יתר על כן, אם צריך להגדיר פרמטרים ספציפיים עבור יעד מסוים, תצורה file ניתן להוסיף בשם sdkconfig.defaults.TARGET_NAME, כאשר TARGET_NAME יכול להיות esp32s2, esp32c3 וכן הלאה. תצורה אלה files מיובאים ל-sdkconfig במהלך ההידור, עם תצורת ברירת המחדל הכללית file sdkconfig.defaults מיובאים תחילה, ולאחר מכן התצורה הספציפית ליעד file, כגון sdkconfig.defaults.esp32c3. במקרים בהם יש פריטי תצורה בעלי אותו שם, התצורה האחרונה file יעקוף את הקודם.
4.3.4 מבוא לתסריט הקומפילציה
כאשר מפתחים פרויקט באמצעות ESP-IDF, מפתחים צריכים לא רק לכתוב קוד מקור אלא גם לכתוב CMakeLists.txt עבור הפרויקט והרכיבים. CMakeLists.txt הוא טקסט file, המכונה גם סקריפט קומפילציה, המגדיר סדרה של אובייקטי קומפילציה, פריטי תצורת קומפילציה ופקודות כדי להנחות את תהליך ההידור של קוד המקור. מערכת הקומפילציה של ESP-IDF v4.3.2 מבוססת על CMake. בנוסף לתמיכה בפונקציות ופקודות CMake מקוריות, היא גם מגדירה סדרה של פונקציות מותאמות אישית, מה שמקל בהרבה על כתיבת סקריפטים של קומפילציה.
תסריטי הקומפילציה ב-ESP-IDF כוללים בעיקר את סקריפט הידור של הפרויקט ואת סקריפטי ההידור המרכיבים. ה-CMakeLists.txt בספריית הבסיס של הפרויקט נקרא סקריפט הידור הפרויקט, המנחה את תהליך הקומפילציה של הפרויקט כולו. תסריט אוסף פרויקטים בסיסי כולל בדרך כלל את שלוש השורות הבאות:
1. cmake_minimum_required(גרסה 3.5) 2. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 3. project(myProject)
ביניהם, יש למקם את ה-cmake_minimum_required (גרסה 3.5) בשורה הראשונה, המשמשת לציון מספר הגרסה המינימלי של CMake הנדרש על ידי הפרויקט. גרסאות חדשות יותר של CMake בדרך כלל תואמות לאחור עם גרסאות ישנות יותר, לכן התאם את מספר הגרסה בהתאם בעת שימוש בפקודות CMake חדשות יותר כדי להבטיח תאימות.
include($ENV {IDF_PATH}/tools/cmake/project.cmake) מייבא פריטי תצורה ופקודות מוגדרים מראש של מערכת ההידור ESP-IDF, כולל כללי הבנייה המוגדרים כברירת מחדל של מערכת ההידור המתוארים בסעיף 4.3.3. project(myProject) יוצר את הפרויקט עצמו ומציין את שמו. שם זה ישמש בתור הפלט הבינארי הסופי file שם, כלומר, myProject.elf ו-myProject.bin.
פרויקט יכול לכלול מספר רכיבים, כולל הרכיב הראשי. הספרייה ברמה העליונה של כל רכיב מכילה CMakeLists.txt file, אשר נקרא סקריפט קומפילציה של רכיבים. סקריפטים של קומפילציה של רכיבים משמשים בעיקר לציון תלות של רכיבים, פרמטרי תצורה, קוד מקור files, וכלול כותרת files עבור
פרק 4. הגדרת סביבת פיתוח 51
הַהדָרָה. עם הפונקציה המותאמת אישית של ESP-IDF idf_component_register, הקוד המינימלי הנדרש עבור סקריפט הידור של רכיבים הוא כדלקמן:
1. idf_component_register(SRCS "src1.c"
2.
INCLUDE_DIRS "כלול"
3.
דורש רכיב1)
הפרמטר SRCS מספק רשימה של מקור files ברכיב, מופרדים ברווחים אם יש מרובים fileס. הפרמטר INCLUDE_DIRS מספק רשימה של כותרות ציבוריות file ספריות עבור הרכיב, שיתווספו לנתיב החיפוש include עבור רכיבים אחרים התלויים ברכיב הנוכחי. הפרמטר REQUIRES מזהה את התלות של הרכיב הציבורי עבור הרכיב הנוכחי. יש צורך ברכיבים לציין במפורש באילו רכיבים הם תלויים, כגון רכיב 2 תלוי ברכיב 1. עם זאת, עבור הרכיב הראשי, התלוי בכל הרכיבים כברירת מחדל, ניתן להשמיט את הפרמטר REQUIRES.
בנוסף, ניתן להשתמש בפקודות CMake מקוריות גם בסקריפט הקומפילציה. למשלample, השתמש בערכת הפקודות כדי להגדיר משתנים, כגון set(VARIABLE "VALUE").
4.3.5 מבוא לפקודות נפוצות
ESP-IDF משתמש ב- CMake (כלי קביעת פרויקטים), Ninja (כלי לבניית פרויקטים) ו-esptool (כלי פלאש) בתהליך הידור הקוד. כל כלי ממלא תפקיד אחר בתהליך ההידור, הבנייה וההבזק, וכן תומך בפקודות הפעלה שונות. כדי להקל על תפעול המשתמש, ESP-IDF מוסיף idf.py חזיתי מאוחד המאפשר לקרוא לפקודות לעיל במהירות.
לפני השימוש ב-idf.py, ודא כי:
· משתנה הסביבה IDF_PATH של ESP-IDF נוסף למסוף הנוכחי. · ספריית ביצוע הפקודה היא ספריית הבסיס של הפרויקט, הכוללת את
סקריפט הידור של פרויקט CMakeLists.txt.
הפקודות הנפוצות של idf.py הן כדלקמן:
· idf.py –help: הצגת רשימה של פקודות והוראות השימוש שלהן. · idf.py set-target : הגדרת הקומפילציה taidf.py fullcleanrget, כגון
כמחליף עם esp32c3. · idf.py menuconfig: הפעלת menuconfig, תצורה גרפית מסוף
כלי, שיכול לבחור או לשנות אפשרויות תצורה, ותוצאות התצורה נשמרות ב-sdkconfig file. · idf.py build: התחלת הידור קוד. הביניים files ותוכנית ההפעלה הסופית שנוצרה על ידי הקומפילציה תישמר בספריית ה-build של הפרויקט כברירת מחדל. תהליך הקומפילציה הוא אינקרמנטלי, מה שאומר שאם רק מקור אחד file שונה, רק השינוי file יערכו בפעם הבאה.
52 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
· idf.py נקי: ניקוי התווך files שנוצר על ידי אוסף הפרויקט. הפרויקט כולו ייאלץ להידור בהרכב הבא. שים לב שתצורת CMake ושינויי התצורה שנעשו על ידי menuconfig לא יימחקו במהלך הניקוי.
· idf.py fullclean: מחיקת כל ספריית ה-build, כולל כל פלט תצורת CMake fileס. בעת בניית הפרויקט מחדש, CMake תגדיר את הפרויקט מאפס. שים לב שפקודה זו תמחק את הכל באופן רקורסיבי files בספריית ה-build, אז השתמש בה בזהירות ובתצורת הפרויקט file לא יימחק.
· idf.py flash: מהבהב את תוכנית ההפעלה הבינארית file נוצר על ידי בנייה ליעד ESP32-C3. האפשרויות -עמ' ו ב משמשים להגדרת שם ההתקן של היציאה הטורית וקצב ההבהוב להבהב, בהתאמה. אם שתי האפשרויות הללו לא יצוינו, היציאה הטורית תזוהה אוטומטית ויעשה שימוש ברירת המחדל של קצב ה-baud.
· צג idf.py: מציג את פלט היציאה הטורית של היעד ESP32-C3. ניתן להשתמש באפשרות -p כדי לציין את שם ההתקן של היציאה הטורית בצד המארח. במהלך הדפסת יציאה טורית, הקש על שילוב המקשים Ctrl+] כדי לצאת מהצג.
ניתן גם לשלב את הפקודות לעיל לפי הצורך. למשלample, הפקודה idf.py build flash monitor תבצע הידור קוד, הבזק ותפתח את צג היציאה הטורית ברצף.
אתה יכול לבקר https://bookc3.espressif.com/build-system כדי לדעת יותר על מערכת הידור ESP-IDF.
4.4 תרגול: קומפילציה דוגמהampהתוכנית "מצמוץ"
4.4.1 דוגמאותampלניתוח
חלק זה ייקח את התוכנית Blink כאקסample לנתח את file כללי מבנה וקידוד של פרויקט אמיתי בפירוט. תוכנית Blink מיישמת את אפקט מהבהב LED, והפרויקט ממוקם בספרייה למשלamples/get-started/blink, המכיל מקור file, תצורה files, וכמה תסריטי אוסף.
פרויקט האור החכם שהוצג בספר זה מבוסס על האקס הזהampלתוכנית. פונקציות יתווספו בהדרגה בפרקים מאוחרים יותר כדי להשלים אותה סופית.
קוד המקור על מנת להדגים את כל תהליך הפיתוח, תוכנית Blink הועתקה ל-esp32c3-iot-projects/device firmware/1 blink.
מבנה הספריות של פרויקט ה-blink files מוצג באיור 4.15.
פרויקט blink מכיל רק ספרייה ראשית אחת, שהיא רכיב מיוחד
פרק 4. הגדרת סביבת פיתוח 53
איור 4.15. File מבנה ספריות של פרויקט blink
חייב להיכלל כמתואר בסעיף 4.3.2. הספרייה הראשית משמשת בעיקר לאחסון היישום של הפונקציה app_main() שהיא נקודת הכניסה לתוכנית המשתמש. פרויקט ה-blink אינו כולל את ספריית הרכיבים, כי האקס הזהample צריך להשתמש רק ברכיבים שמגיעים עם ESP-IDF ואינו דורש רכיבים נוספים. CMakeLists.txt הכלול בפרויקט blink משמש להנחיית תהליך הקומפילציה, בעוד Kconfig.projbuild משמש להוספת פריטי תצורה עבור אקס זהampהתוכנית ב-menuconfig. אחר מיותר files לא ישפיע על הקומפילציה של הקוד, ולכן הם לא יידונו כאן. הקדמה מפורטת לפרויקט מצמוץ files הוא כדלקמן.
1. /*blink.c כולל את הכותרת הבאה files*/
2. #include
//כותרת ספריית C Standard file
3. #include "freertos/freeRTOS.h" //הכותרת הראשית של FreeRTOS file
4. #include "freertos/task.h"
//כותרת המשימות FreeRTOS file
5. #include "sdkconfig.h"
//כותרת תצורה file נוצר על ידי kconfig
6. #include "driver/gpio.h"
//כותרת מנהל ההתקן של GPIO file
המקור file blink.c מכיל סדרה של כותרות files המקביל לפונקציה הצהרת-
אמות. ESP-IDF בדרך כלל עוקב אחר הסדר של הכללת כותרת ספרייה סטנדרטית files, FreeR-
כותרת TOS files, כותרת מנהל התקן files, כותרת רכיב אחר files, וכותרת הפרויקט files.
הסדר שבו הכותרת fileכלולים עשויים להשפיע על תוצאת הקומפילציה הסופית, אז נסה לעשות זאת
פעל לפי כללי ברירת המחדל. יש לציין כי sdkconfig.h נוצר באופן אוטומטי
על ידי kconfig וניתן להגדיר אותו רק באמצעות הפקודה idf.py menuconfig.
שינוי ישיר של כותרת זו file יוחלף.
1. /*אתה יכול לבחור את ה-GPIO המתאים לנורית ב-idf.py menuconfig, ותוצאת השינוי של menuconfig היא שהערך של CONFIG_BLINK
_GPIO ישתנה. אתה יכול גם לשנות ישירות את הגדרת המאקרו
כאן, ושנה את CONFIG_BLINK_GPIO לערך קבוע.*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO
3. void app_main(void)
4. {
5.
/*הגדר את IO כפונקציית ברירת המחדל של GPIO, הפעל מצב משיכה ו
6.
השבת מצבי קלט ופלט*/
7.
gpio_reset_pin(BLINK_GPIO);
54 ESP32-C3 Wireless Adventure: מדריך מקיף ל-IoT
8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. }
/*הגדר את GPIO למצב פלט*/ gpio_set_direction(BLINK_GPIO, GPIO_MODE_OUTPUT); while(1) {
/*הדפס יומן*/ printf(“כיבוי ה-LEDn”); /*כבה את LED (רמת פלט נמוכה)*/ gpio_set_level(BLINK_GPIO, 0); /*Delay (1000 ms)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf ("הפעלת LEDn"); /*הפעל את הנורית (פלט ברמה גבוהה)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay(1000 / portTICK_PERIOD_MS); }
הפונקציה app_main() ב-Blink example program משמשת כנקודת הכניסה לתוכניות משתמש. זוהי פונקציה פשוטה ללא פרמטרים וללא ערך החזרה. פונקציה זו נקראת לאחר שהמערכת השלימה אתחול, הכוללת משימות כגון אתחול היציאה הטורית של יומן הרישום, קביעת תצורה של ליבה יחידה/דואלית והגדרת כלב השמירה.
הפונקציה app_main() פועלת בהקשר של משימה בשם main. ניתן להתאים את גודל המחסנית והעדיפות של משימה זו ב-menuconfig Componentconfig Common ESP-related.
עבור משימות פשוטות כמו מהבהב נורית, ניתן ליישם את כל הקוד הדרוש ישירות בפונקציה app_main(). זה כרוך בדרך כלל באתחול ה-GPIO התואם ל-LED ושימוש בלולאת while(1) כדי להפעיל ולכבות את ה-LED. לחלופין, אתה יכול להשתמש ב-FreeRTOS API כדי ליצור משימה חדשה שמטפלת ב-LED מהבהב. לאחר שהמשימה החדשה נוצרה בהצלחה, תוכל לצאת מהפונקציה app_main() .
התוכן של main/CMakeLists.txt file, המנחה את תהליך הקומפילציה עבור הרכיב הראשי, הוא כדלקמן:
1. idf_component_register(SRCS "blink.c" INCLUDE_DIRS "." )
ביניהם, main/CMakeLists.txt קורא רק לפונקציית מערכת קומפילציה אחת, כלומר idf_component_register. בדומה ל-CMakeLists.txt עבור רוב הרכיבים האחרים, blink.c מתווסף ל-SRCS, והמקור fileיתווספו ל-SRCS יקומפלו. במקביל, ".", המייצג את הנתיב שבו נמצא CMakeLists.txt, יש להוסיף ל- INCLUDE_DIRS בתור ספריות החיפוש עבור כותרת עליונה fileס. התוכן של CMakeLists.txt הוא כדלקמן:
1. #ציין את v3.5 כגרסת ה-CMake הישנה ביותר הנתמכת על ידי הפרויקט הנוכחי 2. יש לשדרג #גרסאות נמוכות מ-v3.5 לפני המשך ההידור 3. cmake_minimum_required(VERSION 3.5) 4. #כלול את תצורת ברירת המחדל של CMake של ה-ESP -מערכת הידור של צה"ל
פרק 4. הגדרת סביבת פיתוח 55
5. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 6. #צור פרויקט בשם "blink" 7. project(myProject)
ביניהם, CMakeLists.txt בספריית השורש כולל בעיקר $ENV{IDF_ PATH}/tools/cmake/project.cmake, שהיא התצורה הראשית של CMake file מסופק על ידי ESP-IDF. הוא משמש כדי לכסות
מסמכים / משאבים
![]() |
Espressif Systems ESP32-C3 Wireless Adventure [pdfמדריך למשתמש ESP32-C3 Wireless Adventure, ESP32-C3, Wireless Adventure, Adventure |