Espressif Systems ESP32-C3 Wireless Adventure მომხმარებლის სახელმძღვანელო

სანამ იყენებდეთ ESP32-C3 Wireless Adventure-ს, დარწმუნდით, რომ ხართ
იცნობს IoT-ის კონცეფციებსა და არქიტექტურას. ეს დაეხმარება
გესმით, როგორ ჯდება მოწყობილობა უფრო დიდ IoT ეკოსისტემაში
და მისი პოტენციური აპლიკაციები ჭკვიან სახლებში.

IoT პროექტების გაცნობა და პრაქტიკა

ამ განყოფილებაში შეიტყობთ ტიპიური IoT პროექტების შესახებ,
მათ შორის ძირითადი მოდულები საერთო IoT მოწყობილობებისთვის, ძირითადი მოდულები
კლიენტის აპლიკაციებისა და საერთო IoT ღრუბლოვანი პლატფორმების. Ეს მოხდება
მოგცემთ საფუძველს თქვენი გაგებისა და შექმნისთვის
საკუთარი IoT პროექტები.

პრაქტიკა: Smart Light Project

ამ პრაქტიკულ პროექტში თქვენ შეისწავლით როგორ შექმნათ ჭკვიანი
განათება ESP32-C3 Wireless Adventure-ის გამოყენებით. პროექტის სტრუქტურა,
ფუნქციები, ტექნიკის მომზადება და განვითარების პროცესი იქნება
დეტალურად ახსნა.

პროექტის სტრუქტურა

პროექტი შედგება რამდენიმე კომპონენტისგან, მათ შორის
ESP32-C3 Wireless Adventure, LED-ები, სენსორები და ღრუბელი
backend.

პროექტის ფუნქციები

ჭკვიანი სინათლის პროექტი საშუალებას გაძლევთ აკონტროლოთ სიკაშკაშე და
LED-ების ფერი დისტანციურად მობილური აპლიკაციის საშუალებით ან web
ინტერფეისი.

ტექნიკის მომზადება

პროექტისთვის მოსამზადებლად, თქვენ უნდა შეაგროვოთ
საჭირო ტექნიკის კომპონენტები, როგორიცაა ESP32-C3 Wireless
სათავგადასავლო დაფა, LED-ები, რეზისტორები და კვების წყარო.

განვითარების პროცესი

განვითარების პროცესი მოიცავს განვითარების დაყენებას
გარემო, კოდის დაწერა LED-ების გასაკონტროლებლად, დაკავშირება
Cloud backend და სმარტის ფუნქციონირების ტესტირება
სინათლე.

ESP RainMaker-ის შესავალი

ESP RainMaker არის ძლიერი ჩარჩო IoT განვითარებისთვის
მოწყობილობები. ამ განყოფილებაში შეიტყობთ რა არის ESP RainMaker და
როგორ შეიძლება მისი განხორციელება თქვენს პროექტებში.

რა არის ESP RainMaker?

ESP RainMaker არის ღრუბელზე დაფუძნებული პლატფორმა, რომელიც უზრუნველყოფს კომპლექტს
ინსტრუმენტები და სერვისები IoT მოწყობილობების შესაქმნელად და მართვისთვის.

ESP RainMaker-ის დანერგვა

ეს ნაწილი განმარტავს სხვადასხვა კომპონენტებს, რომლებიც მონაწილეობენ
ESP RainMaker-ის დანერგვა, მოთხოვნის სერვისის ჩათვლით,
RainMaker აგენტი, ღრუბელი და RainMaker კლიენტი.

პრაქტიკა: ძირითადი პუნქტები 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 Core სისტემის აპარატურის დიზაინი

ESP32-C3 ძირითადი სისტემის ტექნიკის დიზაინი მოიცავს ენერგიას
მიწოდება, ჩართვის თანმიმდევრობა, სისტემის გადატვირთვა, SPI ფლეშ, საათის წყარო,
და RF და ანტენის მოსაზრებები. ეს ქვეგანყოფილება ითვალისწინებს
დეტალური ინფორმაცია ამ ასპექტების შესახებ.

FAQ

კითხვა: რა არის ESP RainMaker?

პასუხი: ESP RainMaker არის ღრუბელზე დაფუძნებული პლატფორმა, რომელიც უზრუნველყოფს ინსტრუმენტებს
და მომსახურება IoT მოწყობილობების მშენებლობისა და მართვისთვის. ეს ამარტივებს
განვითარების პროცესი და საშუალებას იძლევა მარტივი მოწყობილობის დაყენება, დისტანციურად
კონტროლი და მონიტორინგი.

კითხვა: როგორ დავაყენო განვითარების გარემო?
ESP32-C3?

პასუხი: ESP32-C3-ისთვის განვითარების გარემოს დასაყენებლად, გჭირდებათ
დააინსტალიროთ ESP-IDF (Espressif IoT Development Framework) და
დააკონფიგურირეთ იგი მითითებული ინსტრუქციის მიხედვით. ESP-IDF არის
ოფიციალური განვითარების ჩარჩო ESP32-ზე დაფუძნებული მოწყობილობებისთვის.

Q: რა მახასიათებლები აქვს ESP RainMaker-ს?

პასუხი: ESP RainMaker გთავაზობთ სხვადასხვა ფუნქციებს, მომხმარებლის ჩათვლით
მენეჯმენტი, საბოლოო მომხმარებლის ფუნქციები და ადმინისტრატორის ფუნქციები. მომხმარებლის მენეჯმენტი
საშუალებას გაძლევთ მარტივად განაცხადოთ მოწყობილობა და მონაცემთა სინქრონიზაცია. საბოლოო მომხმარებელი
ფუნქციები უზრუნველყოფს მოწყობილობების დისტანციურ მართვას მობილური აპლიკაციის საშუალებით ან
web ინტერფეისი. ადმინისტრატორის ფუნქციები უზრუნველყოფს ხელსაწყოებს მოწყობილობის მონიტორინგისთვის
და მენეჯმენტი.

View Fullscreen

ESP32-C3 უსადენო თავგადასავალი
IoT-ის ყოვლისმომცველი გზამკვლევი
Espressif Systems 12 წლის 2023 ივნისი

შინაარსი

I მომზადება

1 შესავალი IoT-ში

1.1 IoT არქიტექტურა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 IoT აპლიკაცია ჭკვიან სახლებში. . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 IoT პროექტების შესავალი და პრაქტიკა

2.1 ტიპიური IoT პროექტების შესავალი. . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 ძირითადი მოდულები საერთო IoT მოწყობილობებისთვის. . . . . . . . . . . . . . . . . 9

2.1.2 კლიენტის განაცხადების ძირითადი მოდულები. . . . . . . . . . . . . . . . . . . 10

2.1.3 შესავალი საერთო IoT ღრუბლოვანი პლატფორმების შესახებ. . . . . . . . . . . . . . 11

2.2 პრაქტიკა: Smart Light Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 პროექტის სტრუქტურა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 პროექტის ფუნქციები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 აპარატურის მომზადება. . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 განვითარების პროცესი. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 ESP RainMaker-ის შესავალი

3.1 რა არის ESP RainMaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 ESP RainMaker-ის დანერგვა. . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 მოთხოვნის სერვისი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 RainMaker აგენტი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

3.2.4 RainMaker კლიენტი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 პრაქტიკა: ძირითადი პუნქტები ESP RainMaker-ის განვითარებისთვის. . . . . . . . . . . . 25

3.4 ESP RainMaker-ის მახასიათებლები. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 მომხმარებლის მენეჯმენტი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 საბოლოო მომხმარებლის მახასიათებლები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.3 ადმინისტრატორის მახასიათებლები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 განვითარების გარემოს შექმნა

4.1 ESP-IDF დასრულდაview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 ESP-IDF ვერსიები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 ESP-IDF Git სამუშაო პროცესი. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 შესაფერისი ვერსიის არჩევა. . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4 მეტიview ESP-IDF SDK დირექტორია. . . . . . . . . . . . . . . . . . . . 34 4.2 ESP-IDF განვითარების გარემოს დაყენება. . . . . . . . . . . . . . . . . 38 4.2.1 ESP-IDF განვითარების გარემოს დაყენება Linux-ზე. . . . . . . . 38 4.2.2 ESP-IDF განვითარების გარემოს დაყენება Windows-ზე. . . . . . 40 4.2.3 ESP-IDF განვითარების გარემოს დაყენება Mac-ზე. . . . . . . . . 45 4.2.4 VS კოდის ინსტალაცია. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 შესავალი მესამე მხარის განვითარების გარემოში. . . . . . . . 46 4.3 ESP-IDF კომპილაციის სისტემა. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 კომპილაციის სისტემის ძირითადი ცნებები. . . . . . . . . . . . . . . . . . 47 4.3.2 პროექტი File სტრუქტურა . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 კომპილაციის სისტემის ნაგულისხმევი Build წესები. . . . . . . . . . . . . 50 4.3.4 შესავალი კომპილაციის სკრიპტში. . . . . . . . . . . . . . . . . . 51 4.3.5 შესავალი საერთო ბრძანებებში. . . . . . . . . . . . . . . . . . . 52 4.4 პრაქტიკა: შედგენა მაგampპროგრამა "Blink". . . . . . . . . . . . . . . . . . 53 4.4.1 მაგampანალიზი . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.2 Blink პროგრამის შედგენა . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 Blink პროგრამის ციმციმა. . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Blink პროგრამის სერიული პორტის ჟურნალის ანალიზი. . . . . . . . . . . . . . 60 4.5 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

II აპარატურის და დრაივერების განვითარება

5 Smart Light პროდუქტების აპარატურის დიზაინი ESP32-C3-ზე დაფუძნებული

5.1 Smart Light პროდუქტების მახასიათებლები და შემადგენლობა. . . . . . . . . . . . . . . 67

5.2 ESP32-C3 Core სისტემის აპარატურის დიზაინი. . . . . . . . . . . . . . . . . . . 70

5.2.1 კვების ბლოკი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2 ჩართვის თანმიმდევრობა და სისტემის გადატვირთვა. . . . . . . . . . . . . . . . . . 74

5.2.3 SPI Flash. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 PWM სიგნალების GPIO-ების კონფიგურაცია. . . . . . . . . . . . . . . . . . . . 82

5.3.3 პროგრამული უზრუნველყოფის ჩამოტვირთვა და გამართვის ინტერფეისი. . . . . . . . . . . . 82

5.3.4 სახელმძღვანელო RF დიზაინისთვის. . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.5 სახელმძღვანელო ელექტრომომარაგების დიზაინისთვის. . . . . . . . . . . . . . . . . . . 86 5.4 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 მძღოლის განვითარება

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 Dimming დრაივერის განვითარება. . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 არასტაბილური შენახვა (NVS). . . . . . . . . . . . . . . . . . . . . . . . 97

6.4.2 LED PWM კონტროლერი (LEDC). . . . . . . . . . . . . . . . . . . . . . . 98

6.4.3 LED PWM პროგრამირება. . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 პრაქტიკა: დრაივერების დამატება Smart Light პროექტში. . . . . . . . . . . . . . . . . 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 Bluetooth-ის საფუძვლები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.2.1 შესავალი Bluetooth-ში. . . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.2 Bluetooth კონცეფციები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.2.3 Bluetooth კავშირი. . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Wi-Fi ქსელის კონფიგურაცია. . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.3.1 Wi-Fi ქსელის კონფიგურაციის სახელმძღვანელო. . . . . . . . . . . . . . . . . . . . 131

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

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

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

7.3.5 სხვა მეთოდები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.4 Wi-Fi პროგრამირება. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.4.1 Wi-Fi კომპონენტები ESP-IDF-ში. . . . . . . . . . . . . . . . . . . . . . . 139 7.4.2 სავარჯიშო: Wi-Fi კავშირი . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.3 სავარჯიშო: ჭკვიანი Wi-Fi კავშირი . . . . . . . . . . . . . . . . . . . . . 145
7.5 პრაქტიკა: Wi-Fi კონფიგურაცია Smart Light პროექტში. . . . . . . . . . . . . . . 156 7.5.1 Wi-Fi კავშირი Smart Light პროექტში. . . . . . . . . . . . . . . . . 156 7.5.2 Smart Wi-Fi კონფიგურაცია. . . . . . . . . . . . . . . . . . . . . . . . . 157
7.6 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8 ადგილობრივი კონტროლი

159

8.1 შესავალი ლოკალურ კონტროლში. . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1.1 ადგილობრივი კონტროლის გამოყენება. . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.2 წლის ადვანიtagადგილობრივი კონტროლის es. . . . . . . . . . . . . . . . . . . . . . . . 161

8.1.3 კონტროლირებადი მოწყობილობების აღმოჩენა სმარტფონების საშუალებით. . . . . . . . . . 161

8.1.4 მონაცემთა კომუნიკაცია სმარტფონებსა და მოწყობილობებს შორის. . . . . . . . 162

8.2 ადგილობრივი აღმოჩენის საერთო მეთოდები. . . . . . . . . . . . . . . . . . . . . . . . 162

8.2.1 მაუწყებლობა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

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

8.2.3 შედარება მაუწყებლობასა და მრავალგადაცემას შორის. . . . . . . . . . . . . . 176

8.2.4 Multicast განაცხადის პროტოკოლი mDNS ლოკალური აღმოჩენისთვის. . . . . . . . 176

8.3 საერთო საკომუნიკაციო პროტოკოლები ადგილობრივი მონაცემებისთვის. . . . . . . . . . . . . . . 179

8.3.1 გადაცემის კონტროლის პროტოკოლი (TCP). . . . . . . . . . . . . . . . . . . 179

8.3.2 ჰიპერტექსტის გადაცემის პროტოკოლი (HTTP). . . . . . . . . . . . . . . . . . . 185

8.3.3 მომხმარებელი დაtagram პროტოკოლი (UDP). . . . . . . . . . . . . . . . . . . . . . 189

8.3.4 შეზღუდული განაცხადის პროტოკოლი (CoAP). . . . . . . . . . . . . . . . 192

8.3.5 Bluetooth პროტოკოლი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.3.6 მონაცემთა გადაცემის პროტოკოლების შეჯამება. . . . . . . . . . . . . . . 203

8.4 მონაცემთა უსაფრთხოების გარანტია. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

8.4.1 შესავალი სატრანსპორტო ფენის უსაფრთხოებაში (TLS). . . . . . . . . . . . . 207

8.4.2 შესავალი დაtagram Transport Layer Security (DTLS). . . . . . . 213

8.5 პრაქტიკა: ლოკალური კონტროლი Smart Light პროექტში. . . . . . . . . . . . . . . . . . 217

8.5.1 Wi-Fi-ზე დაფუძნებული ლოკალური კონტროლის სერვერის შექმნა. . . . . . . . . . . . . . . 217

8.5.2 ადგილობრივი კონტროლის ფუნქციონირების შემოწმება სკრიპტების გამოყენებით. . . . . . . . . . . 221

8.5.3 Bluetooth-ზე დაფუძნებული ლოკალური კონტროლის სერვერის შექმნა. . . . . . . . . . . . 222

8.6 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 ღრუბლოვანი კონტროლი

225

9.1 დისტანციური მართვის შესავალი. . . . . . . . . . . . . . . . . . . . . . . . . . 225

9.2 ღრუბლოვანი მონაცემთა კომუნიკაციის პროტოკოლები. . . . . . . . . . . . . . . . . . . . . . 226

9.2.1 MQTT შესავალი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 9.2.2 MQTT პრინციპები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.3 MQTT შეტყობინების ფორმატი. . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.4 პროტოკოლის შედარება. . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5 MQTT ბროკერის დაყენება Linux-სა და Windows-ზე. . . . . . . . . . . . 233 9.2.6 MQTT კლიენტის დაყენება ESP-IDF-ზე დაყრდნობით. . . . . . . . . . . . . . . . 235 9.3 MQTT მონაცემთა უსაფრთხოების უზრუნველყოფა. . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.1 სერტიფიკატების მნიშვნელობა და ფუნქცია. . . . . . . . . . . . . . . . . . . 237 9.3.2 სერთიფიკატების გენერირება ადგილობრივად. . . . . . . . . . . . . . . . . . . . . . 239 9.3.3 MQTT ბროკერის კონფიგურაცია. . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.4 MQTT კლიენტის კონფიგურაცია. . . . . . . . . . . . . . . . . . . . . . . . . 241 9.4 პრაქტიკა: დისტანციური მართვა ESP RainMaker-ის მეშვეობით. . . . . . . . . . . . . . . . 243 9.4.1 ESP RainMaker საფუძვლები. . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.4.2 Node and Cloud Backend საკომუნიკაციო პროტოკოლი . . . . . . . . . . . 244 9.4.3 კომუნიკაცია კლიენტსა და Cloud Backend-ს შორის. . . . . . . . . . . 249 9.4.4 მომხმარებლის როლები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.4.5 ძირითადი სერვისები. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.4.6 Smart Light Exampლე . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Android აქტივობის სასიცოცხლო ციკლი. . . . . . . . . . . . . . . . . . . . . . 272

10.1.5 iOS-ის სასიცოცხლო ციკლი Viewკონტროლერი. . . . . . . . . . . . . . . . . . . . . . 273

10.2 ახალი სმარტფონის აპლიკაციის პროექტის შექმნა. . . . . . . . . . . . . . . . . . . . . 275

10.2.1 მზადება ანდროიდის განვითარებისთვის. . . . . . . . . . . . . . . . . . . 275

10.2.2 ახალი Android პროექტის შექმნა. . . . . . . . . . . . . . . . . . . . . . 275

10.2.3 MyRainmaker-ისთვის დამოკიდებულებების დამატება. . . . . . . . . . . . . . . . . 276

10.2.4 ნებართვის მოთხოვნა Android-ში. . . . . . . . . . . . . . . . . . . . . . 277

10.2.5 მზადება iOS განვითარებისთვის. . . . . . . . . . . . . . . . . . . . . . 277

10.2.6 ახალი iOS პროექტის შექმნა. . . . . . . . . . . . . . . . . . . . . . . . 278

10.2.7 MyRainmaker-ისთვის დამოკიდებულებების დამატება. . . . . . . . . . . . . . . . . 279

10.2.8 ნებართვის მოთხოვნა iOS-ში. . . . . . . . . . . . . . . . . . . . . . . . . 280

10.3 აპლიკაციის ფუნქციური მოთხოვნების ანალიზი. . . . . . . . . . . . . . . . . . 281

10.3.1 პროექტის ფუნქციონალური მოთხოვნების ანალიზი. . . . . . . . . . . . 282

10.3.2 მომხმარებლის მენეჯმენტის მოთხოვნების ანალიზი. . . . . . . . . . . . . . . 282 10.3.3 მოწყობილობების უზრუნველყოფისა და სავალდებულო მოთხოვნების ანალიზი. . . . . . . 283 10.3.4 დისტანციური მართვის მოთხოვნების ანალიზი. . . . . . . . . . . . . . . . 283 10.3.5 დაგეგმვის მოთხოვნების ანალიზი. . . . . . . . . . . . . . . . . . . 284 10.3.6 მომხმარებელთა ცენტრის მოთხოვნების ანალიზი. . . . . . . . . . . . . . . . . . 285 10.4 მომხმარებელთა მენეჯმენტის განვითარება. . . . . . . . . . . . . . . . . . . . . . . . 285 10.4.1 RainMaker API-ების შესავალი. . . . . . . . . . . . . . . . . . . . . . 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 კვანძის ID-ის მიღება. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 10.5.5 უზრუნველყოფის მოწყობილობები. . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 10.6 მოწყობილობების მართვის შემუშავება. . . . . . . . . . . . . . . . . . . . . . . . . . 302 10.6.1 მოწყობილობების მიბმა Cloud ანგარიშებთან. . . . . . . . . . . . . . . . . . . . 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 მეტი Cloud 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) მაგampლე . . . . . . . . . . . . . . . . . . . . . . . 332

11.3.1 განაახლეთ პროგრამული უზრუნველყოფა ლოკალური ჰოსტის მეშვეობით. . . . . . . . . . . . . . . . . 332

11.3.2 განაახლეთ Firmware ESP RainMaker-ის მეშვეობით. . . . . . . . . . . . . . . 335

11.4 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

IV ოპტიმიზაცია და მასობრივი წარმოება

343

12 ენერგიის მართვა და დაბალი სიმძლავრის ოპტიმიზაცია

345

12.1 ESP32-C3 ენერგიის მართვა. . . . . . . . . . . . . . . . . . . . . . . . . . . 345

12.1.1 დინამიური სიხშირის სკალირება. . . . . . . . . . . . . . . . . . . . . . . . 346

12.1.2 ენერგიის მართვის კონფიგურაცია. . . . . . . . . . . . . . . . . . . . 348

12.2 ESP32-C3 დაბალი სიმძლავრის რეჟიმი . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

12.2.1 მოდემის ძილის რეჟიმი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

12.2.2 მსუბუქი ძილის რეჟიმი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

12.2.3 ღრმა ძილის რეჟიმი. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

12.2.4 მიმდინარე მოხმარება ენერგიის სხვადასხვა რეჟიმებში. . . . . . . . . . . . . 358

12.3 ენერგიის მართვა და დაბალი სიმძლავრის გამართვა. . . . . . . . . . . . . . . . . 359

12.3.1 ჟურნალის გამართვა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

12.3.2 GPIO გამართვა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

12.4 პრაქტიკა: ენერგიის მართვა Smart Light პროექტში. . . . . . . . . . . . . . . 363

12.4.1 ენერგიის მართვის ფუნქციის კონფიგურაცია. . . . . . . . . . . . . . . . . 364

12.4.2 გამოიყენეთ ენერგიის მართვის საკეტები. . . . . . . . . . . . . . . . . . . . . . 365

12.4.3 ენერგიის მოხმარების შემოწმება. . . . . . . . . . . . . . . . . . . . . . . 366

12.5 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

მოწყობილობის უსაფრთხოების 13 გაძლიერებული ფუნქცია

369

13.1 დასრულდაview IoT მოწყობილობის მონაცემთა უსაფრთხოების შესახებ. . . . . . . . . . . . . . . . . . . . . . . 369

13.1.1 რატომ უნდა დავიცვათ IoT მოწყობილობის მონაცემები? . . . . . . . . . . . . . . . . . . . . . . 370

13.1.2 ძირითადი მოთხოვნები IoT მოწყობილობის მონაცემთა უსაფრთხოებისთვის. . . . . . . . . . . . 371

13.2 მონაცემთა მთლიანობის დაცვა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

13.2.1 მთლიანობის შემოწმების მეთოდის შესავალი. . . . . . . . . . . . . . 372

13.2.2 პროგრამული უზრუნველყოფის მონაცემების მთლიანობის შემოწმება. . . . . . . . . . . . . . . . . . 373

13.2.3 ყოფილიampლე . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3 მონაცემთა კონფიდენციალურობის დაცვა. . . . . . . . . . . . . . . . . . . . . . . . . . 374

13.3.1 შესავალი მონაცემთა დაშიფვრაში. . . . . . . . . . . . . . . . . . . . . . 374

13.3.2 შესავალი Flash Encryption Scheme-ში. . . . . . . . . . . . . . . . . 376

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

13.3.4 Flash Encryption-ის სამუშაო რეჟიმი. . . . . . . . . . . . . . . . . . . . 380

13.3.5 Flash Encryption პროცესი . . . . . . . . . . . . . . . . . . . . . . . . . . 381

13.3.6 შესავალი NVS დაშიფვრაში. . . . . . . . . . . . . . . . . . . . . . 383

13.3.7 ყოფილიampFlash Encryption და NVS Encryption-ის les. . . . . . . . . . . 384

13.4 მონაცემთა ლეგიტიმურობის დაცვა. . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

13.4.1 შესავალი ციფრულ ხელმოწერაში. . . . . . . . . . . . . . . . . . . . . 386

13.4.2 დასრულდაview უსაფრთხო ჩატვირთვის სქემის . . . . . . . . . . . . . . . . . . . . . 388

13.4.3 შესავალი პროგრამული უზრუნველყოფის უსაფრთხო ჩატვირთვაში. . . . . . . . . . . . . . . . . . . 388 13.4.4 შესავალი აპარატურის უსაფრთხო ჩატვირთვაში. . . . . . . . . . . . . . . . . . 390 13.4.5 მაგampლეს . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 13.5 პრაქტიკა: უსაფრთხოების მახასიათებლები მასობრივ წარმოებაში. . . . . . . . . . . . . . . . . . 396 13.5.1 Flash Encryption და Secure Boot . . . . . . . . . . . . . . . . . . . . . 396 13.5.2 Flash დაშიფვრის და უსაფრთხო ჩატვირთვის ჩართვა Batch Flash Tools-ით. . 397 13.5.3 ჩართვა Flash Encryption და Secure Boot in Smart Light Project. . . 398 13.6 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

14 პროგრამული უზრუნველყოფის დაწვა და ტესტირება მასობრივი წარმოებისთვის

399

14.1 პროგრამული უზრუნველყოფის წვა მასობრივ წარმოებაში. . . . . . . . . . . . . . . . . . . . . . 399

14.1.1 მონაცემთა დანაყოფების განსაზღვრა. . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.1.2 პროგრამული უზრუნველყოფის დაწვა. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

14.2 მასობრივი წარმოების ტესტირება. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

14.3 პრაქტიკა: მასობრივი წარმოების მონაცემები Smart Light Project-ში. . . . . . . . . . . . . 404

14.4 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

15 ESP Insights: დისტანციური მონიტორინგის პლატფორმა

405

15.1 ESP Insights-ის შესავალი. . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

15.2 ESP Insights-ის დაწყება. . . . . . . . . . . . . . . . . . . . . . . . . 409

15.2.1 ESP Insights-ის დაწყება esp-inights პროექტში. . . . . . 409

15.2.2 სირბილი მაგample esp-inights პროექტში. . . . . . . . . . . . . . . 411

15.2.3 ანგარიშგების ძირითადი ინფორმაცია. . . . . . . . . . . . . . . . . . . . . 411

15.2.4 ინტერესთა ჟურნალის მორგება. . . . . . . . . . . . . . . . . . . . . . . . 412

15.2.5 მოხსენება გადატვირთვის მიზეზი. . . . . . . . . . . . . . . . . . . . . . . . . 413

15.2.6 მორგებული მეტრიკის მოხსენება. . . . . . . . . . . . . . . . . . . . . . . . . 413

15.3 პრაქტიკა: ESP Insights-ის გამოყენება Smart Light Project-ში. . . . . . . . . . . . . . . 416

15.4 რეზიუმე. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

შესავალი
ESP32-C3 არის ერთბირთვიანი Wi-Fi და Bluetooth 5 (LE) მიკროკონტროლერი SoC, რომელიც დაფუძნებულია ღია კოდის RISC-V არქიტექტურაზე. ის უზრუნველყოფს ძალაუფლების სწორ ბალანსს, I/O შესაძლებლობებს და უსაფრთხოებას, რითაც გთავაზობთ ოპტიმალურ ეკონომიურ გადაწყვეტას დაკავშირებული მოწყობილობებისთვის. ESP32-C3 ოჯახის სხვადასხვა აპლიკაციების საჩვენებლად, Espressif-ის ეს წიგნი მიგიყვანთ საინტერესო მოგზაურობაში AIoT-ში, დაწყებული IoT პროექტის შემუშავების საფუძვლებიდან და გარემოს დაყენებიდან პრაქტიკულ გამოცდილებამდე.amples. პირველ ოთხ თავში საუბარია IoT, ESP RainMaker და ESP-IDF-ზე. მე-5 და მე-6 თავები მოკლე ტექნიკის დიზაინისა და დრაივერის განვითარების შესახებ. პროგრესთან ერთად, თქვენ აღმოაჩენთ, თუ როგორ უნდა დააკონფიგურიროთ თქვენი პროექტი Wi-Fi ქსელებისა და მობილური აპების მეშვეობით. და ბოლოს, თქვენ ისწავლით თქვენი პროექტის ოპტიმიზაციას და მასობრივ წარმოებას.
თუ თქვენ ხართ ინჟინერი მონათესავე სფეროებში, პროგრამული უზრუნველყოფის არქიტექტორი, მასწავლებელი, სტუდენტი ან ვინმე, ვინც დაინტერესებულია IoT-ით, ეს წიგნი თქვენთვისაა.
შეგიძლიათ ჩამოტვირთოთ კოდი exampამ წიგნში გამოყენებულია Espressif-ის საიტიდან GitHub-ზე. IoT განვითარების შესახებ უახლესი ინფორმაციისთვის, გთხოვთ, მიჰყევით ჩვენს ოფიციალურ ანგარიშს.

წინასიტყვაობა
Informatising World
ინტერნეტის ტალღაზე ასვლისას, ნივთების ინტერნეტმა (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 წლის ივლისის მდგომარეობით, Espressif-ის IoT ჩიპსეტების კუმულატიურმა გადაზიდვებმა გადააჭარბა 800 მილიონს, რაც ლიდერობს Wi-Fi MCU ბაზარზე და აძლიერებს დაკავშირებული მოწყობილობების დიდ რაოდენობას მთელ მსოფლიოში. ბრწყინვალებისკენ სწრაფვა ხდის Espressif-ის თითოეულ პროდუქტს დიდ დარტყმას ინტეგრაციის მაღალი დონით და ხარჯების ეფექტურობით. ESP32-C3-ის გამოშვება წარმოადგენს Espressif-ის თვითგანვითარებული ტექნოლოგიის მნიშვნელოვან ეტაპს. ეს არის ერთბირთვიანი, 32-ბიტიანი, RISC-V-ზე დაფუძნებული MCU 400KB SRAM-ით, რომელსაც შეუძლია იმუშაოს 160MHz-ზე. მას აქვს ინტეგრირებული 2.4 გჰც Wi-Fi და Bluetooth 5 (LE) გრძელვადიანი მხარდაჭერით. ის უზრუნველყოფს ძალაუფლების კარგ ბალანსს, I/O შესაძლებლობებს და უსაფრთხოებას, რითაც გთავაზობთ ოპტიმალურ ეკონომიურ გადაწყვეტას დაკავშირებული მოწყობილობებისთვის. ასეთ მძლავრ ESP32-C3-ზე დაფუძნებული, ეს წიგნი მიზნად ისახავს მკითხველს დაეხმაროს IoT-თან დაკავშირებული ცოდნის გააზრებაში დეტალური ილუსტრაციებით და პრაქტიკული გამოცდილებით.amples.
რატომ დავწერეთ ეს წიგნი?
Espressif Systems უფრო მეტია, ვიდრე ნახევარგამტარული კომპანია. ის ასევე არის IoT პლატფორმის კომპანია, რომელიც ყოველთვის მიისწრაფვის მიღწევებისა და ინოვაციებისკენ ტექნოლოგიების სფეროში. ამავდროულად, Espressif-მა გახსნა და გაუზიარა საზოგადოებას თავისი თვითგანვითარებული ოპერაციული სისტემა და პროგრამული უზრუნველყოფის ჩარჩო, რაც ქმნის უნიკალურ ეკოსისტემას. ინჟინრები, მწარმოებლები და ტექნოლოგიების ენთუზიასტები აქტიურად ავითარებენ ახალ პროგრამულ აპლიკაციებს Espressif-ის პროდუქტებზე დაყრდნობით, თავისუფლად ურთიერთობენ და უზიარებენ გამოცდილებას. თქვენ ყოველთვის შეგიძლიათ ნახოთ დეველოპერების მომხიბლავი იდეები სხვადასხვა პლატფორმებზე, როგორიცაა YouTube და GitHub. Espressif-ის პროდუქციის პოპულარობამ გამოიწვია მზარდი ავტორების სტიმული, რომლებმაც შექმნეს 100-ზე მეტი წიგნი Espressif-ის ჩიპსეტებზე დაყრდნობით, ათზე მეტ ენაზე, მათ შორის ინგლისურ, ჩინურ, გერმანულ, ფრანგულ და იაპონურ ენაზე.

ეს არის საზოგადოების პარტნიორების მხარდაჭერა და ნდობა, რაც ხელს უწყობს Espressif-ის უწყვეტ ინოვაციებს. „ჩვენ ვცდილობთ გავხადოთ ჩვენი ჩიპები, ოპერაციული სისტემები, ჩარჩოები, გადაწყვეტილებები, Cloud, ბიზნეს პრაქტიკა, ინსტრუმენტები, დოკუმენტაცია, ნაწერები, იდეები და ა.შ. ეს არის Espressif-ის უმაღლესი ამბიცია და მორალური კომპასი“. განაცხადა ბატონმა ტეო სვი ენმა, 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-ის მიერ და დაწერილია კომპანიის უფროსი ინჟინრების მიერ. ის შესაფერისია მენეჯერებისა და R&D პერსონალისთვის IoT-თან დაკავშირებულ ინდუსტრიებში, მასწავლებლებისა და სტუდენტებისთვის დაკავშირებული სპეციალობების და ენთუზიასტებისთვის ნივთების ინტერნეტის სფეროში. ვიმედოვნებთ, რომ ეს წიგნი შეიძლება გახდეს სამუშაო სახელმძღვანელო, ცნობარი და საწოლის წიგნაკი, რომ იყოს კარგი დამრიგებელი და მეგობარი.
ამ წიგნის შედგენისას ჩვენ მივმართეთ ექსპერტების, მეცნიერებისა და ტექნიკოსების რამდენიმე შესაბამის კვლევის შედეგებს სახლში და მის ფარგლებს გარეთ და ყველაფერი გავაკეთეთ, რომ ისინი აკადემიური ნორმების მიხედვით მოვიყვანეთ. თუმცა, გარდაუვალია გარკვეული ხარვეზები, ამიტომ აქ გვინდა გამოვხატოთ ჩვენი ღრმა პატივისცემა და მადლობა ყველა შესაბამის ავტორს. გარდა ამისა, ჩვენ მოვიყვანეთ ინფორმაცია ინტერნეტიდან, ამიტომ გვინდა მადლობა გადავუხადოთ თავდაპირველ ავტორებს და გამომცემლებს და ბოდიში მოვუხადოთ, რომ ვერ მივუთითებთ ყოველი ინფორმაციის წყაროს.
მაღალი ხარისხის წიგნის შესაქმნელად, ჩვენ მოვაწყეთ შიდა დისკუსიების რაუნდები და ვისწავლეთ საცდელი მკითხველებისა და გამომცემლების რედაქტორების წინადადებები და გამოხმაურებები. აქ, კიდევ ერთხელ გვინდა მადლობა გადაგიხადოთ თქვენი დახმარებისთვის, რომელიც ყველამ წვლილი შეიტანა ამ წარმატებულ საქმიანობაში.
ბოლო, მაგრამ რაც მთავარია, მადლობა ყველას Espressif-ში, ვინც ამდენი იშრომა ჩვენი პროდუქციის დაბადებისა და პოპულარიზაციისთვის.
IoT პროექტების განვითარება მოიცავს ცოდნის ფართო სპექტრს. წიგნის ხანგრძლივობით, ასევე ავტორის დონით და გამოცდილებით შემოიფარგლება, გამოტოვება გარდაუვალია. ამიტომ, გთხოვთ, ექსპერტებმა და მკითხველებმა გააკრიტიკონ და გამოასწორონ ჩვენი შეცდომები. თუ თქვენ გაქვთ რაიმე შემოთავაზება ამ წიგნთან დაკავშირებით, გთხოვთ დაგვიკავშირდეთ book@espressif.com. ჩვენ მოუთმენლად ველით თქვენს გამოხმაურებას.

როგორ გამოვიყენოთ ეს წიგნი?
ამ წიგნში მოცემული პროექტების კოდი ღია წყაროა. შეგიძლიათ გადმოწეროთ ჩვენი GitHub საცავიდან და გააზიაროთ თქვენი აზრები და შეკითხვები ჩვენს ოფიციალურ ფორუმზე. GitHub: https://github.com/espressif/book-esp32c3-iot-projects ფორუმი: https://www.esp32.com/bookc3 მთელ წიგნში იქნება ხაზგასმული ნაწილები, როგორც ეს ნაჩვენებია ქვემოთ.
წყაროს კოდი ამ წიგნში ჩვენ ხაზს ვუსვამთ თეორიისა და პრაქტიკის ერთობლიობას და ამგვარად ვადგენთ პრაქტიკის განყოფილებას Smart Light პროექტის შესახებ თითქმის ყველა თავში. შესაბამისი ნაბიჯები და წყაროს გვერდი მონიშნული იქნება ორ სტრიქონს შორის, დაწყებული tag წყაროს კოდი.
შენიშვნა/რჩევები აქ შეგიძლიათ იპოვოთ კრიტიკული ინფორმაცია და შეხსენება თქვენი პროგრამის წარმატებით გამართვისთვის. ისინი მონიშნული იქნება ორ სქელ ხაზს შორის დაწყებული tag შენიშვნა ან რჩევები.
ამ წიგნში ბრძანებების უმეტესობა შესრულებულია Linux-ის ქვეშ, მოწოდებული სიმბოლო „$“. თუ ბრძანება მოითხოვს სუპერმომხმარებლის პრივილეგიებს შესასრულებლად, მოთხოვნა შეიცვლება "#"-ით. ბრძანების სტრიქონი Mac სისტემებზე არის "%", როგორც გამოიყენება განყოფილებაში 4.2.3 დაინსტალირება ESP-IDF Mac-ზე.
ამ წიგნის ძირითადი ტექსტი დაიბეჭდება ქარტიაში, ხოლო კოდი examples, კომპონენტები, ფუნქციები, ცვლადები, კოდი file სახელები, კოდების დირექტორიები და სტრიქონები იქნება Courier New-ში.
ბრძანებები ან ტექსტები, რომლებიც უნდა შეიყვანოს მომხმარებელმა, და ბრძანებები, რომლებიც შეიძლება შევიდეს ღილაკზე „Enter“ დაჭერით, დაიბეჭდება Courier New თამამად. ჟურნალები და კოდების ბლოკები წარმოდგენილი იქნება ღია ცისფერ უჯრებში.
Exampლე:
მეორე, გამოიყენეთ esp-idf/components/nvs flash/nvs დანაყოფი გენერატორი/nvs დანაყოფი gen.py NVS დანაყოფის ორობითი გენერირებისთვის. file განვითარების ჰოსტზე შემდეგი ბრძანებით:
$ python $IDF PATH/კომპონენტები/nvs flash/nvs დანაყოფი გენერატორი/nvs დანაყოფი gen.py –შეყვანის მასა prod.csv –გამომავალი მასა prod.bin –ზომა NVS PARTITION SIZE

თავი 1

შესავალი

რომ

IoT

მე-20 საუკუნის ბოლოს, კომპიუტერული ქსელებისა და საკომუნიკაციო ტექნოლოგიების ამაღლებასთან ერთად, ინტერნეტი სწრაფად გაერთიანდა ადამიანების ცხოვრებაში. როდესაც ინტერნეტ ტექნოლოგია აგრძელებს ზრდას, წარმოიშვა საგნების ინტერნეტის (IoT) იდეა. სიტყვასიტყვით, IoT ნიშნავს ინტერნეტს, სადაც ნივთები დაკავშირებულია. მიუხედავად იმისა, რომ ორიგინალური ინტერნეტი არღვევს სივრცისა და დროის საზღვრებს და ავიწროებს მანძილს „ადამიანსა და პიროვნებას“ შორის, IoT ხდის „ნივნებს“ მნიშვნელოვან მონაწილედ, აახლოებს „ადამიანებსა“ და „ნივთებს“. უახლოეს მომავალში, IoT გახდება საინფორმაციო ინდუსტრიის მამოძრავებელი ძალა.
მაშ, რა არის ნივთების ინტერნეტი?
ძნელია ზუსტად განსაზღვრო ნივთების ინტერნეტი, რადგან მისი მნიშვნელობა და ფარგლები მუდმივად ვითარდება. 1995 წელს ბილ გეითსმა პირველად წამოაყენა IoT-ის იდეა თავის წიგნში The Road Ahead. მარტივად რომ ვთქვათ, IoT საშუალებას აძლევს ობიექტებს გაცვალონ ინფორმაცია ერთმანეთთან ინტერნეტის საშუალებით. მისი საბოლოო მიზანია შექმნას "ინტერნეტი ყველაფრის". ეს არის IoT-ის ადრეული ინტერპრეტაცია, ისევე როგორც მომავალი ტექნოლოგიების ფანტაზია. ოცდაათი წლის შემდეგ, ეკონომიკისა და ტექნოლოგიების სწრაფ განვითარებასთან ერთად, ფანტაზია რეალობაში ხდება. ჭკვიანი მოწყობილობებიდან, ჭკვიანი სახლებიდან, ჭკვიანი ქალაქებიდან, მანქანების ინტერნეტიდან და ტარებადი მოწყობილობებიდან დაწყებული, IoT ტექნოლოგიებით მხარდაჭერილი „მეტავერსიით“, მუდმივად ჩნდება ახალი კონცეფციები. ამ თავში ჩვენ დავიწყებთ ნივთების ინტერნეტის არქიტექტურის ახსნას და შემდეგ წარმოგიდგენთ ყველაზე გავრცელებულ IoT აპლიკაციას, ჭკვიან სახლს, რათა დაგეხმაროთ IoT-ის მკაფიო გაგებაში.
1.1 IoT-ის არქიტექტურა
ნივთების ინტერნეტი მოიცავს მრავალ ტექნოლოგიას, რომლებსაც აქვთ განაცხადის განსხვავებული საჭიროებები და ფორმები სხვადასხვა ინდუსტრიაში. IoT-ის სტრუქტურის, ძირითადი ტექნოლოგიებისა და გამოყენების მახასიათებლების დასალაგებლად აუცილებელია ერთიანი არქიტექტურისა და სტანდარტული ტექნიკური სისტემის ჩამოყალიბება. ამ წიგნში IoT-ის არქიტექტურა უბრალოდ იყოფა ოთხ ფენად: აღქმის და კონტროლის ფენა, ქსელის ფენა, პლატფორმის ფენა და აპლიკაციის ფენა.
აღქმა და კონტროლის ფენა, როგორც IoT არქიტექტურის ყველაზე ძირითადი ელემენტი, აღქმა და კონტროლის ფენა არის IoT-ის ყოვლისმომცველი სენსორული რეალიზაციის საფუძველი. მისი მთავარი ფუნქციაა ინფორმაციის შეგროვება, იდენტიფიცირება და კონტროლი. იგი შედგება სხვადასხვა მოწყობილობებისაგან აღქმის უნარით,
3

იდენტიფიკაცია, კონტროლი და შესრულება და პასუხისმგებელია ისეთი მონაცემების მოძიებასა და ანალიზზე, როგორიცაა მასალის თვისებები, ქცევითი ტენდენციები და მოწყობილობის სტატუსი. ამ გზით, IoT იღებს რეალურ ფიზიკურ სამყაროს. გარდა ამისა, ფენას ასევე შეუძლია გააკონტროლოს მოწყობილობის სტატუსი.
ამ ფენის ყველაზე გავრცელებული მოწყობილობებია სხვადასხვა სენსორები, რომლებიც მნიშვნელოვან როლს ასრულებენ ინფორმაციის შეგროვებასა და იდენტიფიკაციაში. სენსორები ჰგავს ადამიანის სენსორულ ორგანოებს, როგორიცაა ფოტომგრძნობიარე სენსორები, რომლებიც უტოლდება მხედველობას, აკუსტიკური სენსორები სმენას, გაზის სენსორები ყნოსვისთვის და წნევისა და ტემპერატურისადმი მგრძნობიარე სენსორები შეხებისას. ყველა ამ „სენსორული ორგანოებით“ ობიექტები ხდებიან „ცოცხალი“ და შეუძლიათ ფიზიკური სამყაროს ინტელექტუალური აღქმა, ამოცნობა და მანიპულირება.
ქსელის ფენა ქსელის ფენის მთავარი ფუნქციაა ინფორმაციის გადაცემა, მათ შორის, აღქმისა და კონტროლის ფენიდან მიღებული მონაცემების მითითებულ სამიზნეზე, ასევე აპლიკაციის ფენიდან გაცემული ბრძანებები აღქმისა და კონტროლის ფენაში. ის ემსახურება როგორც მნიშვნელოვანი საკომუნიკაციო ხიდს, რომელიც აკავშირებს IoT სისტემის სხვადასხვა ფენებს. ნივთების ინტერნეტის ძირითადი მოდელის დასაყენებლად, ის მოიცავს ორ ნაბიჯს ობიექტების ქსელში ინტეგრაციისთვის: ინტერნეტში წვდომას და ინტერნეტის საშუალებით გადაცემას.
ინტერნეტ ინტერნეტთან წვდომა საშუალებას აძლევს ადამიანსა და ადამიანს შორის ურთიერთკავშირს, მაგრამ ვერ ახერხებს ნივთების დიდ ოჯახს. IoT-ის მოსვლამდე, ბევრი რამ არ იყო „ქსელური“. ტექნოლოგიის უწყვეტი განვითარების წყალობით, IoT ახერხებს ნივთების ინტერნეტთან დაკავშირებას, რითაც აცნობიერებს ურთიერთკავშირს „ადამიანებსა და ნივთებს“ და „ნივთებსა და ნივთებს“ შორის. ინტერნეტ კავშირის განხორციელების ორი საერთო გზა არსებობს: სადენიანი ქსელის წვდომა და უკაბელო ქსელის წვდომა.
სადენიანი ქსელის წვდომის მეთოდები მოიცავს Ethernet-ს, სერიულ კომუნიკაციას (მაგ., RS-232, RS-485) და USB-ს, ხოლო უკაბელო ქსელის წვდომა დამოკიდებულია უსადენო კომუნიკაციაზე, რომელიც შემდგომში შეიძლება დაიყოს მოკლე დიაპაზონის უსადენო კომუნიკაციად და შორ მანძილზე უსადენო კომუნიკაციად.
მოკლე დიაპაზონის უკაბელო კომუნიკაცია მოიცავს ZigBee, Bluetoothr, Wi-Fi, Near-Field Communication (NFC) და რადიო სიხშირის იდენტიფიკაციას (RFID). გრძელვადიანი უკაბელო კომუნიკაცია მოიცავს გაძლიერებულ აპარატის ტიპის კომუნიკაციას (eMTC), LoRa, ნივთების ვიწრო ზოლის ინტერნეტს (NB-IoT), 2G, 3G, 4G, 5G და ა.შ.
ინტერნეტით გადაცემა ინტერნეტში წვდომის სხვადასხვა მეთოდი იწვევს მონაცემთა შესაბამის ფიზიკურ გადაცემას. შემდეგი რამ არის გადაწყვიტოს რომელი საკომუნიკაციო პროტოკოლი გამოიყენოს მონაცემების გადასაცემად. ინტერნეტ ტერმინალებთან შედარებით, IoT ტერმინალების უმეტესობას ამჟამად ნაკლები აქვს
4 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

ხელმისაწვდომი რესურსები, როგორიცაა დამუშავების შესრულება, შენახვის მოცულობა, ქსელის სიჩქარე და ა.შ., ამიტომ აუცილებელია საკომუნიკაციო პროტოკოლის არჩევა, რომელიც ნაკლებ რესურსს დაიკავებს IoT აპლიკაციებში. არსებობს ორი საკომუნიკაციო პროტოკოლი, რომლებიც დღეს ფართოდ გამოიყენება: შეტყობინებების რიგის ტელემეტრიული ტრანსპორტი (MQTT) და შეზღუდული აპლიკაციის პროტოკოლი (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ე და ინტელექტუალური სtage, როგორც ნაჩვენებია სურათზე 1.2.
სურათი 1.2. განვითარების სtagჭკვიანი სახლის e 6 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

პირველი სtagე არის ჭკვიანი პროდუქტების შესახებ. ტრადიციული სახლებისგან განსხვავებით, ჭკვიან სახლებში, IoT მოწყობილობები იღებენ სიგნალებს სენსორებით და ქსელში არიან უკაბელო საკომუნიკაციო ტექნოლოგიების საშუალებით, როგორიცაა Wi-Fi, Bluetooth LE და ZigBee. მომხმარებლებს შეუძლიათ აკონტროლონ ჭკვიანი პროდუქტები სხვადასხვა გზით, როგორიცაა სმარტფონის აპლიკაციები, ხმოვანი ასისტენტები, ჭკვიანი დინამიკის კონტროლი და ა.შ.tage ფოკუსირებულია სცენის ურთიერთდაკავშირებაზე. ამ სtagე, დეველოპერები აღარ განიხილავენ ერთი ჭკვიანი პროდუქტის კონტროლს, არამედ ორი ან მეტი ჭკვიანი პროდუქტის ურთიერთდაკავშირებას, გარკვეულწილად ავტომატიზირებას და საბოლოოდ პერსონალური სცენის რეჟიმის ფორმირებას. მაგampასევე, როდესაც მომხმარებელი დააჭერს სცენის რეჟიმის ნებისმიერ ღილაკს, განათება, ფარდები და კონდიციონერები ავტომატურად მოერგება წინასწარ დაყენებულს. რა თქმა უნდა, არსებობს წინაპირობა, რომ კავშირის ლოგიკა ადვილად დაყენებული იყოს, მათ შორის ტრიგერის პირობები და შესრულების მოქმედებები. წარმოიდგინეთ, რომ კონდიცირების გათბობის რეჟიმი ამოქმედდება, როდესაც შიდა ტემპერატურა 10°C-ზე დაბლა ეცემა; რომ დილის 7 საათზე უკრავს მუსიკა მომხმარებლის გასაღვიძებლად, სმარტ ფარდები იხსნება და ბრინჯის გაზქურის ან პურის ტოსტერი სმარტ სოკეტიდან იწყება; როდესაც მომხმარებელი ადგება და რეცხვას დაასრულებს, საუზმე უკვე მიირთმევა, რათა სამსახურში წასვლა არ შეფერხდეს. რა მოსახერხებელი გახდა ჩვენი ცხოვრება! მესამე სtagე მიდის დაზვერვის სtagე. რაც უფრო მეტი ჭკვიანი სახლის მოწყობილობა იქნება წვდომა, ასევე იქნება გენერირებული მონაცემების ტიპები. ღრუბლოვანი გამოთვლების, დიდი მონაცემების და ხელოვნური ინტელექტის დახმარებით, თითქოს „ჭკვიანი ტვინი“ ჩადებულია ჭკვიან სახლებში, რომლებიც აღარ საჭიროებენ მომხმარებლისგან ხშირ ბრძანებებს. ისინი აგროვებენ მონაცემებს წინა ურთიერთქმედებიდან და სწავლობენ მომხმარებლის ქცევის შაბლონებს და პრეფერენციებს, რათა მოხდეს აქტივობების ავტომატიზაცია, მათ შორის გადაწყვეტილების მიღების რეკომენდაციების მიწოდება. ამჟამად, ყველაზე ჭკვიანი სახლები შემთხვევის ადგილზეა ურთიერთკავშირი stagე. ჭკვიანი პროდუქტების შეღწევადობის კოეფიციენტისა და ინტელექტის ზრდასთან ერთად, კომუნიკაციის პროტოკოლებს შორის არსებული ბარიერები მოიხსნება. სამომავლოდ ჭკვიანი სახლები ნამდვილად „ჭკვიანები“ გახდებიან, ისევე როგორც AI სისტემა Jarvis in Iron Man, რომელიც არამარტო ეხმარება მომხმარებელს სხვადასხვა მოწყობილობების მართვაში, ყოველდღიური საქმეების მართვაში, არამედ აქვს სუპერ გამოთვლითი ძალა და აზროვნების უნარი. ინტელექტუალურ სtagე, ადამიანი მიიღებს უკეთეს მომსახურებას როგორც რაოდენობით, ასევე ხარისხით.
თავი 1. IoT 7 შესავალი

8 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

თავი 2 IoT პროექტის შესავალი და პრაქტიკა
პირველ თავში ჩვენ გავაცანით IoT არქიტექტურა და აღქმისა და კონტროლის ფენის, ქსელის ფენის, პლატფორმის ფენის და აპლიკაციის ფენის როლები და ურთიერთკავშირი, ასევე ჭკვიანი სახლის განვითარება. თუმცა, ისევე, როგორც როცა ვსწავლობთ ხატვას, თეორიული ცოდნის ცოდნა შორს არის საკმარისი. ჩვენ უნდა „დავიბინძუროთ“ IoT პროექტების პრაქტიკაში განსახორციელებლად, რათა ჭეშმარიტად დავეუფლოთ ტექნოლოგიას. გარდა ამისა, როდესაც პროექტი გადადის მასობრივ წარმოებაზე სtagე, აუცილებელია გავითვალისწინოთ მეტი ფაქტორი, როგორიცაა ქსელის კავშირი, კონფიგურაცია, IoT ღრუბლოვანი პლატფორმის ურთიერთქმედება, პროგრამული უზრუნველყოფის მენეჯმენტი და განახლებები, მასობრივი წარმოების მენეჯმენტი და უსაფრთხოების კონფიგურაცია. მაშ, რას უნდა მივაქციოთ ყურადღება სრული IoT პროექტის შემუშავებისას? პირველ თავში აღვნიშნეთ, რომ ჭკვიანი სახლი არის IoT აპლიკაციების ერთ-ერთი ყველაზე გავრცელებული სცენარი, ხოლო ჭკვიანი განათება არის ერთ-ერთი ყველაზე ძირითადი და პრაქტიკული მოწყობილობა, რომლის გამოყენება შესაძლებელია სახლებში, სასტუმროებში, სპორტდარბაზებში, საავადმყოფოებში და ა.შ. ამ წიგნში ჩვენ ავიღებთ გონივრული სინათლის პროექტის მშენებლობას, როგორც ამოსავალ წერტილს, ავხსნით მის კომპონენტებსა და მახასიათებლებს და მივცემთ მითითებებს პროექტის განვითარების შესახებ. ვიმედოვნებთ, რომ თქვენ შეძლებთ დასკვნის გამოტანას ამ შემთხვევიდან მეტი IoT აპლიკაციის შესაქმნელად.
2.1 ტიპიური IoT პროექტების შესავალი
განვითარების თვალსაზრისით, IoT პროექტების ძირითადი ფუნქციონალური მოდულები შეიძლება კლასიფიცირდეს IoT მოწყობილობების პროგრამული უზრუნველყოფისა და ტექნიკის განვითარებად, კლიენტის აპლიკაციების შემუშავებად და IoT ღრუბლოვანი პლატფორმის განვითარებად. მნიშვნელოვანია ძირითადი ფუნქციური მოდულების გარკვევა, რომლებიც შემდგომში იქნება აღწერილი ამ ნაწილში.
2.1.1 ძირითადი მოდულები საერთო IoT მოწყობილობებისთვის
IoT მოწყობილობების პროგრამული და ტექნიკის განვითარება მოიცავს შემდეგ ძირითად მოდულებს: მონაცემთა შეგროვება
როგორც IoT არქიტექტურის ქვედა ფენა, აღქმისა და კონტროლის ფენის IoT მოწყობილობები აკავშირებენ სენსორებსა და მოწყობილობებს მათი ჩიპებისა და პერიფერიული მოწყობილობების მეშვეობით, რათა მიაღწიონ მონაცემთა შეგროვებას და ოპერაციულ კონტროლს.
9

ანგარიშის დაკავშირება და საწყისი კონფიგურაცია IoT მოწყობილობების უმეტესობისთვის, ანგარიშის დაკავშირება და საწყისი კონფიგურაცია სრულდება ერთ ოპერაციულ პროცესში, მაგ.ample, მოწყობილობების მომხმარებლებთან დაკავშირება Wi-Fi ქსელის კონფიგურაციით.
ურთიერთქმედება IoT ღრუბლოვან პლატფორმებთან IoT მოწყობილობების მონიტორინგისა და კონტროლისთვის, ასევე აუცილებელია მათი დაკავშირება IoT ღრუბლოვან პლატფორმებთან, რათა ბრძანებები მივცეთ და მოახსენოთ სტატუსი ერთმანეთთან ურთიერთქმედების გზით.
მოწყობილობის კონტროლი IoT ღრუბლოვან პლატფორმებთან დაკავშირებისას მოწყობილობებს შეუძლიათ ღრუბელთან კომუნიკაცია და დარეგისტრირება, შეკვრა ან კონტროლი. მომხმარებლებს შეუძლიათ მოითხოვონ პროდუქტის სტატუსი და განახორციელონ სხვა ოპერაციები სმარტფონის აპლიკაციაში IoT ღრუბლოვანი პლატფორმების ან ადგილობრივი საკომუნიკაციო პროტოკოლების მეშვეობით.
პროგრამული უზრუნველყოფის განახლების IoT მოწყობილობებს ასევე შეუძლიათ მიაღწიონ პროგრამული უზრუნველყოფის განახლებას მწარმოებლების საჭიროებებზე დაყრდნობით. ღრუბლის მიერ გაგზავნილი ბრძანებების მიღებით განხორციელდება პროგრამული უზრუნველყოფის განახლება და ვერსიის მართვა. ამ პროგრამული უზრუნველყოფის განახლების ფუნქციით, შეგიძლიათ მუდმივად გააუმჯობესოთ IoT მოწყობილობების ფუნქციები, გამოასწოროთ დეფექტები და გააუმჯობესოთ მომხმარებლის გამოცდილება.
2.1.2 კლიენტის აპლიკაციების ძირითადი მოდულები
კლიენტის აპლიკაციები (მაგ., სმარტფონის აპლიკაციები) ძირითადად მოიცავს შემდეგ ძირითად მოდულებს:
ანგარიშის სისტემა და ავტორიზაცია ის მხარს უჭერს ანგარიშის და მოწყობილობის ავტორიზაციას.
მოწყობილობის კონტროლი სმარტფონის აპები ჩვეულებრივ აღჭურვილია საკონტროლო ფუნქციებით. მომხმარებლებს შეუძლიათ მარტივად დაუკავშირდნენ IoT მოწყობილობებს და მართონ ისინი ნებისმიერ დროს, ნებისმიერ ადგილას სმარტფონის აპლიკაციების საშუალებით. რეალურ სამყაროში ჭკვიან სახლში, მოწყობილობები ძირითადად კონტროლდება სმარტფონის აპლიკაციების საშუალებით, რაც არა მხოლოდ ხელს უწყობს მოწყობილობების ინტელექტუალურ მართვას, არამედ დაზოგავს სამუშაო ძალის ხარჯებს. ამიტომ, მოწყობილობის კონტროლი აუცილებელია კლიენტის აპლიკაციებისთვის, როგორიცაა მოწყობილობის ფუნქციის ატრიბუტების კონტროლი, სცენის კონტროლი, დაგეგმვა, დისტანციური მართვა, მოწყობილობის დაკავშირება და ა.შ. ჭკვიანი სახლის მომხმარებლებს ასევე შეუძლიათ სცენების მორგება პირადი საჭიროებების მიხედვით, განათების კონტროლი, საყოფაცხოვრებო ტექნიკა, შესასვლელი. და ა.შ., რათა სახლის ცხოვრება უფრო კომფორტული და მოსახერხებელი გახდეს. მათ შეუძლიათ კონდიცირების დრო, დისტანციურად გამორთვა, კარიბჭის გახსნის შემდეგ დერეფნის განათების ავტომატურად ჩართვა ან ერთი ღილაკით გადართვა „თეატრის“ რეჟიმში.
შეტყობინებების კლიენტის აპლიკაციები აახლებს IoT მოწყობილობების რეალურ დროში სტატუსს და აგზავნის გაფრთხილებებს, როდესაც მოწყობილობები არანორმალური ხდება.
10 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი 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 და Webსოკეტი, არამედ მოწყობილობის უსაფრთხოების ავთენტიფიკაციის ფუნქცია ყალბი და უკანონო მოწყობილობების დაბლოკვის მიზნით, რაც ეფექტურად ამცირებს კომპრომეტირების რისკს. ასეთი ავთენტიფიკაცია ჩვეულებრივ მხარს უჭერს სხვადასხვა მექანიზმებს, ამიტომ მოწყობილობების მასობრივი წარმოებისას აუცილებელია მოწყობილობის სერტიფიკატის წინასწარ მინიჭება შერჩეული ავთენტიფიკაციის მექანიზმის მიხედვით და ჩაწეროთ მოწყობილობებში.
მოწყობილობის მენეჯმენტი IoT ღრუბლოვანი პლატფორმების მიერ მოწოდებული მოწყობილობის მართვის ფუნქცია არა მხოლოდ ეხმარება მწარმოებლებს რეალურ დროში აკონტროლონ აქტივაციის სტატუსი და მათი მოწყობილობების ონლაინ სტატუსი, არამედ ასევე საშუალებას აძლევს ისეთი ვარიანტებს, როგორიცაა მოწყობილობების დამატება/წაშლა, მოძიება, ჯგუფების დამატება/წაშლა, პროგრამული უზრუნველყოფის განახლება. და ვერსიის მართვა.
მოწყობილობის ჩრდილოვანი IoT ღრუბლოვან პლატფორმებს შეუძლიათ შექმნან მუდმივი ვირტუალური ვერსია (მოწყობილობის ჩრდილი) თითოეული მოწყობილობისთვის, ხოლო მოწყობილობის ჩრდილის სტატუსის სინქრონიზაცია და მიღება შესაძლებელია სმარტფონის აპლიკაციის ან სხვა მოწყობილობების მიერ ინტერნეტის გადაცემის პროტოკოლების მეშვეობით. მოწყობილობის ჩრდილი ინახავს თითოეული მოწყობილობის უახლეს მოხსენებულ სტატუსს და მოსალოდნელ სტატუსს და მაშინაც კი, თუ მოწყობილობა ხაზგარეშეა, მას მაინც შეუძლია სტატუსის მიღება API-ებზე დარეკვით. Device shadow უზრუნველყოფს ყოველთვის ჩართულ API-ებს, რაც აადვილებს სმარტფონის აპების შექმნას, რომლებიც ურთიერთქმედებენ მოწყობილობებთან.
ექსპლუატაცია და ტექნიკური მომსახურება O&M ფუნქცია მოიცავს სამ ასპექტს: · სტატისტიკური ინფორმაციის დემონსტრირება IoT მოწყობილობებისა და შეტყობინებების შესახებ. · ჟურნალის მენეჯმენტი იძლევა ინფორმაციის მოძიებას მოწყობილობის ქცევის, შეტყობინებების ზევით/ქვევით ნაკადის და შეტყობინების შინაარსის შესახებ. · მოწყობილობის გამართვა მხარს უჭერს ბრძანებების მიწოდებას, კონფიგურაციის განახლებას და IoT ღრუბლოვან პლატფორმებსა და მოწყობილობის შეტყობინებებს შორის ურთიერთქმედების შემოწმებას.
2.2 პრაქტიკა: Smart Light Project
თითოეულ თავში თეორიული შესავლის შემდეგ, თქვენ იხილავთ პრაქტიკულ განყოფილებას, რომელიც დაკავშირებულია Smart Light პროექტთან, რომელიც დაგეხმარებათ მიიღოთ პრაქტიკული გამოცდილება. პროექტი დაფუძნებულია Espressif-ის ESP32-C3 ჩიპზე და ESP RainMaker IoT Cloud პლატფორმაზე და მოიცავს უკაბელო მოდულის აპარატურას ჭკვიანი სინათლის პროდუქტებში, ჩაშენებულ პროგრამულ უზრუნველყოფას ჭკვიანი მოწყობილობებისთვის ESP32C3-ზე დაფუძნებული, სმარტფონის აპლიკაციებსა და ESP RainMaker-ის ინტერაქციაზე.
წყაროს კოდი უკეთესი სწავლისა და გამოცდილების განვითარებისთვის, ამ წიგნში მოცემული პროექტი ღია წყაროებით იქნა შემუშავებული. შეგიძლიათ ჩამოტვირთოთ წყაროს კოდი ჩვენი GitHub საცავიდან https://github. com/espressif/book-esp32c3-iot-projects.
12 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

2.2.1 პროექტის სტრუქტურა
Smart Light პროექტი სამი ნაწილისგან შედგება: ი. ჭკვიანი განათების მოწყობილობები ESP32-C3-ზე დაფუძნებული, რომლებიც პასუხისმგებელნი არიან IoT ღრუბლოვან პლატფორმებთან ურთიერთობისთვის და LED l-ის გადამრთველის, სიკაშკაშისა და ფერის ტემპერატურის კონტროლზე.amp მძივები. ii. სმარტფონის აპლიკაციები (მათ შორის, ტაბლეტის აპლიკაციები, რომლებიც მუშაობს Android-ზე და iOS-ზე), პასუხისმგებელია ჭკვიანი სინათლის პროდუქტების ქსელის კონფიგურაციაზე, ასევე მათი სტატუსის მოთხოვნისა და კონტროლისთვის.
iii. IoT ღრუბლოვანი პლატფორმა, რომელიც დაფუძნებულია ESP RainMaker-ზე. გამარტივებისთვის, ამ წიგნში განვიხილავთ IoT ღრუბლოვან პლატფორმას და ბიზნეს სერვერს მთლიანობაში. ESP RainMaker-ის შესახებ დეტალები მოცემულია მე-3 თავში.
კორესპონდენცია Smart Light პროექტის სტრუქტურასა და IoT-ის არქიტექტურას შორის ნაჩვენებია სურათზე 2.1.
სურათი 2.1. ჭკვიანი სინათლის პროექტის სტრუქტურა
2.2.2 პროექტის ფუნქციები
სტრუქტურის მიხედვით იყოფა, თითოეული ნაწილის ფუნქციები შემდეგია. ჭკვიანი განათების მოწყობილობები
· ქსელის კონფიგურაცია და კავშირი. · LED PWM კონტროლი, როგორიცაა შეცვლა, სიკაშკაშე, ფერის ტემპერატურა და ა.შ. · ავტომატიზაცია ან სცენის კონტროლი, მაგ., დროის შეცვლა. · Flash-ის დაშიფვრა და უსაფრთხო ჩატვირთვა. · პროგრამული უზრუნველყოფის განახლება და ვერსიის მართვა.
თავი 2. IoT პროექტების შესავალი და პრაქტიკა 13

სმარტფონის აპლიკაციები · ქსელის კონფიგურაცია და მოწყობილობის დაკავშირება. · ჭკვიანი სინათლის პროდუქტის კონტროლი, როგორიცაა შეცვლა, სიკაშკაშე, ფერის ტემპერატურა და ა.შ. · ავტომატიზაცია ან სცენის პარამეტრები, მაგ., დროის შეცვლა. · ლოკალური/დისტანციური მართვა. · მომხმარებლის რეგისტრაცია, შესვლა და ა.შ.
ESP RainMaker IoT ღრუბლოვანი პლატფორმა · IoT მოწყობილობაზე წვდომის ჩართვა. · მოწყობილობის ოპერაციული API-ების უზრუნველყოფა, რომლებიც ხელმისაწვდომია სმარტფონის აპებისთვის. · პროგრამული უზრუნველყოფის განახლება და ვერსიის მართვა.
2.2.3 აპარატურის მომზადება
თუ დაინტერესებული ხართ პროექტის პრაქტიკაში განხორციელებაში, ასევე დაგჭირდებათ შემდეგი აპარატურა: ჭკვიანი განათება, სმარტფონები, Wi-Fi მარშრუტიზატორები და კომპიუტერი, რომელიც აკმაყოფილებს განვითარების გარემოს ინსტალაციის მოთხოვნებს. ჭკვიანი ნათურები
ჭკვიანი ნათურები არის ახალი ტიპის ნათურები, რომელთა ფორმა იგივეა, რაც ზოგადი ინკანდესენტური ნათურა. ჭკვიანი ნათურა შედგება კონდენსატორის დაქვეითების რეგულირებადი კვების წყაროსგან, უკაბელო მოდულისგან (ჩაშენებული ESP32-C3), LED კონტროლერისგან და RGB LED მატრიცისგან. დენის ჩართვისას, 15 V DC voltagკონდენსატორის დაწევის, დიოდის გასწორების და რეგულირების შემდეგ გამომავალი ენერგია უზრუნველყოფს LED კონტროლერს და LED მატრიცას. LED კონტროლერს შეუძლია ავტომატურად გააგზავნოს მაღალი და დაბალი დონეები გარკვეული ინტერვალებით, გადართოს RGB LED მატრიცა დახურულ (ნათურები) და ღია (განათება გამორთული) შორის, ისე რომ მას შეუძლია ასხივოს ცისფერი, ყვითელი, მწვანე, მეწამული, ლურჯი, წითელი და თეთრი ნათება. უკაბელო მოდული პასუხისმგებელია Wi-Fi როუტერთან დაკავშირებაზე, ჭკვიანი განათების სტატუსის მიღებასა და მოხსენებაზე და LED-ის სამართავად ბრძანებების გაგზავნაზე.
სურათი 2.2. სიმულირებული ჭკვიანი შუქი
ადრეულ განვითარებაში სtagე, შეგიძლიათ ჭკვიანი განათების სიმულაცია ESP32-C3DevKitM-1 დაფის გამოყენებით, რომელიც დაკავშირებულია RGB LED l-თანamp მძივები (იხ. სურათი 2.2). მაგრამ თქვენ უნდა
14 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

გაითვალისწინეთ, რომ ეს არ არის გონიერი განათების აწყობის ერთადერთი გზა. ამ წიგნში პროექტის ტექნიკის დიზაინი შეიცავს მხოლოდ უკაბელო მოდულს (ჩაშენებული ESP32-C3), მაგრამ არა სრულ ჭკვიანი მსუბუქი აპარატურის დიზაინს. გარდა ამისა, Espressif ასევე აწარმოებს ESP32-C3-ზე დაფუძნებული აუდიო განვითარების დაფას ESP32C3-Lyra აუდიო განათების მართვისთვის. დაფას აქვს მიკროფონებისა და დინამიკების ინტერფეისი და შეუძლია LED ზოლების მართვა. მისი გამოყენება შესაძლებელია ულტრა დაბალფასიანი, მაღალი ხარისხის აუდიო მაუწყებლების და რიტმული სინათლის ზოლების შესაქმნელად. სურათი 2.3 გვიჩვენებს ESP32-C3Lyra დაფას, რომელიც დაკავშირებულია 40 LED განათების ზოლთან.
სურათი 2.3. ESP32-C3-Lyra დაკავშირებულია 40 LED განათების ზოლით
სმარტფონები (Android/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-თან. Espressif-ის ESP32-C3 ჩიპი მხარს უჭერს IEEE 802.11b/g/n, ასე რომ თქვენ შეგიძლიათ აირჩიოთ ერთზოლიანი (2.4 გჰც) ან ორბანიანი (2.4 გჰც და 5 გჰც) Wi-Fi როუტერი.
კომპიუტერის (Linux/macOS/Windows) განვითარების გარემო დაინერგება მე-4 თავში. თავი 2. IoT პროექტების შესავალი და პრაქტიკა 15

2.2.4 განვითარების პროცესი
სურათი 2.4. Smart Light პროექტის შემუშავების ნაბიჯები
ტექნიკის დიზაინი IoT მოწყობილობების აპარატურის დიზაინი აუცილებელია IoT პროექტისთვის. სრული ჭკვიანი განათების პროექტი გამიზნულია ალamp მუშაობს ქსელის მიწოდების ქვეშ. სხვადასხვა მწარმოებელი აწარმოებს ლampსხვადასხვა სტილის და დრაივერების ტიპები, მაგრამ მათი უკაბელო მოდულები, როგორც წესი, იგივე ფუნქციის მქონეა. Smart Ligh პროექტის განვითარების პროცესის გასამარტივებლად, ეს წიგნი მხოლოდ უკაბელო მოდულების ტექნიკის დიზაინსა და პროგრამული უზრუნველყოფის შემუშავებას მოიცავს.
IoT ღრუბლოვანი პლატფორმის კონფიგურაცია IoT ღრუბლოვანი პლატფორმების გამოსაყენებლად, თქვენ უნდა დააკონფიგურიროთ პროექტები backend-ზე, როგორიცაა პროდუქტების შექმნა, მოწყობილობების შექმნა, მოწყობილობის თვისებების დაყენება და ა.შ.
ჩაშენებული პროგრამული უზრუნველყოფის შემუშავება IoT მოწყობილობებისთვის. განახორციელეთ მოსალოდნელი ფუნქციები ESP-IDF-ით, Espressif-ის მოწყობილობის მხარეს SDK-ით, მათ შორის IoT ღრუბლოვან პლატფორმებთან დაკავშირება, LED დრაივერების შემუშავება და პროგრამული უზრუნველყოფის განახლება.
სმარტფონის აპლიკაციების შემუშავება შეიმუშავეთ სმარტფონის აპლიკაციები Android და iOS სისტემებისთვის, რათა განხორციელდეს მომხმარებლის რეგისტრაცია და შესვლა, მოწყობილობის კონტროლი და სხვა ფუნქციები.
IoT მოწყობილობის ოპტიმიზაცია IoT მოწყობილობის ფუნქციების ძირითადი განვითარების დასრულების შემდეგ, შეგიძლიათ მიმართოთ ოპტიმიზაციის ამოცანებს, როგორიცაა ენერგიის ოპტიმიზაცია.
მასობრივი წარმოების ტესტირება ჩაატარეთ მასობრივი წარმოების ტესტები შესაბამისი სტანდარტების მიხედვით, როგორიცაა აღჭურვილობის ფუნქციური ტესტი, დაბერების ტესტი, RF ტესტი და ა.შ.
მიუხედავად ზემოთ ჩამოთვლილი ნაბიჯებისა, Smart Light პროექტი სულაც არ ექვემდებარება ასეთ პროცედურას, რადგან სხვადასხვა ამოცანების შესრულება შესაძლებელია ერთდროულად. მაგampპარალელურად შეიძლება განვითარდეს ჩაშენებული პროგრამული უზრუნველყოფა და სმარტფონის აპლიკაციები. ზოგიერთი ნაბიჯის გამეორებაც შეიძლება დაგჭირდეთ, როგორიცაა IoT მოწყობილობის ოპტიმიზაცია და მასობრივი წარმოების ტესტირება.
16 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

2.3 რეზიუმე
ამ თავში ჩვენ ჯერ განვიხილეთ IoT პროექტის ძირითადი კომპონენტები და ფუნქციური მოდულები, შემდეგ კი პრაქტიკისთვის წარმოვადგინეთ Smart Light შემთხვევა, რომელიც ეხება მის სტრუქტურას, ფუნქციებს, ტექნიკის მომზადებას და განვითარების პროცესს. მკითხველებს შეუძლიათ გამოიტანონ დასკვნები პრაქტიკიდან და გახდნენ დარწმუნებული, რომ მომავალში განახორციელებენ IoT პროექტებს მინიმალური შეცდომებით.
თავი 2. IoT პროექტების შესავალი და პრაქტიკა 17

18 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

თავი 3

შესავალი

რომ

ESP

წვიმის შემქმნელი

ნივთების ინტერნეტი (IoT) გთავაზობთ უსაზღვრო შესაძლებლობებს ადამიანების ცხოვრების წესის შესაცვლელად, თუმცა IoT ინჟინერიის განვითარება სავსეა გამოწვევებით. საჯარო ღრუბლებით, ტერმინალის მწარმოებლებს შეუძლიათ პროდუქტის ფუნქციონირების განხორციელება შემდეგი გადაწყვეტილებების საშუალებით:
გადაწყვეტილებების პროვაიდერების ღრუბლოვან პლატფორმებზე დაყრდნობით ამ გზით, ტერმინალის მწარმოებლებს მხოლოდ პროდუქტის აპარატურის დიზაინი სჭირდებათ, შემდეგ აპარატურა ღრუბელთან დაკავშირება მოწოდებული საკომუნიკაციო მოდულის გამოყენებით და პროდუქტის ფუნქციების კონფიგურაცია გაიდლაინების შესაბამისად. ეს არის ეფექტური მიდგომა, რადგან ის გამორიცხავს სერვერის და აპლიკაციის მხარეს განვითარებისა და ოპერაციებისა და ტექნიკური მომსახურების (O&M) საჭიროებას. ეს საშუალებას აძლევს ტერმინალის მწარმოებლებს ფოკუსირება მოახდინონ ტექნიკის დიზაინზე ღრუბლის განხორციელების განხილვის გარეშე. თუმცა, ასეთი გადაწყვეტილებები (მაგ., მოწყობილობის პროგრამული უზრუნველყოფა და აპლიკაცია) ზოგადად არ არის ღია წყარო, ამიტომ პროდუქტის ფუნქციები შეზღუდული იქნება პროვაიდერის ღრუბლოვანი პლატფორმით, რომლის მორგება შეუძლებელია. იმავდროულად, მომხმარებლის და მოწყობილობის მონაცემები ასევე ეკუთვნის ღრუბლოვან პლატფორმას.
ღრუბლოვანი პროდუქტების საფუძველზე ამ გადაწყვეტაში, ტექნიკის დიზაინის დასრულების შემდეგ, ტერმინალის მწარმოებლებმა არა მხოლოდ უნდა განახორციელონ ღრუბლოვანი ფუნქციები საჯარო ღრუბლის მიერ მოწოდებული ერთი ან მეტი ღრუბლოვანი პროდუქტის გამოყენებით, არამედ უნდა დააკავშირონ აპარატურა ღრუბელთან. მაგample, ამაზონთან დასაკავშირებლად Web სერვისები (AWS), ტერმინალის მწარმოებლებმა უნდა გამოიყენონ AWS პროდუქტები, როგორიცაა Amazon API Gateway, AWS IoT Core და AWS Lambda, რათა ჩართონ მოწყობილობაზე წვდომა, დისტანციური მართვა, მონაცემთა შენახვა, მომხმარებლის მართვა და სხვა ძირითადი ფუნქციები. ის არა მხოლოდ სთხოვს ტერმინალის მწარმოებლებს მოქნილად გამოიყენონ და დააკონფიგურირონ ღრუბლოვანი პროდუქტები სიღრმისეული გაგებით და მდიდარი გამოცდილებით, არამედ ასევე მოითხოვს მათგან გაითვალისწინონ მშენებლობისა და შენარჩუნების ღირებულება საწყისი და შემდგომი ს.tages ეს დიდ გამოწვევებს უქმნის კომპანიის ენერგიასა და რესურსებს.
საჯარო ღრუბლებთან შედარებით, კერძო ღრუბლები ჩვეულებრივ აგებულია კონკრეტული პროექტებისა და პროდუქტებისთვის. ღრუბლის კერძო დეველოპერებს ეძლევათ თავისუფლების უმაღლესი დონე პროტოკოლის დიზაინისა და ბიზნეს ლოგიკის განხორციელებაში. ტერმინალის მწარმოებლებს შეუძლიათ სურვილისამებრ შექმნან პროდუქტები და დიზაინის სქემები და ადვილად გააერთიანონ და გააძლიერონ მომხმარებლის მონაცემები. საჯარო ღრუბლის მაღალი უსაფრთხოების, მასშტაბურობისა და საიმედოობის გაერთიანება ადვანთანtagკერძო ღრუბლის წყალობით, Espressif-მა გამოუშვა ESP
19

RainMaker, ღრმად ინტეგრირებული კერძო ღრუბლოვანი გადაწყვეტა, რომელიც დაფუძნებულია Amazon ღრუბელზე. მომხმარებლებს შეუძლიათ განათავსონ ESP RainMaker და შექმნან პირადი ღრუბელი უბრალოდ AWS ანგარიშით.
3.1 რა არის ESP RainMaker?
ESP RainMaker არის სრული AIoT პლატფორმა, რომელიც აგებულია მრავალი ზრდასრული AWS პროდუქტით. ის უზრუნველყოფს მასიური წარმოებისთვის საჭირო სხვადასხვა სერვისებს, როგორიცაა მოწყობილობის ღრუბლოვანი წვდომა, მოწყობილობის განახლება, სარეზერვო მენეჯმენტი, მესამე მხარის შესვლა, ხმოვანი ინტეგრაცია და მომხმარებლის მართვა. AWS-ის მიერ მოწოდებული სერვერის აპლიკაციის საცავის (SAR) გამოყენებით, ტერმინალის მწარმოებლებს შეუძლიათ სწრაფად განათავსონ ESP RainMaker თავიანთ AWS ანგარიშებზე, რაც დროში ეფექტური და მარტივია. Espressif-ის მიერ მართული და შენარჩუნებული SAR, რომელსაც იყენებს ESP RainMaker, ეხმარება დეველოპერებს შეამცირონ ღრუბლის შენარჩუნების ხარჯები და დააჩქარონ AIoT პროდუქტების განვითარება, რითაც შექმნან უსაფრთხო, სტაბილური და რეგულირებადი AIoT გადაწყვეტილებები. სურათი 3.1 გვიჩვენებს ESP RainMaker-ის არქიტექტურას.
სურათი 3.1. ESP RainMaker-ის არქიტექტურა
ESP RainMaker-ის საჯარო სერვერი Espressif-ის მიერ უფასოა ყველა ESP ენთუზიასტისთვის, შემქმნელისთვის და მასწავლებლისთვის გადაწყვეტილების შეფასებისთვის. დეველოპერებს შეუძლიათ შევიდნენ Apple, Google ან GitHub ანგარიშებით და სწრაფად შექმნან საკუთარი IoT აპლიკაციის პროტოტიპები. საჯარო სერვერი აერთიანებს Alexa-სა და Google Home-ს და უზრუნველყოფს ხმის მართვის სერვისებს, რომლებსაც მხარს უჭერს Alexa Skill და Google Actions. მისი სემანტიკური ამოცნობის ფუნქცია ასევე უზრუნველყოფილია მესამე მხარის მიერ. RainMaker IoT მოწყობილობები პასუხობენ მხოლოდ კონკრეტულ ქმედებებს. მხარდაჭერილი ხმოვანი ბრძანებების ამომწურავი სიისთვის გთხოვთ, შეამოწმოთ მესამე მხარის პლატფორმები. გარდა ამისა, Espressif სთავაზობს მომხმარებლებს RainMaker App-ს, რათა აკონტროლონ პროდუქტები სმარტფონების საშუალებით. 20 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

3.2 ESP RainMaker-ის დანერგვა
როგორც ნახაზი 3.2-ზეა ნაჩვენები, ESP RainMaker შედგება ოთხი ნაწილისგან: · განაცხადის სერვისი, რომელიც საშუალებას აძლევს RainMaker მოწყობილობებს დინამიურად მიიღონ სერთიფიკატები. · RainMaker Cloud (ასევე ცნობილია, როგორც ღრუბელი უკანა ნაწილი), რომელიც უზრუნველყოფს სერვისებს, როგორიცაა შეტყობინებების გაფილტვრა, მომხმარებლის მართვა, მონაცემთა შენახვა და მესამე მხარის ინტეგრაცია. · RainMaker აგენტი, რომელიც საშუალებას აძლევს RainMaker მოწყობილობებს დაუკავშირდნენ RainMaker Cloud-ს. · RainMaker Client (RainMaker App ან CLI სკრიპტები), უზრუნველყოფის, მომხმარებლის შექმნის, მოწყობილობის ასოციაციისა და კონტროლისთვის და ა.შ.
სურათი 3.2. ESP RainMaker-ის სტრუქტურა
ESP RainMaker გთავაზობთ ინსტრუმენტების სრულ კომპლექტს პროდუქტის განვითარებისა და მასობრივი წარმოებისთვის, მათ შორის: RainMaker SDK
RainMaker SDK დაფუძნებულია ESP-IDF-ზე და უზრუნველყოფს მოწყობილობის გვერდითი აგენტის წყაროს კოდს და დაკავშირებულ C API-ებს პროგრამული უზრუნველყოფის განვითარებისთვის. დეველოპერებს მხოლოდ აპლიკაციის ლოგიკის დაწერა სჭირდებათ, დანარჩენი კი RainMaker-ის ფრეიმიკს მიატოვებენ. C API-ების შესახებ დამატებითი ინფორმაციისთვის ეწვიეთ https://bookc3.espressif.com/rm/c-api-reference. RainMaker App RainMaker App-ის საჯარო ვერსია საშუალებას აძლევს დეველოპერებს დაასრულონ მოწყობილობების უზრუნველყოფა და გააკონტროლონ და მოითხოვონ მოწყობილობების სტატუსი (მაგ., ჭკვიანი განათების პროდუქტები). ის ხელმისაწვდომია როგორც iOS, ასევე Android აპლიკაციების მაღაზიებში. დამატებითი ინფორმაციისთვის, გთხოვთ, იხილოთ თავი 10. REST APIs REST API-ები მომხმარებლებს ეხმარება შექმნან საკუთარი აპლიკაციები RainMaker აპლიკაციის მსგავსი. დამატებითი ინფორმაციისთვის ეწვიეთ https://swaggerapis.rainmaker.espressif.com/.
თავი 3. ESP RainMaker 21-ის შესავალი

Python API-ები Python-ზე დაფუძნებული CLI, რომელიც მოყვება RainMaker SDK-ს, მოწოდებულია სმარტფონის ფუნქციების მსგავსი ყველა ფუნქციის განსახორციელებლად. Python API-ების შესახებ დამატებითი ინფორმაციისთვის ეწვიეთ https://bookc3.espressif.com/rm/python-api-reference.
Admin CLI Admin CLI, წვდომის უფრო მაღალი დონით, უზრუნველყოფილია ESP RainMaker-ის პირადი განლაგებისთვის, რათა გამოიმუშაოს მოწყობილობის სერთიფიკატები ნაყარად.
3.2.1 მოთხოვნის სერვისი
ყველა კომუნიკაცია RainMaker მოწყობილობებსა და ღრუბლოვან ბაზას შორის ხორციელდება MQTT+TLS-ის საშუალებით. ESP RainMaker-ის კონტექსტში, „Claiming“ არის პროცესი, რომლის დროსაც მოწყობილობები იღებენ სერთიფიკატებს Claiming Service-ისგან ღრუბლოვან ბაზასთან დასაკავშირებლად. გაითვალისწინეთ, რომ Claiming Service გამოიყენება მხოლოდ RainMaker-ის საჯარო სერვისზე, ხოლო კერძო განლაგებისთვის, მოწყობილობის სერთიფიკატების გენერირება საჭიროა Admin CLI-ის მეშვეობით. ESP RainMaker მხარს უჭერს სამი სახის პრეტენზიის სერვისს: თვითმმართველობის პრეტენზია
მოწყობილობა თავად იღებს სერთიფიკატებს eFuse-ში წინასწარ დაპროგრამებული საიდუმლო გასაღების მეშვეობით ინტერნეტთან დაკავშირების შემდეგ. მასპინძელზე ორიენტირებული პრეტენზია სერთიფიკატები მიიღება განვითარების ჰოსტისგან RainMaker ანგარიშით. დამხმარე პრეტენზია სერთიფიკატები მიიღება სმარტფონის აპლიკაციების მეშვეობით უზრუნველყოფის დროს.
3.2.2 RainMaker აგენტი
სურათი 3.3. RainMaker SDK-ის სტრუქტურა RainMaker Agent-ის ძირითადი ფუნქციაა უზრუნველყოს კავშირი და დაეხმაროს აპლიკაციის ფენას ზედმიწევნით/ჩამომტვირთავი ღრუბლოვანი მონაცემების დამუშავებაში. ის აგებულია RainMaker SDK 22 ESP32-C3 Wireless Adventure-ის მეშვეობით: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

და შეიქმნა დადასტურებული ESP-IDF ჩარჩოს საფუძველზე, ESP-IDF კომპონენტების გამოყენებით, როგორიცაა RTOS, NVS და MQTT. სურათი 3.3 გვიჩვენებს RainMaker SDK-ის სტრუქტურას.
RainMaker SDK მოიცავს ორ ძირითად ფუნქციას.
კავშირი
მე. თანამშრომლობა Claiming Service-თან მოწყობილობის სერთიფიკატების მისაღებად.
ii. ღრუბლოვანი სისტემის დაკავშირება უსაფრთხო MQTT პროტოკოლის გამოყენებით დისტანციური კავშირის უზრუნველსაყოფად და დისტანციური მართვის, შეტყობინებების მოხსენების, მომხმარებლის მენეჯმენტის, მოწყობილობის მენეჯმენტის და ა.შ. ნაგულისხმევად იყენებს MQTT კომპონენტს ESP-IDF-ში და უზრუნველყოფს აბსტრაქციის ფენას სხვასთან ინტერფეისისთვის. პროტოკოლის სტეკები.
iii. Wi-Fi უზრუნველყოფის კომპონენტის უზრუნველყოფა Wi-Fi კავშირისა და უზრუნველყოფისთვის, esp https ota კომპონენტი OTA განახლებისთვის და esp ადგილობრივი ctrl კომპონენტი ადგილობრივი მოწყობილობის აღმოჩენისა და კავშირისთვის. ყველა ამ მიზნის მიღწევა შესაძლებელია მარტივი კონფიგურაციის საშუალებით.
მონაცემთა დამუშავება
მე. Claiming Service-ის მიერ გაცემული მოწყობილობის სერთიფიკატების და RainMaker-ის გაშვებისას საჭირო მონაცემების შენახვა, ნაგულისხმევად nvs flash კომპონენტის მიერ მოწოდებული ინტერფეისის გამოყენებით და დეველოპერებისთვის API-ების უზრუნველყოფა პირდაპირი გამოყენებისთვის.
ii. გამოძახების მექანიზმის გამოყენება ღრუბლოვანი მონაცემების ზემოქმედების/ჩამოტვირთვის დასამუშავებლად და აპლიკაციის ფენაზე მონაცემების ავტომატურად განბლოკვის მიზნით, დეველოპერების მიერ მარტივი დამუშავებისთვის. მაგampასევე, RainMaker SDK უზრუნველყოფს მდიდარ ინტერფეისებს TSL (Thing Specification Language) მონაცემების დასამყარებლად, რომლებიც საჭიროა TSL მოდელების განსაზღვრისთვის IoT მოწყობილობების აღსაწერად და ისეთი ფუნქციების განსახორციელებლად, როგორიცაა დრო, ათვლა და ხმის კონტროლი. ძირითადი ინტერაქტიული ფუნქციებისთვის, როგორიცაა დრო, RainMaker SDK უზრუნველყოფს განვითარების გარეშე გადაწყვეტას, რომელიც შეიძლება უბრალოდ ჩართოთ საჭიროების შემთხვევაში. შემდეგ, RainMaker აგენტი პირდაპირ დაამუშავებს მონაცემებს, გააგზავნის მას ღრუბელში ასოცირებული MQTT თემის საშუალებით და გამოაბრუნებს მონაცემთა ცვლილებებს ღრუბელში გამოძახების მექანიზმის მეშვეობით.
3.2.3 Cloud Backend
Cloud 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 (bucket შენახვის სერვისი). ის მიზნად ისახავს მასშტაბურობისა და უსაფრთხოების ოპტიმიზაციას. ESP RainMaker-ით დეველოპერებს შეუძლიათ მართონ მოწყობილობები ღრუბელში კოდის დაწერის გარეშე. მოწყობილობების მიერ მოხსენებული შეტყობინებები გამჭვირვალედ გადაეცემა
თავი 3. ESP RainMaker 23-ის შესავალი

აპლიკაციის კლიენტები ან სხვა მესამე მხარის სერვისები. ცხრილი 3.1 გვიჩვენებს AWS ღრუბლოვან პროდუქტებსა და ფუნქციებს, რომლებიც გამოიყენება ღრუბელში, მეტი პროდუქტითა და ფუნქციებით დამუშავების პროცესში.
ცხრილი 3.1. AWS ღრუბლოვანი პროდუქტები და ფუნქციები, რომლებიც გამოიყენება ღრუბლოვანი სისტემის მიერ

AWS Cloud პროდუქტი, რომელსაც იყენებს RainMaker

ფუნქცია

AWS Cognito

მომხმარებლის რწმუნებათა სიგელების მართვა და მესამე მხარის შესვლის მხარდაჭერა

AWS ლამბდა

Cloud backend-ის ძირითადი ბიზნეს ლოგიკის დანერგვა

Amazon Timestream დროის სერიების მონაცემების შენახვა

Amazon DynamoDB მომხმარებელთა პირადი ინფორმაციის შენახვა

AWS IoT Core

MQTT კომუნიკაციის მხარდაჭერა

Amazon SES

ელექტრონული ფოსტის გაგზავნის სერვისების მიწოდება

Amazon CloudFront აჩქარებს backend-ის მართვას webსაიტის წვდომა

Amazon SQS

შეტყობინებების გადამისამართება AWS IoT Core-დან

3.2.4 RainMaker კლიენტი
RainMaker-ის კლიენტები, როგორიცაა App და CLI, აკავშირებენ ღრუბლოვან ბაზასთან REST API-ების მეშვეობით. დეტალური ინფორმაცია და ინსტრუქციები REST API-ების შესახებ შეგიძლიათ იხილოთ Espressif-ის მიერ მოწოდებულ Swagger-ის დოკუმენტაციაში. RainMaker-ის მობილური აპლიკაციის კლიენტი ხელმისაწვდომია როგორც iOS, ასევე Android სისტემებისთვის. ის საშუალებას აძლევს მოწყობილობების უზრუნველყოფას, კონტროლს და გაზიარებას, ასევე შექმნას და ჩართოს უკუმთვლელი ამოცანები და დაუკავშირდეს მესამე მხარის პლატფორმებს. მას შეუძლია ავტომატურად იტვირთოს UI და ხატები მოწყობილობების მიერ მოხსენებული კონფიგურაციის მიხედვით და სრულად აჩვენოს მოწყობილობა TSL.
მაგampთუ გონიერი განათება აგებულია RainMaker SDK-ზე, რომელიც მოწოდებულია ყოფილიampსხვათა შორის, ნათურის შუქის ხატულა და ინტერფეისი ავტომატურად იტვირთება, როდესაც უზრუნველყოფა დასრულდება. მომხმარებლებს შეუძლიათ შეცვალონ განათების ფერი და სიკაშკაშე ინტერფეისის საშუალებით და მიაღწიონ მესამე მხარის კონტროლს Alexa Smart Home Skill-ის ან Google Smart Home Actions-ის დაკავშირებით მათ ESP RainMaker ანგარიშებთან. სურათი 3.4 გვიჩვენებს ხატულას და UI exampნათურის შუქი, შესაბამისად, Alexa-ზე, Google Home-ზე და ESP RainMaker App-ზე.

24 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

(ა) მაგampლე – ალექსა

(ბ) მაგample – Google Home

(გ) მაგample – ESP RainMaker
სურათი 3.4. გამampნათურის ნათურის ხატულა და ინტერფეისი Alexa-ზე, Google Home-ზე და ESP RainMaker აპზე
3.3 პრაქტიკა: ძირითადი პუნქტები ESP RainMaker-ის განვითარებისთვის
მოწყობილობის დრაივერის ფენის დასრულების შემდეგ, დეველოპერებმა შეიძლება დაიწყონ TSL მოდელების შექმნა და დაშვებული ბმულის მონაცემების დამუშავება RainMaker SDK-ის მიერ მოწოდებული API-ების გამოყენებით და ჩართონ ESP RainMaker ძირითადი სერვისები პროდუქტის განმარტებასა და მოთხოვნებზე დაყრდნობით.
თავი 3. ESP RainMaker 25-ის შესავალი

ამ წიგნის 9.4 ნაწილი განმარტავს RainMaker-ში LED ჭკვიანი განათების დანერგვას. გამართვის დროს, დეველოპერებს შეუძლიათ გამოიყენონ CLI ინსტრუმენტები RainMaker SDK-ში, რათა დაუკავშირდნენ ჭკვიან განათებას (ან გამოიძახონ REST API-ები Swagger-ისგან).
მე-10 თავი განიხილავს REST API-ების გამოყენებას სმარტფონების აპლიკაციების შემუშავებაში. LED ჭკვიანი განათების OTA განახლებები განხილული იქნება მე-11 თავში. თუ დეველოპერებმა ჩართოთ ESP Insights დისტანციური მონიტორინგი, ESP RainMaker-ის მენეჯმენტის ბექენდი აჩვენებს ESP Insights მონაცემებს. დეტალები წარმოდგენილი იქნება მე-15 თავში.
ESP RainMaker მხარს უჭერს კერძო განლაგებას, რომელიც განსხვავდება საჯარო RainMaker სერვერისგან შემდეგი გზებით:
მოთხოვნის სერვისი კერძო განლაგებაში სერთიფიკატების გენერირებისთვის საჭიროა RainMaker Admin CLI-ის გამოყენება Claiming-ის ნაცვლად. საჯარო სერვერთან ერთად, დეველოპერებს უნდა მიენიჭოთ ადმინისტრატორის უფლებები, რომ განახორციელონ firmware განახლებები, მაგრამ ეს არასასურველია კომერციულ განლაგებაში. აქედან გამომდინარე, არც ცალკე ავთენტიფიკაციის სერვისის მიწოდება შესაძლებელია თვითგანცხადებისთვის და არც ადმინისტრატორის უფლებები მასპინძელზე მართული ან დამხმარე პრეტენზიისთვის.
ტელეფონის აპლიკაციები კერძო განლაგებაში, აპლიკაციები უნდა იყოს კონფიგურირებული და ცალკე შედგენილი, რათა დარწმუნდეთ, რომ ანგარიშის სისტემები არ არის თავსებადი.
მესამე მხარის შესვლა და ხმოვანი ინტეგრაცია დეველოპერებმა ცალკე უნდა დააკონფიგურიროთ Google-ისა და Apple-ის დეველოპერის ანგარიშების მეშვეობით, რათა ჩართოთ მესამე მხარის შესვლა, ასევე Alexa Skill-ისა და Google Voice Assistant-ის ინტეგრაცია.
რჩევები ღრუბლის განლაგების შესახებ დეტალებისთვის ეწვიეთ https://customer.rainmaker.espressif. com. პროგრამული უზრუნველყოფის თვალსაზრისით, საჯარო სერვერიდან კერძო სერვერზე მიგრაცია მოითხოვს მხოლოდ მოწყობილობის სერთიფიკატების შეცვლას, რაც მნიშვნელოვნად აუმჯობესებს მიგრაციის ეფექტურობას და ამცირებს მიგრაციის და მეორადი გამართვის ღირებულებას.
3.4 ESP RainMaker-ის მახასიათებლები
ESP RainMaker ფუნქციები ძირითადად გამიზნულია სამ ასპექტზე - მომხმარებლის მენეჯმენტი, საბოლოო მომხმარებლები და ადმინისტრატორები. ყველა ფუნქცია მხარდაჭერილია როგორც საჯარო, ასევე კერძო სერვერებზე, თუ სხვა რამ არ არის მითითებული.
3.4.1 მომხმარებლის მენეჯმენტი
მომხმარებლის მართვის ფუნქციები საშუალებას აძლევს საბოლოო მომხმარებლებს დარეგისტრირდნენ, შეხვიდეთ სისტემაში, შეცვალონ პაროლები, მოიძიონ პაროლები და ა.შ.
26 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

რეგისტრაცია და შესვლა RainMaker-ის მიერ მხარდაჭერილი რეგისტრაციისა და შესვლის მეთოდები მოიცავს: · ელფოსტის ID + პაროლი · ტელეფონის ნომერი + პაროლი · Google ანგარიში · Apple ანგარიში · GitHub ანგარიში (მხოლოდ საჯარო სერვერი) · Amazon ანგარიში (მხოლოდ კერძო სერვერი)
შენიშვნა დარეგისტრირდით Google/Amazon-ის გამოყენებით, აზიარებს მომხმარებლის ელფოსტის მისამართს RainMaker-ს. დარეგისტრირდით Apple-ის გამოყენებით, იზიარებს მოტყუებულ მისამართს, რომელსაც Apple ანიჭებს მომხმარებელს სპეციალურად RainMaker სერვისისთვის. RainMaker ანგარიში ავტომატურად შეიქმნება მომხმარებლებისთვის, რომლებიც პირველად შედიან Google-ის, Apple-ის ან Amazon-ის ანგარიშზე.
პაროლის შეცვლა მოქმედებს მხოლოდ ელ.ფოსტის ID/ტელეფონის ნომერზე დაფუძნებული შესვლისთვის. პაროლის შეცვლის შემდეგ ყველა სხვა აქტიური სესია გამოვა. AWS Cognito ქცევის მიხედვით, სისტემაში გამოსული სესიები შეიძლება აქტიური დარჩეს 1 საათამდე.
პაროლის აღდგენა მოქმედებს მხოლოდ ელ.ფოსტის ID/ტელეფონის ნომერზე დაფუძნებული შესვლისთვის.
3.4.2 საბოლოო მომხმარებლის მახასიათებლები
საბოლოო მომხმარებლებისთვის ღია ფუნქციები მოიცავს ლოკალურ და დისტანციურ მართვას და მონიტორინგს, დაგეგმვას, მოწყობილობების დაჯგუფებას, მოწყობილობის გაზიარებას, push-შეტყობინებებს და მესამე მხარის ინტეგრაციას.
დისტანციური მართვა და მონიტორინგი · შეკითხვის კონფიგურაცია, პარამეტრების მნიშვნელობები და კავშირის სტატუსი ერთი ან ყველა მოწყობილობისთვის. · პარამეტრების დაყენება ერთი ან მრავალი მოწყობილობისთვის.
ლოკალური კონტროლი და მონიტორინგი მობილური ტელეფონი და მოწყობილობა ლოკალური კონტროლისთვის უნდა იყოს დაკავშირებული იმავე ქსელთან.
დაგეგმვა · მომხმარებლებმა წინასწარ დააყენეს გარკვეული მოქმედებები კონკრეტულ დროს. · გრაფიკის შესრულებისას მოწყობილობას ინტერნეტთან კავშირი არ სჭირდება. · ერთჯერადი ან გამეორება (დღების მითითებით) ერთი ან მრავალი მოწყობილობისთვის.
მოწყობილობების დაჯგუფების მხარდაჭერა მრავალ დონის აბსტრაქტული დაჯგუფების მხარდაჭერა ჯგუფის მეტამონაცემების გამოყენება შესაძლებელია სახლის ოთახის სტრუქტურის შესაქმნელად.
თავი 3. ESP RainMaker 27-ის შესავალი

მოწყობილობის გაზიარება ერთი ან მეტი მოწყობილობის გაზიარება შესაძლებელია ერთ ან მეტ მომხმარებელთან.
Push-შეტყობინებები საბოლოო მომხმარებლები მიიღებენ Push-შეტყობინებებს ისეთი მოვლენების შესახებ, როგორიცაა · დამატებული/წაშლილი ახალი მოწყობილობა(ებ)ი · ღრუბელთან დაკავშირებული მოწყობილობა · მოწყობილობა გათიშულია ღრუბელთან · მოწყობილობის გაზიარების მოთხოვნები შექმნილი/მიღებული/უარყოფილი · მოწყობილობების მიერ მოხსენებული გაფრთხილების შეტყობინებები
მესამე მხარის ინტეგრაციები Alexa და Google Voice Assistant მხარდაჭერილია RainMaker მოწყობილობების სამართავად, მათ შორის განათებები, კონცენტრატორები, სოკეტები, ვენტილატორები და ტემპერატურის სენსორები.
3.4.3 ადმინისტრატორის მახასიათებლები
ადმინისტრატორის ფუნქციები საშუალებას აძლევს ადმინისტრატორებს განახორციელონ მოწყობილობის რეგისტრაცია, მოწყობილობების დაჯგუფება და OTA განახლებები და view სტატისტიკა და ESP Insights მონაცემები.
მოწყობილობის რეგისტრაცია შექმენით მოწყობილობის სერთიფიკატები და დარეგისტრირდით Admin CLI-ზე (მხოლოდ კერძო სერვერზე).
მოწყობილობების დაჯგუფება შექმენით აბსტრაქტული ან სტრუქტურირებული ჯგუფები მოწყობილობის ინფორმაციის საფუძველზე (მხოლოდ პირადი სერვერი).
საჰაერო ხომალდის (OTA) განახლებები ატვირთეთ firmware ვერსიისა და მოდელის მიხედვით, ერთ ან მეტ მოწყობილობაზე ან ჯგუფურ მონიტორინგს, გაუქმებას ან დაარქივებს OTA სამუშაოებს.
View სტატისტიკა Viewუნარიანი სტატისტიკა მოიცავს: · მოწყობილობის რეგისტრაციას (ადმინისტრატორის მიერ დარეგისტრირებული სერთიფიკატები) · მოწყობილობის აქტივაცია (მოწყობილობა პირველად დაკავშირებულია) · მომხმარებლის ანგარიშები · მომხმარებლის მოწყობილობასთან ასოციაცია
View ESP Insights მონაცემები ViewESP Insights-ის მოქმედი მონაცემები მოიცავს: · შეცდომებს, გაფრთხილებებს და მორგებულ ჟურნალებს · ავარიის ანგარიშები და ანალიზი · გადატვირთვის მიზეზები · მეტრიკა, როგორიცაა მეხსიერების გამოყენება, RSSI და ა.შ. · მორგებული მეტრიკა და ცვლადები
28 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

3.5 რეზიუმე
ამ თავში ჩვენ წარმოვადგინეთ რამდენიმე ძირითადი განსხვავება RainMaker-ის საჯარო განლაგებასა და კერძო განლაგებას შორის. Espressif-ის მიერ გამოშვებული პირადი ESP RainMaker გადაწყვეტა არის უაღრესად საიმედო და გაფართოებადი. ESP32 სერიის ყველა ჩიპი დაკავშირებულია და ადაპტირებულია AWS-ზე, რაც მნიშვნელოვნად ამცირებს ღირებულებას. დეველოპერებს შეუძლიათ ფოკუსირება პროტოტიპის გადამოწმებაზე, AWS ღრუბლოვანი პროდუქტების გაცნობის გარეშე. ჩვენ ასევე ავუხსენით ESP RainMaker-ის იმპლემენტაცია და მახასიათებლები და რამდენიმე ძირითადი პუნქტი პლატფორმის გამოყენებით განვითარებისთვის.
სკანირება ჩამოტვირთეთ ESP RainMaker Android-ისთვის სკანირება ჩამოტვირთეთ ESP RainMaker iOS-ისთვის
თავი 3. ESP RainMaker 29-ის შესავალი

30 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

თავი დაყენება 4 განვითარების გარემო
ეს თავი ყურადღებას ამახვილებს ESP-IDF-ზე, ESP32-C3-ის პროგრამული უზრუნველყოფის განვითარების ოფიციალურ ჩარჩოზე. ჩვენ ავუხსნით, თუ როგორ დავაყენოთ გარემო სხვადასხვა ოპერაციულ სისტემაზე და გავაცნობთ ESP-IDF-ის პროექტის სტრუქტურას და კონსტრუქციულ სისტემას, ასევე შესაბამისი განვითარების ინსტრუმენტების გამოყენებას. შემდეგ ჩვენ წარმოგიდგენთ ყოფილის შედგენისა და გაშვების პროცესსample პროექტი, ხოლო შესთავაზა დეტალური ახსნა გამომავალი ჟურნალის თითოეულ stage.
4.1 ESP-IDF დასრულდაview
ESP-IDF (Espressif IoT Development Framework) არის ერთჯერადი IoT განვითარების ჩარჩო, რომელიც მოწოდებულია Espressif Technology-ის მიერ. ის იყენებს C/C++ როგორც განვითარების მთავარ ენას და მხარს უჭერს ჯვარედინი კომპილაციას ძირითადი ოპერაციული სისტემების პირობებში, როგორიცაა Linux, Mac და Windows. ყოფილმაampამ წიგნში შეტანილი პროგრამები შემუშავებულია ESP-IDF-ის გამოყენებით, რომელიც გთავაზობთ შემდეგ ფუნქციებს: · SoC სისტემის დონის დრაივერები. ESP-IDF მოიცავს დრაივერებს ESP32, ESP32-S2, ESP32-C3,
და სხვა ჩიფსები. ეს დრაივერები მოიცავს პერიფერიულ დაბალი დონის (LL) ბიბლიოთეკას, ტექნიკის აბსტრაქციის ფენის (HAL) ბიბლიოთეკას, RTOS მხარდაჭერას და ზედა ფენის დრაივერის პროგრამულ უზრუნველყოფას და ა.შ. · ძირითადი კომპონენტები. ESP-IDF აერთიანებს IoT განვითარებისთვის საჭირო ფუნდამენტურ კომპონენტებს. ეს მოიცავს ქსელის პროტოკოლის მრავალ დასტას, როგორიცაა HTTP და MQTT, ენერგიის მართვის ჩარჩო დინამიური სიხშირის მოდულაცია და ისეთი ფუნქციები, როგორიცაა Flash Encryption და Secure Boot და ა.შ. · განვითარებისა და წარმოების ინსტრუმენტები. ESP-IDF უზრუნველყოფს საყოველთაოდ გამოყენებულ ინსტრუმენტებს მშენებლობის, ფლეშის და გამართვისთვის განვითარებისა და მასობრივი წარმოების დროს (იხ. სურათი 4.1), როგორიცაა CMake-ზე დაფუძნებული შენობის სისტემა, GCC-ზე დაფუძნებული ჯვარედინი კომპილაციის ხელსაწყოების ჯაჭვი და J.TAG გამართვის ინსტრუმენტი, რომელიც დაფუძნებულია OpenOCD-ზე და ა.შ. აღსანიშნავია, რომ ESP-IDF კოდი ძირითადად ემორჩილება Apache 2.0 ღია კოდის ლიცენზიას. მომხმარებლებს შეუძლიათ განავითარონ პერსონალური ან კომერციული პროგრამული უზრუნველყოფა შეზღუდვების გარეშე, ღია კოდის ლიცენზიის პირობების დაცვით. გარდა ამისა, მომხმარებლებს ენიჭებათ მუდმივი პატენტის ლიცენზიები უფასოდ, წყაროს კოდის ნებისმიერი ცვლილების შეტანის ვალდებულების გარეშე.
31

სურათი 4.1.

აშენება, მოციმციმე და გამართვა-

ging ინსტრუმენტები განვითარებისა და მასობრივი წარმოებისთვის

4.1.1 ESP-IDF ვერსიები
ESP-IDF კოდი განთავსებულია GitHub-ზე, როგორც ღია კოდის პროექტი. ამჟამად ხელმისაწვდომია სამი ძირითადი ვერსია: v3, v4 და v5. თითოეული ძირითადი ვერსია ჩვეულებრივ შეიცავს სხვადასხვა ქვევერსიებს, როგორიცაა v4.2, v4.3 და ა.შ. Espressif Systems უზრუნველყოფს 30 თვიან მხარდაჭერას შეცდომების გამოსწორებისა და უსაფრთხოების პატჩებისთვის თითოეული გამოშვებული ქვევერსიისთვის. ამიტომ რეგულარულად გამოდის დივერსიების რევიზიები, როგორიცაა v4.3.1, v4.2.2 და ა.შ.view stage (მხარდაჭერის შეთავაზება წინასწარview ვერსიები, რომლებსაც შეიძლება არ ჰქონდეს გარკვეული მახასიათებლები ან დოკუმენტაცია) ან ოფიციალურად არის მხარდაჭერილი.

ცხრილი 4.1. სხვადასხვა ESP-IDF ვერსიების მხარდაჭერის სტატუსი Espressif ჩიპებისთვის

სერია ESP32 ESP32-S2 ESP32-C3 ESP32-S3 ESP32-C2 ESP32-H2

v4.1 მხარდაჭერილი

მხარდაჭერილია v4.2

v4.3 მხარდაჭერილი მხარდაჭერილი მხარდაჭერა

v4.4 მხარდაჭერილი მხარდაჭერილი მხარდაჭერილი მხარდაჭერა
წინასწარიview

v5.0 მხარდაჭერილი მხარდაჭერილი მხარდაჭერილი მხარდაჭერილი მხარდაჭერილი წინასწარview

32 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

ძირითადი ვერსიების გამეორება ხშირად მოიცავს ჩარჩოს სტრუქტურის კორექტირებას და კომპილაციის სისტემის განახლებებს. მაგampმთავარი ცვლილება v3.*-დან v4.*-მდე იყო build სისტემის თანდათანობითი მიგრაცია Make-დან CMake-ზე. მეორეს მხრივ, მცირე ვერსიების გამეორება, როგორც წესი, იწვევს ახალი ფუნქციების დამატებას ან ახალი ჩიპების მხარდაჭერას.
მნიშვნელოვანია განასხვავოთ და გავიგოთ ურთიერთობა სტაბილურ ვერსიებსა და GitHub ფილიალებს შორის. ვერსიები ეტიკეტირებული როგორც v*.* ან v*.*.* წარმოადგენს სტაბილურ ვერსიებს, რომლებმაც გაიარეს სრული შიდა ტესტირება Espressif-ის მიერ. დაფიქსირების შემდეგ, კოდი, ხელსაწყოების ჯაჭვი და გამოშვების დოკუმენტები იმავე ვერსიისთვის უცვლელი რჩება. თუმცა, GitHub-ის ფილიალები (მაგ., გამოშვება/v4.3 ფილიალი) განიცდიან ხშირ კოდს, ხშირად ყოველდღიურად. აქედან გამომდინარე, ორი კოდის ფრაგმენტი ერთი და იმავე ფილიალში შეიძლება განსხვავდებოდეს, რის გამოც დეველოპერებმა უნდა განაახლონ თავიანთი კოდი შესაბამისად.
4.1.2 ESP-IDF Git სამუშაო პროცესი
Espressif მიჰყვება სპეციფიკურ Git სამუშაო პროცესს ESP-IDF-სთვის, რომელიც შემდეგნაირად არის ასახული:
· ახალი ცვლილებები განხორციელდა სამაგისტრო ფილიალში, რომელიც ემსახურება როგორც განვითარების მთავარ ფილიალს. მთავარ ფილიალზე ESP-IDF ვერსია ყოველთვის შეიცავს -dev tag მიუთითოს, რომ ის ამჟამად დამუშავების პროცესშია, როგორიცაა v4.3-dev. სამაგისტრო ფილიალში ცვლილებები ჯერ ხელახლა იქნებაviewed და ტესტირება Espressif-ის შიდა საცავში, შემდეგ კი გადაიტანეს GitHub-ზე ავტომატური ტესტირების დასრულების შემდეგ.
· მას შემდეგ რაც ახალი ვერსია დაასრულებს ფუნქციების განვითარებას მთავარ ფილიალში და დააკმაყოფილებს ბეტა ტესტირებაში შესვლის კრიტერიუმებს, ის გადადის ახალ ფილიალზე, როგორიცაა გამოშვება/ 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-დან. თუმცა, მნიშვნელოვანია აღინიშნოს, რომ ამ წიგნის წაკითხვის დროისთვის შეიძლება უკვე ხელმისაწვდომი იყოს v4.4 ან უფრო ახალი ვერსიები. ვერსიის არჩევისას ჩვენ გირჩევთ შემდეგს:
· საწყისი დონის დეველოპერებისთვის მიზანშეწონილია აირჩიონ სტაბილური v4.3 ვერსია ან მისი შესწორებული ვერსია, რომელიც შეესაბამება ყოფილს.ampამ წიგნში გამოყენებული ვერსია.
· მასობრივი წარმოების მიზნით, რეკომენდებულია უახლესი სტაბილური ვერსიის გამოყენება, რათა ისარგებლოთ უახლესი ტექნიკური მხარდაჭერით.
· თუ თქვენ აპირებთ ახალი ჩიპების ექსპერიმენტს ან ახალი პროდუქტის ფუნქციების შესწავლას, გთხოვთ, გამოიყენოთ ძირითადი ფილიალი. უახლესი ვერსია შეიცავს ყველა უახლეს მახასიათებელს, მაგრამ გახსოვდეთ, რომ შეიძლება იყოს ცნობილი ან უცნობი შეცდომები.
· თუ გამოყენებული სტაბილური ვერსია არ შეიცავს სასურველ ახალ ფუნქციებს და გსურთ მინიმუმამდე დაიყვანოთ მთავარ ფილიალთან დაკავშირებული რისკები, განიხილეთ შესაბამისი გამოშვების ფილიალი, როგორიცაა გამოშვება/v4.4 ფილიალი. Espressif-ის GitHub საცავი თავდაპირველად შექმნის გამოშვების/v4.4 ფილიალს და შემდგომში გამოუშვებს სტაბილურ v4.4 ვერსიას ამ ფილიალის კონკრეტული ისტორიული სურათის საფუძველზე, ყველა ფუნქციის განვითარებისა და ტესტირების დასრულების შემდეგ.
4.1.4 დასრულდაview ESP-IDF SDK დირექტორია
ESP-IDF SDK შედგება ორი ძირითადი დირექტორიისგან: esp-idf და .espressif. პირველი შეიცავს ESP-IDF საცავის წყაროს კოდს files და კომპილაციის სკრიპტები, ხოლო ეს უკანასკნელი ძირითადად ინახავს კომპილაციის ხელსაწყოების ჯაჭვებს და სხვა პროგრამულ უზრუნველყოფას. ამ ორი დირექტორიის გაცნობა დაეხმარება დეველოპერებს, უკეთ გამოიყენონ არსებული რესურსები და დააჩქარონ განვითარების პროცესი. ESP-IDF-ის დირექტორია სტრუქტურა აღწერილია ქვემოთ:
(1) ESP-IDF საცავის კოდის დირექტორია (/esp/esp-idf), როგორც ნაჩვენებია სურათზე 4.2.
ა. კომპონენტების დირექტორია კომპონენტები
ეს ძირითადი დირექტორია აერთიანებს ESP-IDF-ის მრავალ აუცილებელ პროგრამულ კომპონენტს. არცერთი პროექტის კოდი არ შეიძლება შედგეს ამ დირექტორიაში არსებულ კომპონენტებზე დაყრდნობის გარეშე. მასში შედის დრაივერის მხარდაჭერა სხვადასხვა Espressif ჩიპებისთვის. LL ბიბლიოთეკიდან და HAL ბიბლიოთეკის ინტერფეისებიდან პერიფერიული მოწყობილობებისთვის ზედა დონის დრაივერი და ვირტუალური File სისტემის (VFS) ფენის მხარდაჭერა, დეველოპერებს შეუძლიათ აირჩიონ შესაბამისი კომპონენტები სხვადასხვა დონეზე მათი განვითარების საჭიროებებისთვის. ESP-IDF ასევე მხარს უჭერს მრავალი სტანდარტული ქსელის პროტოკოლის დასტას, როგორიცაა TCP/IP, HTTP, MQTT, WebSocket და ა.შ. დეველოპერებს შეუძლიათ გამოიყენონ ნაცნობი ინტერფეისები, როგორიცაა Socket, ქსელური აპლიკაციების შესაქმნელად. კომპონენტები უზრუნველყოფენ გაგებას
34 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი 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 ასევე შეიცავს ძირითად სკრიპტს. fileკომპილაციის სისტემის ს, რომელიც ემსახურება ESP-IDF შედგენის წესების დანერგვის საფუძველს. გარემოს ცვლადების დამატებისას, ხელსაწყოების დირექტორიაში არსებული შიგთავსი ემატება სისტემის გარემოს ცვლადს, რაც საშუალებას აძლევს idf.py შესრულდეს უშუალოდ პროექტის ბილიკზე.
დ. მაგample პროგრამის დირექტორია examples
ეს დირექტორია შეიცავს ESP-IDF-ის უზარმაზარ კოლექციასampპროგრამები, რომლებიც აჩვენებენ კომპონენტის API-ების გამოყენებას. ყოფილმაamples ორგანიზებულია სხვადასხვა ქვედირექტორიებად მათი კატეგორიების მიხედვით:
· დაწყება: ეს ქვეცნობარი მოიცავს საწყისი დონის მაგampროგორიცაა „გამარჯობა სამყარო“ და „მოციმციმე“, რათა მომხმარებლებს დაეხმარონ საფუძვლების გააზრებაში.
· bluetooth: შეგიძლიათ იპოვოთ Bluetooth დაკავშირებული ყოფილიampაქ არის, მათ შორის Bluetooth LE Mesh, Bluetooth LE HID, BluFi და სხვა.
· wifi: ეს ქვეცნობარი ფოკუსირებულია Wi-Fi ex-ზეamples, მათ შორის ძირითადი პროგრამები, როგორიცაა Wi-Fi SoftAP, Wi-Fi Station, espnow, ისევე როგორც საკუთრების საკომუნიკაციო პროტოკოლი examples from Espressif. იგი ასევე მოიცავს აპლიკაციის მრავალ ფენას მაგampWi-Fi-ზე დაფუძნებული მოწყობილობები, როგორიცაა Iperf, Sniffer და Smart Config.
· პერიფერიული მოწყობილობები: ეს ვრცელი ქვეცნობარი შემდგომში იყოფა მრავალ ქვესაქაღალდედ პერიფერიული სახელების მიხედვით. ის ძირითადად შეიცავს პერიფერიულ დრაივერს მაგamples Espressif ჩიფსებისთვის, თითოეული ყოფილიampრამდენიმე ქვე-ყოფილიamples. მაგალითად, gpio ქვედირექტორიაში შედის ორი ყოფილიamples: GPIO და GPIO მატრიცული კლავიატურა. მნიშვნელოვანია აღინიშნოს, რომ არა ყველა ყოფილიampამ დირექტორიაში წერილები გამოიყენება ESP32-C3-ზე.
36 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

მაგampლე, ყოფილიampusb/host-ში გამოყენებულია მხოლოდ პერიფერიული მოწყობილობები USB Host-ის აპარატურით (როგორიცაა ESP32-S3), ხოლო ESP32-C3-ს არ აქვს ეს პერიფერიული მოწყობილობა. კომპილაციის სისტემა, როგორც წესი, იძლევა მოთხოვნებს მიზნის დაყენებისას. README file თითოეული ყოფილიample ჩამოთვლის მხარდაჭერილ ჩიპებს. · პროტოკოლები: ეს ქვეცნობარი შეიცავს მაგampსხვადასხვა საკომუნიკაციო პროტოკოლებისთვის, მათ შორის MQTT, HTTP, HTTP სერვერი, PPPoS, Modbus, mDNS, SNTP, რომელიც მოიცავს საკომუნიკაციო პროტოკოლის ფართო სპექტრს.ampIoT განვითარებისთვის საჭირო ნაკლები. · უზრუნველყოფა: აქ, თქვენ იპოვით უზრუნველყოფას მაგamples სხვადასხვა მეთოდებისთვის, როგორიცაა Wi-Fi უზრუნველყოფა და Bluetooth LE უზრუნველყოფა. · სისტემა: ეს ქვეცნობარი მოიცავს სისტემის გამართვას მაგamples (მაგ., stack tracing, runtime tracing, task monitoring), ენერგიის მართვა მაგamples (მაგ. ძილის სხვადასხვა რეჟიმი, თანაპროცესორები) და მაგampდაკავშირებულია სისტემის საერთო კომპონენტებთან, როგორიცაა კონსოლის ტერმინალი, მოვლენის ციკლი და სისტემის ტაიმერი. · შენახვა: ამ ქვედირექტორიაში თქვენ აღმოაჩენთ მაგampყველაფერზე ნაკლები file სისტემები და შენახვის მექანიზმები, რომლებიც მხარდაჭერილია ESP-IDF-ით (როგორიცაა Flash-ის, SD ბარათის და სხვა საცავის მედიის კითხვა და ჩაწერა), ასევეampარასტაბილური შენახვის (NVS), FatFS, SPIFFS და სხვა file სისტემის ოპერაციები. · უსაფრთხოება: ეს ქვეცნობარი შეიცავს მაგampფლეშის დაშიფვრასთან დაკავშირებული საქმეები. (2) ESP-IDF კომპილაციის ხელსაწყოების ჯაჭვის დირექტორია (/.espressif), როგორც ნაჩვენებია სურათზე 4.3.
სურათი 4.3. ESP-IDF კომპილაციის ხელსაწყოების ჯაჭვის დირექტორია
თავი 4. განვითარების გარემოს შექმნა 37

ა. პროგრამული უზრუნველყოფის განაწილების დირექტორია dist
ESP-IDF ხელსაწყოების ჯაჭვი და სხვა პროგრამული უზრუნველყოფა ნაწილდება შეკუმშული პაკეტების სახით. ინსტალაციის პროცესში, ინსტალაციის ინსტრუმენტი ჯერ ჩამოტვირთავს შეკუმშულ პაკეტს dist დირექტორიაში, შემდეგ კი ამოიღებს მას მითითებულ დირექტორიაში. ინსტალაციის დასრულების შემდეგ, ამ დირექტორიაში არსებული შიგთავსი შეიძლება უსაფრთხოდ წაიშალოს.
ბ. პითონის ვირტუალური გარემოს დირექტორია python env
ESP-IDF-ის სხვადასხვა ვერსია ეყრდნობა პითონის პაკეტების კონკრეტულ ვერსიებს. ამ პაკეტების უშუალოდ იმავე ჰოსტზე დაყენებამ შეიძლება გამოიწვიოს კონფლიქტი პაკეტის ვერსიებს შორის. ამის მოსაგვარებლად, ESP-IDF იყენებს პითონის ვირტუალურ გარემოს სხვადასხვა პაკეტის ვერსიების იზოლირებისთვის. ამ მექანიზმით, დეველოპერებს შეუძლიათ დააინსტალირონ ESP-IDF-ის მრავალი ვერსია ერთსა და იმავე ჰოსტზე და ადვილად გადაერთონ მათ შორის გარემოს სხვადასხვა ცვლადების იმპორტით.
გ. ESP-IDF კომპილაციის ხელსაწყოების ჯაჭვის დირექტორია ინსტრუმენტები
ეს დირექტორია ძირითადად შეიცავს ჯვარედინი კომპილაციის ინსტრუმენტებს, რომლებიც საჭიროა ESP-IDF პროექტების შედგენისთვის, როგორიცაა CMake ინსტრუმენტები, Ninja build ინსტრუმენტები და gcc ხელსაწყოების ჯაჭვი, რომელიც ქმნის საბოლოო შესრულებად პროგრამას. გარდა ამისა, ამ დირექტორიაში განთავსებულია C/C++ ენის სტანდარტული ბიბლიოთეკა შესაბამის სათაურთან ერთად fileს. თუ პროგრამა მიუთითებს სისტემის სათაურზე file მოსწონს # მოიცავს , კომპილაციის ხელსაწყოების ჯაჭვი აღმოაჩენს stdio.h-ს file ამ დირექტორიაში.
4.2 ESP-IDF განვითარების გარემოს დაყენება
ESP-IDF განვითარების გარემო მხარს უჭერს ძირითად ოპერაციულ სისტემებს, როგორიცაა Windows, Linux და macOS. ეს განყოფილება გაგაცნობთ, თუ როგორ უნდა დააყენოთ განვითარების გარემო თითოეულ სისტემაზე. რეკომენდირებულია ESP32-C3-ის შემუშავება Linux სისტემაზე, რომელიც დეტალურად იქნება გაცნობილი აქ. ბევრი ინსტრუქცია გამოიყენება პლატფორმებზე, განვითარების ინსტრუმენტების მსგავსების გამო. ამიტომ, რეკომენდებულია ამ განყოფილების შინაარსის ყურადღებით წაკითხვა.
შენიშვნა შეგიძლიათ მიმართოთ ონლაინ დოკუმენტებს, რომლებიც ხელმისაწვდომია https://bookc3.espressif.com/esp32c3, რომელიც შეიცავს ამ განყოფილებაში ნახსენებ ბრძანებებს.
4.2.1 ESP-IDF განვითარების გარემოს დაყენება Linux-ზე
ESP-IDF განვითარების გარემოსთვის საჭირო GNU განვითარებისა და გამართვის ინსტრუმენტები Linux სისტემის მშობლიურია. გარდა ამისა, ბრძანების ხაზის ტერმინალი Linux-ში არის ძლიერი და მოსახერხებელი, რაც მას იდეალურ არჩევანს ხდის ESP32-C3 განვითარებისთვის. Შენ შეგიძლია
38 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

აირჩიეთ თქვენთვის სასურველი Linux დისტრიბუცია, მაგრამ ჩვენ გირჩევთ გამოიყენოთ Ubuntu ან სხვა Debianbased სისტემები. ამ განყოფილებაში მოცემულია ინსტრუქცია Ubuntu 20.04-ზე ESP-IDF განვითარების გარემოს დაყენების შესახებ.
1. დააინსტალირეთ საჭირო პაკეტები
გახსენით ახალი ტერმინალი და შეასრულეთ შემდეგი ბრძანება ყველა საჭირო პაკეტის დასაყენებლად. ბრძანება ავტომატურად გამოტოვებს უკვე დაინსტალირებულ პაკეტებს.
$ sudo apt-get ინსტალაცია 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 აერთიანებს უამრავ ავტომატიზაციის სკრიპტს, რომელიც დაწერილია პითონში. ინსტრუმენტები, როგორიცაა CMake, Ninja-build და Ccache, ფართოდ გამოიყენება C/C++ პროექტებში და ემსახურება როგორც ნაგულისხმევი კოდის კომპილაციისა და აგების ხელსაწყოებს ESP-IDF-ში. libusb-1.0-0 და dfu-util არის ძირითადი დრაივერები, რომლებიც გამოიყენება USB სერიული კომუნიკაციისა და პროგრამული უზრუნველყოფის ჩასაწერად. პროგრამული პაკეტების დაინსტალირების შემდეგ, შეგიძლიათ გამოიყენოთ apt show ბრძანება თითოეული პაკეტის დეტალური აღწერილობის მისაღებად. მაგampგამოიყენეთ apt show git Git ინსტრუმენტის აღწერილობის ინფორმაციის დასაბეჭდად.
კითხვა: რა უნდა გააკეთოს, თუ პითონის ვერსია არ არის მხარდაჭერილი? პასუხი: ESP-IDF v4.3 მოითხოვს Python ვერსიას, რომელიც არ არის უფრო დაბალი ვიდრე v3.6. Ubuntu-ს ძველი ვერსიებისთვის გთხოვთ, ხელით ჩამოტვირთოთ და დააინსტალიროთ Python-ის უფრო მაღალი ვერსია და დააყენოთ Python3 როგორც ნაგულისხმევი Python გარემო. თქვენ შეგიძლიათ იპოვოთ დეტალური ინსტრუქციები საკვანძო სიტყვის განახლება-ალტერნატივების პითონის ძიებით.
2. ჩამოტვირთეთ ESP-IDF საცავის კოდი
გახსენით ტერმინალი და შექმენით საქაღალდე სახელად esp თქვენს მთავარ დირექტორიაში mkdir ბრძანების გამოყენებით. თუ გსურთ, შეგიძლიათ აირჩიოთ საქაღალდის სხვა სახელი. გამოიყენეთ cd ბრძანება საქაღალდეში შესასვლელად.
თავი 4. განვითარების გარემოს შექმნა 39

$ mkdir -p /esp $ cd /esp
გამოიყენეთ git clone ბრძანება ESP-IDF საცავის კოდის ჩამოსატვირთად, როგორც ეს ნაჩვენებია ქვემოთ:
$ git კლონი -b v4.3.2 – რეკურსიული https://github.com/espressif/esp-idf.git
ზემოთ მოცემულ ბრძანებაში პარამეტრი -b v4.3.2 განსაზღვრავს ჩამოტვირთვის ვერსიას (ამ შემთხვევაში, ვერსია 4.3.2). პარამეტრი -რეკურსიული უზრუნველყოფს ESP-IDF-ის ყველა ქვე-საცავის რეკურსიულად გადმოტვირთვას. ინფორმაცია ქვე-საცავების შესახებ შეგიძლიათ იხილოთ .gitmodules-ში file.
3. დააინსტალირეთ ESP-IDF განვითარების ხელსაწყოების ჯაჭვი
Espressif უზრუნველყოფს ავტომატური სკრიპტის install.sh ჩამოსატვირთად და დააინსტალირებს ხელსაწყოების ჯაჭვს. ეს სკრიპტი ამოწმებს ESP-IDF-ის მიმდინარე ვერსიას და ოპერაციული სისტემის გარემოს, შემდეგ ჩამოტვირთავს და აინსტალირებს Python-ის ხელსაწყოების პაკეტების და კომპილაციის ხელსაწყოების ჯაჭვის შესაბამის ვერსიას. ინსტალაციის ნაგულისხმევი გზა ხელსაწყოების ჯაჭვისთვის არის /.espressif. ყველაფერი რაც თქვენ უნდა გააკეთოთ არის ნავიგაცია esp-idf დირექტორიაში და გაუშვით install.sh.
$ cd /esp/esp-idf $ ./install.sh
თუ ხელსაწყოების ჯაჭვს წარმატებით დააინსტალირებთ, ტერმინალი გამოჩნდება:
ყველაფერი გაკეთებულია!
ამ ეტაპზე, თქვენ წარმატებით დააყენეთ ESP-IDF განვითარების გარემო.
4.2.2 ESP-IDF განვითარების გარემოს დაყენება Windows-ზე
1. ჩამოტვირთეთ ESP-IDF ინსტრუმენტების ინსტალერი
რჩევები რეკომენდებულია ESP-IDF განვითარების გარემოს დაყენება Windows 10 ან უფრო მაღალ ვერსიაზე. შეგიძლიათ ჩამოტვირთოთ ინსტალერი https://dl.espressif.com/dl/esp-idf/-დან. ინსტალერი ასევე არის ღია კოდის პროგრამული უზრუნველყოფა და მისი კოდი შეიძლება იყოს viewგამოქვეყნებულია https://github.com/espressif/idf-installer-ზე.
· ონლაინ ESP-IDF ინსტრუმენტების ინსტალერი
ეს ინსტალერი შედარებით მცირეა, დაახლოებით 4 მბ ზომით და სხვა პაკეტები და კოდი ჩამოიტვირთება ინსტალაციის პროცესში. ადვანიtagონლაინ ინსტალერი არის ის, რომ არა მხოლოდ პროგრამული პაკეტების და კოდის ჩამოტვირთვა შესაძლებელია ინსტალაციის პროცესში მოთხოვნისამებრ, არამედ საშუალებას გაძლევთ დააინსტალიროთ ESP-IDF-ის ყველა ხელმისაწვდომი გამოშვება და GitHub კოდის უახლესი ფილიალი (როგორიცაა სამაგისტრო ფილიალი). . მინუსიtage არის ის, რომ ინსტალაციის პროცესში საჭიროა ქსელის კავშირი, რამაც შეიძლება გამოიწვიოს ინსტალაციის წარუმატებლობა ქსელის პრობლემების გამო.
40 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

· ოფლაინ ESP-IDF ხელსაწყოების ინსტალერი ეს ინსტალერი უფრო დიდია, დაახლოებით 1 გბ ზომით და შეიცავს ყველა პროგრამულ პაკეტს და კოდს, რომელიც საჭიროა გარემოს დაყენებისთვის. მთავარი უპირატესობაtagოფლაინ ინსტალერი არის ის, რომ ის შეიძლება გამოყენებულ იქნას კომპიუტერებზე ინტერნეტის გარეშე და ზოგადად აქვს ინსტალაციის წარმატების მაღალი მაჩვენებელი. უნდა აღინიშნოს, რომ ოფლაინ ინსტალერს შეუძლია დააინსტალიროს მხოლოდ ESP-IDF-ის სტაბილური გამოშვებები, რომლებიც იდენტიფიცირებულია v*.* ან v*.*.*-ით.
2. გაუშვით ESP-IDF ინსტრუმენტების ინსტალერი ინსტალერის შესაფერისი ვერსიის ჩამოტვირთვის შემდეგ (მაგალითად, მიიღეთ ESP-IDF Tools Offline 4.3.2ample აქ), ორჯერ დააწკაპუნეთ exe file ESP-IDF ინსტალაციის ინტერფეისის გასაშვებად. ქვემოთ მოცემულია, თუ როგორ უნდა დააინსტალიროთ ESP-IDF სტაბილური ვერსია v4.3.2 ოფლაინ ინსტალერის გამოყენებით.
(1) „აირჩიე ინსტალაციის ენა“ ინტერფეისში, რომელიც ნაჩვენებია ნახაზ 4.4-ზე, აირჩიეთ ენა, რომელიც უნდა გამოიყენოთ ჩამოსაშლელი სიიდან.
სურათი 4.4. ინტერფეისი „აირჩიეთ ინსტალაციის ენა“ (2) ენის არჩევის შემდეგ დააწკაპუნეთ „OK“-ზე, რათა გამოჩნდეს „სალიცენზიო ხელშეკრულების“ ინტერფეისი
(იხ. სურათი 4.5). ინსტალაციის სალიცენზიო ხელშეკრულების ყურადღებით წაკითხვის შემდეგ აირჩიეთ „ვეთანხმები ხელშეკრულებას“ და დააჭირეთ „შემდეგი“.
სურათი 4.5. „სალიცენზიო ხელშეკრულების“ ინტერფეისი თავი 4. განვითარების გარემოს დაყენება 41

(3) რეview სისტემის კონფიგურაცია „სისტემის წინასწარი ინსტალაციის შემოწმება“ ინტერფეისში (იხ. სურათი 4.6). შეამოწმეთ Windows-ის ვერსია და დაინსტალირებული ანტივირუსული პროგრამული უზრუნველყოფის ინფორმაცია. დააწკაპუნეთ "შემდეგი", თუ კონფიგურაციის ყველა ელემენტი ნორმალურია. წინააღმდეგ შემთხვევაში, შეგიძლიათ დააწკაპუნოთ „სრულ ჟურნალში“ ძირითადი ელემენტების საფუძველზე გადაწყვეტილებისთვის.
სურათი 4.6. ინტერფეისის რჩევები „სისტემის შემოწმება ინსტალაციამდე“.
დახმარებისთვის შეგიძლიათ გამოაგზავნოთ ჟურნალები https://github.com/espressif/idf-installer/issues-ზე. (4) აირჩიეთ ESP-IDF ინსტალაციის დირექტორია. აქ აირჩიეთ D:/.espressif, როგორც ნაჩვენებია
სურათი 4.7 და დააჭირეთ "შემდეგი". გთხოვთ გაითვალისწინოთ, რომ .espressif აქ არის დამალული დირექტორია. ინსტალაციის დასრულების შემდეგ შეგიძლიათ view ამ დირექტორიას კონკრეტული შინაარსის გახსნით file მენეჯერი და ფარული ელემენტების ჩვენება.
სურათი 4.7. აირჩიეთ ESP-IDF ინსტალაციის დირექტორია 42 ESP32-C3 Wireless Adventure: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

(5) შეამოწმეთ კომპონენტები, რომლებიც უნდა დამონტაჟდეს, როგორც ნაჩვენებია სურათზე 4.8. მიზანშეწონილია გამოიყენოთ ნაგულისხმევი ვარიანტი, ანუ დაასრულოთ ინსტალაცია და შემდეგ დააწკაპუნოთ "შემდეგი".
სურათი 4.8. აირჩიეთ კომპონენტები, რომლებიც უნდა დააინსტალიროთ (6) დაადასტურეთ კომპონენტები, რომლებიც უნდა დააინსტალიროთ და დააწკაპუნეთ „ინსტალაციაზე“, რათა დაიწყოთ ავტომატური ინ-
დაყენების პროცესი, როგორც ნაჩვენებია სურათზე 4.9. ინსტალაციის პროცესი შეიძლება გაგრძელდეს ათობით წუთი და ინსტალაციის პროცესის პროგრესის ზოლი ნაჩვენებია სურათზე 4.10. გთხოვთ მოთმინებით დაელოდოთ.
სურათი 4.9. ინსტალაციისთვის მზადება (7) ინსტალაციის დასრულების შემდეგ, რეკომენდებულია შეამოწმოთ „ESP-IDF-ის რეგისტრაცია
ინსტრუმენტები შესრულებადი, როგორც Windows Defender გამონაკლისი…” ანტივირუსული პროგრამის წაშლის თავიდან ასაცილებლად fileს. გამორიცხვის ელემენტების დამატებით ასევე შეიძლება გამოტოვოთ ხშირი სკანირება ანტივირუსით
თავი 4. განვითარების გარემოს შექმნა 43

სურათი 4.10. ინსტალაციის პროგრესის ზოლის პროგრამული უზრუნველყოფა, მნიშვნელოვნად აუმჯობესებს Windows სისტემის კოდების შედგენის ეფექტურობას. დააწკაპუნეთ „დასრულებაზე“ განვითარების გარემოს ინსტალაციის დასასრულებლად, როგორც ნაჩვენებია სურათზე 4.11. თქვენ შეგიძლიათ აირჩიოთ „ESP-IDF PowerShell გარემოს გაშვება“ ან „ESP-IDF ბრძანების ხაზის გაშვება“. გაუშვით კომპილაციის ფანჯარა უშუალოდ ინსტალაციის შემდეგ, რათა დარწმუნდეთ, რომ განვითარების გარემო ნორმალურად ფუნქციონირებს.
სურათი 4.11. ინსტალაცია დასრულდა (8) გახსენით დაინსტალირებული განვითარების გარემო პროგრამების სიაში (ან ESP-IDF 4.3
CMD ან 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-ზე
Mac სისტემაზე ESP-IDF განვითარების გარემოს დაყენების პროცესი იგივეა, რაც Linux სისტემაში. საცავის კოდის ჩამოტვირთვისა და ხელსაწყოების ჯაჭვის ინსტალაციის ბრძანებები ზუსტად იგივეა. მხოლოდ დამოკიდებულების პაკეტების დაყენების ბრძანებები ოდნავ განსხვავდება. 1. დამოკიდებულების პაკეტების ინსტალაცია გახსენით ტერმინალი და დააინსტალირეთ pip, Python პაკეტის მართვის ინსტრუმენტი, შემდეგი ბრძანების გაშვებით:
% sudo მარტივი ინსტალაციის პიპი
დააინსტალირეთ Homebrew, პაკეტის მართვის ინსტრუმენტი macOS-ისთვის, შემდეგი ბრძანების გაშვებით:
% /bin/bash -c „$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/ HEAD/install.sh)”
დააინსტალირეთ საჭირო დამოკიდებულების პაკეტები შემდეგი ბრძანების გაშვებით:
% brew python3 დააინსტალირე cmake ninja ccache dfu-util
2. ჩამოტვირთეთ ESP-IDF საცავის კოდი მიჰყევით 4.2.1 ნაწილში მოცემულ ინსტრუქციას ESP-IDF საცავის კოდის ჩამოსატვირთად. ნაბიჯები იგივეა, რაც ლინუქსის სისტემაზე ჩამოტვირთვისას.
თავი 4. განვითარების გარემოს შექმნა 45

3. დააინსტალირეთ ESP-IDF განვითარების ხელსაწყოების ჯაჭვი
მიჰყევით 4.2.1 ნაწილში მოცემულ ინსტრუქციას ESP-IDF განვითარების ხელსაწყოების ჯაჭვის დასაყენებლად. ნაბიჯები იგივეა, რაც Linux სისტემაზე ინსტალაციისთვის.
4.2.4 VS კოდის ინსტალაცია
ნაგულისხმევად, ESP-IDF SDK არ შეიცავს კოდის რედაქტირების ხელსაწყოს (თუმცა უახლესი ESP-IDF ინსტალერი Windows-ისთვის გთავაზობთ ESP-IDF Eclipse-ის ინსტალაციის ვარიანტს). თქვენ შეგიძლიათ გამოიყენოთ თქვენი არჩევანის ტექსტის რედაქტირების ნებისმიერი ინსტრუმენტი კოდის რედაქტირებისთვის და შემდეგ მისი შედგენა ტერმინალის ბრძანებების გამოყენებით.
კოდის რედაქტირების ერთ-ერთი პოპულარული ინსტრუმენტია VS Code (Visual Studio Code), რომელიც არის უფასო და მდიდარი კოდის რედაქტორი მომხმარებლისთვის მოსახერხებელი ინტერფეისით. ის გთავაზობთ სხვადასხვა plugins რომელიც უზრუნველყოფს ფუნქციებს, როგორიცაა კოდების ნავიგაცია, სინტაქსის ხაზგასმა, Git ვერსიის კონტროლი და ტერმინალის ინტეგრაცია. გარდა ამისა, Espressif-მა შეიმუშავა გამოყოფილი მოდული სახელწოდებით Espressif IDF VS კოდისთვის, რომელიც ამარტივებს პროექტის კონფიგურაციას და გამართვას.
შეგიძლიათ გამოიყენოთ კოდის ბრძანება ტერმინალში, რათა სწრაფად გახსნათ მიმდინარე საქაღალდე VS Code-ში. ალტერნატიულად, შეგიძლიათ გამოიყენოთ მალსახმობი Ctrl+ სისტემის ნაგულისხმევი ტერმინალის კონსოლის გასახსნელად VS Code-ში.
რჩევები რეკომენდირებულია გამოიყენოთ VS კოდი ESP32-C3 კოდის შემუშავებისთვის. ჩამოტვირთეთ და დააინსტალირეთ VS Code-ის უახლესი ვერსია https://code.visualstudio.com/.
4.2.5 შესავალი მესამე მხარის განვითარების გარემოში
ESP-IDF განვითარების ოფიციალური გარემოს გარდა, რომელიც ძირითადად იყენებს C ენას, ESP32-C3 ასევე მხარს უჭერს სხვა ძირითადი პროგრამირების ენებს და მესამე მხარის განვითარების გარემოს ფართო სპექტრს. ზოგიერთი შესამჩნევი ვარიანტი მოიცავს:
Arduino: ღია კოდის პლატფორმა როგორც აპარატურისთვის, ასევე პროგრამული უზრუნველყოფისთვის, რომელიც მხარს უჭერს სხვადასხვა მიკროკონტროლერებს, მათ შორის ESP32-C3.
ის იყენებს C++ ენას და გთავაზობთ გამარტივებულ და სტანდარტიზებულ API-ს, რომელსაც ჩვეულებრივ Arduino ენას უწოდებენ. Arduino ფართოდ გამოიყენება პროტოტიპების შემუშავებაში და საგანმანათლებლო კონტექსტში. ის უზრუნველყოფს გაფართოებულ პროგრამულ პაკეტს და IDE-ს, რომელიც იძლევა მარტივი შედგენისა და ციმციმის საშუალებას.
MicroPython: Python 3 ენის თარჯიმანი, რომელიც შექმნილია ჩაშენებულ მიკროკონტროლერ პლატფორმებზე გასაშვებად.
მარტივი სკრიპტის ენით, მას შეუძლია პირდაპირ წვდომა ESP32-C3-ის პერიფერიულ რესურსებზე (როგორიცაა UART, SPI და I2C) და საკომუნიკაციო ფუნქციებზე (როგორიცაა Wi-Fi და Bluetooth LE).
46 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

ეს ამარტივებს ტექნიკის ურთიერთქმედებას. MicroPython, პითონის ვრცელი მათემატიკური ოპერაციების ბიბლიოთეკასთან ერთად, საშუალებას იძლევა რთული ალგორითმების დანერგვა ESP32-C3-ზე, რაც ხელს უწყობს AI-თან დაკავშირებული აპლიკაციების განვითარებას. როგორც დამწერლობის ენა, არ არის საჭირო განმეორებითი შედგენა; შესაძლებელია ცვლილებების შეტანა და სკრიპტების პირდაპირ შესრულება.
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: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

განსაზღვრავს მისი კომპილაციის პარამეტრებს და დამოკიდებულებებს. კომპილაციის პროცესში კომპონენტები კომპილირებულია ცალკეულ სტატიკურ ბიბლიოთეკებში (.a fileს) და საბოლოოდ სხვა კომპონენტებთან ერთად აპლიკაციის პროგრამის შესაქმნელად.
ESP-IDF უზრუნველყოფს აუცილებელ ფუნქციებს, როგორიცაა ოპერაციული სისტემა, პერიფერიული დრაივერები და ქსელის პროტოკოლის დასტა, კომპონენტების სახით. ეს კომპონენტები ინახება კომპონენტების დირექტორიაში, რომელიც მდებარეობს ESP-IDF root დირექტორიაში. დეველოპერებს არ სჭირდებათ ამ კომპონენტების კოპირება myProject-ის კომპონენტების დირექტორიაში. ამის ნაცვლად, მათ მხოლოდ უნდა დააკონკრეტოთ ამ კომპონენტების დამოკიდებულების ურთიერთობები პროექტის CMakeLists.txt-ში. file REQUIRES ან PRIV_REQUIRES დირექტივების გამოყენებით. კომპილაციის სისტემა ავტომატურად აღმოაჩენს და შეადგენს საჭირო კომპონენტებს.
ამიტომ, კომპონენტების დირექტორია myProject-ში არ არის საჭირო. იგი გამოიყენება მხოლოდ პროექტის ზოგიერთი ინდივიდუალური კომპონენტის შესატანად, რომელიც შეიძლება იყოს მესამე მხარის ბიბლიოთეკები ან მომხმარებლის მიერ განსაზღვრული კოდი. გარდა ამისა, კომპონენტების წყარო შეიძლება იყოს ნებისმიერი დირექტორია, გარდა ESP-IDF ან მიმდინარე პროექტისა, მაგალითად, სხვა დირექტორიაში შენახული ღია კოდის პროექტიდან. ამ შემთხვევაში, თქვენ მხოლოდ უნდა დაამატოთ კომპონენტის ბილიკი EXTRA_COMPONENT_DIRS ცვლადის დაყენებით CMakeLists.txt root დირექტორიაში. ეს დირექტორია უგულებელყოფს ნებისმიერ ESP-IDF კომპონენტს იგივე სახელით, რაც უზრუნველყოფს სწორი კომპონენტის გამოყენებას.
შესვლის პროგრამის მთავარი პროექტის მთავარი დირექტორია იგივე მიდის file სტრუქტურა, როგორც სხვა კომპონენტები (მაგ. კომპონენტი1). თუმცა, მას განსაკუთრებული მნიშვნელობა აქვს, რადგან ის არის სავალდებულო კომპონენტი, რომელიც უნდა არსებობდეს ყველა პროექტში. მთავარი დირექტორია შეიცავს პროექტის საწყის კოდს და მომხმარებლის პროგრამის შესვლის წერტილს, რომელსაც ჩვეულებრივ ეძახიან app_main. ნაგულისხმევად, მომხმარებლის პროგრამის შესრულება იწყება ამ შესვლის წერტილიდან. მთავარი კომპონენტი ასევე განსხვავდება იმით, რომ ის ავტომატურად დამოკიდებულია ყველა კომპონენტზე საძიებო გზაზე. ამიტომ, არ არის საჭირო ცალსახად მიუთითოთ დამოკიდებულებები CMakeLists.txt-ში REQUIRES ან PRIV_REQUIRES დირექტივების გამოყენებით. file.
კონფიგურაცია file პროექტის root დირექტორია შეიცავს კონფიგურაციას file სახელწოდებით sdkconfig, რომელიც შეიცავს პროექტის ყველა კომპონენტის კონფიგურაციის პარამეტრებს. sdkconfig file ავტომატურად გენერირდება კომპილაციის სისტემის მიერ და მისი შეცვლა და რეგენერაცია შესაძლებელია ბრძანებით idf.py menuconfig. მენიუს კონფიგურაციის პარამეტრები ძირითადად წარმოიქმნება პროექტის Kconfig.projbuild-დან და კომპონენტების Kconfig-დან. კომპონენტების დეველოპერები ზოგადად ამატებენ კონფიგურაციის ელემენტებს Kconfig-ში, რათა კომპონენტი მოქნილი და კონფიგურირებადი გახადონ.
Build დირექტორია ნაგულისხმევად, build დირექტორია პროექტის ფარგლებში ინახავს შუალედურს files და fi-
თავი 4. განვითარების გარემოს შექმნა 49

nal შესრულებადი პროგრამები გენერირებული idf.py build ბრძანებით. ზოგადად, არ არის აუცილებელი უშუალოდ წვდომა build დირექტორიაში. ESP-IDF უზრუნველყოფს წინასწარ განსაზღვრულ ბრძანებებს დირექტორიასთან ურთიერთქმედებისთვის, მაგალითად, idf.py ფლეშ ბრძანების გამოყენებით კომპილირებული ბინარის ავტომატურად განთავსებისთვის. file და გამოანათეთ იგი მითითებულ ფლეშ მისამართზე, ან გამოიყენეთ idf.py fullclean ბრძანება მთელი build დირექტორიის გასასუფთავებლად.
დანაყოფის ცხრილი (partitions.csv) თითოეული პროექტი მოითხოვს დანაყოფის ცხრილს, რათა გაიყოს ფლეშის სივრცე და მიუთითოს შესრულებადი პროგრამის ზომა და საწყისი მისამართი და მომხმარებლის მონაცემების სივრცე. Command idf.py flash ან OTA განახლების პროგრამა გამოანათებს firmware-ს შესაბამის მისამართზე ამ ცხრილის მიხედვით. ESP-IDF გთავაზობთ რამდენიმე ნაგულისხმევ დანაყოფის ცხრილებს კომპონენტებში/partition_table-ში, როგორიცაა partitions_singleapp.csv და partitions_two_ ota.csv, რომელთა არჩევა შესაძლებელია მენიუს კონფიგურაციაში.
თუ სისტემის ნაგულისხმევი დანაყოფების ცხრილი ვერ აკმაყოფილებს პროექტის მოთხოვნებს, მორგებული partitions.csv შეიძლება დაემატოს პროექტის დირექტორიაში და შეირჩეს menuconfig-ში.
4.3.3 კომპილაციის სისტემის ნაგულისხმევი Build წესები
ერთიდაიგივე სახელის მქონე კომპონენტების გადაფარვის წესები კომპონენტების ძიების პროცესში, კომპილაციის სისტემა მიჰყვება კონკრეტულ წესრიგს. ის ჯერ ეძებს ESP-IDF-ის შიდა კომპონენტებს, შემდეგ ეძებს მომხმარებლის პროექტის კომპონენტებს და ბოლოს ეძებს კომპონენტებს EXTRA_COMPONENT_DIRS-ში. იმ შემთხვევებში, როდესაც მრავალი დირექტორია შეიცავს კომპონენტებს ერთი და იგივე სახელით, ბოლო დირექტორიაში ნაპოვნი კომპონენტი გადააჭარბებს იმავე სახელის წინა კომპონენტებს. ეს წესი იძლევა ESP-IDF კომპონენტების პერსონალიზაციას მომხმარებლის პროექტში, ხოლო ორიგინალური ESP-IDF კოდი ხელუხლებლად შეინარჩუნოს.
ნაგულისხმევად საერთო კომპონენტების ჩართვის წესები როგორც აღინიშნა განყოფილებაში 4.3.2, კომპონენტებმა მკაფიოდ უნდა მიუთითონ თავიანთი დამოკიდებულება სხვა კომპონენტებზე CMakeLists.txt-ში. თუმცა, ჩვეულებრივი კომპონენტები, როგორიცაა freertos, ავტომატურად შედის build სისტემაში ნაგულისხმევად, მაშინაც კი, თუ მათი დამოკიდებულების ურთიერთობები არ არის ცალსახად განსაზღვრული კომპილაციის სკრიპტში. 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 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი 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-ში კომპილაციის სკრიპტები ძირითადად მოიცავს პროექტის კომპილაციის სკრიპტს და კომპონენტის კომპილაციის სკრიპტებს. პროექტის root დირექტორიაში CMakeLists.txt-ს ეწოდება პროექტის კომპილაციის სკრიპტი, რომელიც ხელმძღვანელობს მთელი პროექტის შედგენის პროცესს. ძირითადი პროექტის კომპილაციის სკრიპტი ჩვეულებრივ მოიცავს შემდეგ სამ ხაზს:
1. cmake_minimum_required(VERSION 3.5) 2. include($ENV{IDF_PATH}/tools/cmake/project.cmake) 3. პროექტი (myProject)
მათ შორის პირველ სტრიქონზე უნდა განთავსდეს cmake_minimum_required (VERSION 3.5), რომელიც გამოიყენება პროექტის მიერ მოთხოვნილი მინიმალური CMake ვერსიის ნომრის მითითებისთვის. CMake-ის უახლესი ვერსიები, როგორც წესი, თავსებადია ძველ ვერსიებთან, ამიტომ შეცვალეთ ვერსიის ნომერი შესაბამისად ახალი CMake ბრძანებების გამოყენებისას თავსებადობის უზრუნველსაყოფად.
მოიცავს ($ENV {IDF_PATH}/tools/cmake/project.cmake) ESP-IDF კომპილაციის სისტემის წინასწარ განსაზღვრული კონფიგურაციის ელემენტების და ბრძანებების იმპორტს, 4.3.3-ში აღწერილი კომპილაციის სისტემის ნაგულისხმევი კონსტრუქციის წესების ჩათვლით. project(myProject) თავად ქმნის პროექტს და აზუსტებს მის სახელს. ეს სახელი გამოყენებული იქნება როგორც საბოლოო გამომავალი ორობითი file სახელი, ანუ myProject.elf და myProject.bin.
პროექტს შეიძლება ჰქონდეს მრავალი კომპონენტი, მათ შორის მთავარი კომპონენტი. თითოეული კომპონენტის ზედა დონის დირექტორია შეიცავს CMakeLists.txt file, რომელსაც ეწოდება კომპონენტის კომპილაციის სკრიპტი. კომპონენტების კომპილაციის სკრიპტები ძირითადად გამოიყენება კომპონენტების დამოკიდებულების, კონფიგურაციის პარამეტრების, წყაროს კოდის დასაზუსტებლად files და მოყვება სათაური fileს ამისთვის
თავი 4. განვითარების გარემოს შექმნა 51

შედგენა. ESP-IDF-ის მორგებული ფუნქციით idf_component_register, კომპონენტის კომპილაციის სკრიპტის მინიმალური საჭირო კოდი შემდეგია:

1. idf_component_register(SRCS „src1.c“

INCLUDE_DIRS „შეიცავს“

საჭიროებს კომპონენტს 1)

SRCS პარამეტრი უზრუნველყოფს წყაროების სიას files კომპონენტში, გამოყოფილი სივრცეებით, თუ არის მრავლობითი fileს. INCLUDE_DIRS პარამეტრი უზრუნველყოფს საჯარო სათაურის სიას file დირექტორიები კომპონენტისთვის, რომელიც დაემატება სხვა კომპონენტების საძიებო გზას, რომლებიც დამოკიდებულია მიმდინარე კომპონენტზე. REQUIRES პარამეტრი განსაზღვრავს საჯარო კომპონენტის დამოკიდებულებებს მიმდინარე კომპონენტისთვის. აუცილებელია კომპონენტებმა ცალსახად მიუთითონ რომელ კომპონენტებზეა დამოკიდებული, მაგალითად კომპონენტი2 დამოკიდებულია კომპონენტზე1. თუმცა, ძირითადი კომპონენტისთვის, რომელიც ნაგულისხმევად დამოკიდებულია ყველა კომპონენტზე, REQUIRES პარამეტრი შეიძლება გამოტოვდეს.

გარდა ამისა, მშობლიური CMake ბრძანებები ასევე შეიძლება გამოყენებულ იქნას კომპილაციის სკრიპტში. მაგample, გამოიყენეთ ბრძანება set ცვლადების დასაყენებლად, როგორიცაა set(VARIABLE "VALUE").

4.3.5 შესავალი საერთო ბრძანებებში
ESP-IDF იყენებს CMake-ს (პროექტის კონფიგურაციის ხელსაწყოს), Ninja-ს (პროექტის მშენებლობის ხელსაწყოს) და esptool-ს (ფლეშ ხელსაწყოს) კოდის შედგენის პროცესში. თითოეული ინსტრუმენტი ასრულებს განსხვავებულ როლს შედგენის, აშენებისა და ფლეშის პროცესში და ასევე მხარს უჭერს სხვადასხვა ოპერაციულ ბრძანებებს. მომხმარებლის ფუნქციონირების გასაადვილებლად, ESP-IDF ამატებს ერთიანი წინა idf.py-ს, რომელიც ზემოაღნიშნული ბრძანებების სწრაფად გამოძახების საშუალებას იძლევა.
idf.py-ის გამოყენებამდე დარწმუნდით, რომ:
· ESP-IDF-ის გარემოს ცვლადი IDF_PATH დაემატა მიმდინარე ტერმინალს. · ბრძანების შესრულების დირექტორია არის პროექტის root დირექტორია, რომელიც მოიცავს
პროექტის კომპილაციის სკრიპტი CMakeLists.txt.
idf.py-ის საერთო ბრძანებები შემდეგია:
· idf.py –help: ბრძანებების სიის და მათი გამოყენების ინსტრუქციების ჩვენება. · idf.py მითითებული-სამიზნე : კომპილაციის დაყენება taidf.py fullcleanrget, როგორიცაა
როგორც შემცვლელი esp32c3-ით. · idf.py menuconfig: გაშვება menuconfig, ტერმინალის გრაფიკული კონფიგურაცია
ინსტრუმენტი, რომელსაც შეუძლია შეარჩიოს ან შეცვალოს კონფიგურაციის პარამეტრები და კონფიგურაციის შედეგები ინახება sdkconfig-ში file. · idf.py build: კოდის შედგენის დაწყება. შუალედური files და კომპილაციის მიერ გენერირებული საბოლოო შესრულებადი პროგრამა ნაგულისხმევად შეინახება პროექტის build დირექტორიაში. შედგენის პროცესი ეტაპობრივია, რაც იმას ნიშნავს, რომ თუ მხოლოდ ერთი წყარო file შეცვლილია, მხოლოდ შეცვლილია file შემდეგ ჯერზე შედგენილი იქნება.

52 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი IoT-ისთვის

· idf.py სუფთა: შუალედურის გაწმენდა fileპროექტის შედგენის შედეგად წარმოქმნილი ს. მთელი პროექტი იძულებული იქნება შედგეს შემდეგ კრებულში. გაითვალისწინეთ, რომ CMake კონფიგურაცია და menuconfig-ის მიერ შესრულებული კონფიგურაციის ცვლილებები არ წაიშლება გასუფთავების დროს.
· idf.py fullclean: წაშლა მთელი build დირექტორია, მათ შორის CMake კონფიგურაციის ყველა გამომავალი fileს. პროექტის ხელახლა აშენებისას, CMake დააკონფიგურირებს პროექტს ნულიდან. გთხოვთ გაითვალისწინოთ, რომ ეს ბრძანება რეკურსიულად წაშლის ყველაფერს files build დირექტორიაში, ამიტომ გამოიყენეთ იგი სიფრთხილით და პროექტის კონფიგურაცია file არ წაიშლება.
· idf.py flash: შესრულებადი პროგრამის ორობითი ციმციმები file გენერირებული build-ით სამიზნე ESP32-C3-მდე. ვარიანტები - გვ და -ბ გამოიყენება სერიული პორტის მოწყობილობის სახელის და ციმციმისთვის ბაუდის სიჩქარის დასაყენებლად. თუ ეს ორი ვარიანტი არ არის მითითებული, სერიული პორტი ავტომატურად გამოვლინდება და გამოყენებული იქნება ბაუდის ნაგულისხმევი სიჩქარე.
· idf.py მონიტორი: აჩვენებს სამიზნე ESP32-C3 სერიული პორტის გამომავალს. ვარიანტი -p შეიძლება გამოყენებულ იქნას ჰოსტის მხარის სერიული პორტის მოწყობილობის სახელის დასაზუსტებლად. სერიული პორტის ბეჭდვისას დააჭირეთ კლავიშთა კომბინაციას Ctrl+] მონიტორიდან გასასვლელად.
ზემოაღნიშნული ბრძანებები ასევე შეიძლება გაერთიანდეს საჭიროებისამებრ. მაგample, ბრძანება idf.py build flash monitor შეასრულებს კოდის შედგენას, ფლეშს და გახსნის სერიული პორტის მონიტორს თანმიმდევრობით.
შეგიძლიათ ეწვიოთ https://bookc3.espressif.com/build-system, რომ მეტი იცოდეთ ESP-IDF კომპილაციის სისტემის შესახებ.
4.4 პრაქტიკა: შედგენა მაგampპროგრამა "Blink"
4.4.1 ყოფილიampანალიზი
ეს განყოფილება მიიღებს პროგრამას Blink, როგორც ყოფილიampგავაანალიზოთ file დეტალურად რეალური პროექტის სტრუქტურა და კოდირების წესები. Blink პროგრამა ახორციელებს LED მოციმციმე ეფექტს და პროექტი მდებარეობს დირექტორიაში examples/get-started/blink, რომელიც შეიცავს წყაროს file, კონფიგურაცია files და რამდენიმე კომპილაციის სკრიპტი.
ამ წიგნში წარმოდგენილი ჭკვიანი სინათლის პროექტი ეფუძნება ამ ყოფილსampლე პროგრამა. ფუნქციები თანდათან დაემატება შემდეგ თავებში, რათა საბოლოოდ დასრულდეს იგი.
წყარო კოდი განვითარების მთელი პროცესის დემონსტრირების მიზნით, Blink პროგრამა დაკოპირდა esp32c3-iot-projects/device firmware/1 blink.
blink პროექტის დირექტორია სტრუქტურა files ნაჩვენებია სურათზე 4.15.
მოციმციმე პროექტი შეიცავს მხოლოდ ერთ მთავარ დირექტორიას, რომელიც წარმოადგენს სპეციალურ კომპონენტს
თავი 4. განვითარების გარემოს შექმნა 53

სურათი 4.15. File blink პროექტის დირექტორიას სტრუქტურა

უნდა იყოს ჩართული, როგორც აღწერილია 4.3.2 ნაწილში. ძირითადი დირექტორია ძირითადად გამოიყენება app_main() ფუნქციის განხორციელების შესანახად, რომელიც არის მომხმარებლის პროგრამის შესვლის წერტილი. Blink პროექტი არ შეიცავს კომპონენტების დირექტორიას, რადგან ეს ყოფილიampსაჭიროა მხოლოდ იმ კომპონენტების გამოყენება, რომლებიც მოყვება ESP-IDF-ს და არ საჭიროებს დამატებით კომპონენტებს. Blink პროექტში შემავალი CMakeLists.txt გამოიყენება კომპილაციის პროცესის წარმართვისთვის, ხოლო Kconfig.projbuild გამოიყენება ამ ყოფილი კონფიგურაციის ელემენტების დასამატებლად.ampპროგრამა მენიუში კონფიგურაციაში. სხვა არასაჭირო files არ იმოქმედებს კოდის შედგენაზე, ამიტომ ისინი აქ არ იქნება განხილული. დეტალური შესავალი blink პროექტის შესახებ files არის შემდეგი.

1. /*blink.c მოიცავს შემდეგ სათაურს files*/

2. #შეიცავს

//სტანდარტული C ბიბლიოთეკის სათაური file

3. #include „freertos/freeRTOS.h“ //FreeRTOS მთავარი სათაური file

4. #include „freertos/task.h“

//FreeRTOS დავალების სათაური file

5. #include „sdkconfig.h“

//კონფიგურაციის სათაური file გენერირებული kconfig-ის მიერ

6. #include „driver/gpio.h“

//GPIO დრაივერის სათაური file

წყარო file blink.c შეიცავს სათაურის სერიას files შესაბამისი ფუნქცია declara-

tions. ESP-IDF ზოგადად მიჰყვება ბიბლიოთეკის სტანდარტული სათაურის ჩართვის თანმიმდევრობას files, FreeR-

TOS სათაური files, მძღოლის სათაური files, სხვა კომპონენტის სათაური files და პროექტის სათაური files.

სათაურის თანმიმდევრობა files ჩართული შეიძლება გავლენა იქონიოს შედგენის საბოლოო შედეგზე, ამიტომ სცადეთ

დაიცავით ნაგულისხმევი წესები. უნდა აღინიშნოს, რომ sdkconfig.h ავტომატურად გენერირებულია

kconfig-ით და მისი კონფიგურაცია შესაძლებელია მხოლოდ ბრძანების idf.py menuconfig.

ამ სათაურის პირდაპირი მოდიფიკაცია file გადაიწერება.

1. /*შეგიძლიათ აირჩიოთ LED-ის შესაბამისი GPIO idf.py menuconfig-ში და menuconfig-ის მოდიფიკაციის შედეგი არის CONFIG_BLINK მნიშვნელობა.

_GPIO შეიცვლება. თქვენ ასევე შეგიძლიათ პირდაპირ შეცვალოთ მაკრო განმარტება

აქ და შეცვალეთ CONFIG_BLINK_GPIO ფიქსირებულ მნიშვნელობად.*/ 2. #define BLINK_GPIO CONFIG_BLINK_GPIO

3. void app_main(void)

4. {

/* დააკონფიგურირეთ IO, როგორც GPIO ნაგულისხმევი ფუნქცია, ჩართეთ ამოღების რეჟიმი და

გამორთეთ შეყვანის და გამომავალი რეჟიმები*/

gpio_reset_pin (BLINK_GPIO);

54 ESP32-C3 უსადენო თავგადასავალი: ყოვლისმომცველი გზამკვლევი 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); ხოლო (1) {
/*Print log*/ printf("LEDn-ის გამორთვა"); /*გამორთეთ LED (გამომავალი დაბალი დონე)*/ gpio_set_level(BLINK_GPIO, 0); /*დაყოვნება (1000 ms)*/ vTaskDelay(1000 / portTICK_PERIOD_MS); printf ("ჩართვა LEDn"); /*ჩართეთ LED (გამომავალი მაღალი დონე)*/ gpio_set_level(BLINK_GPIO, 1); vTaskDelay (1000 / portTICK_PERIOD_MS); }

app_main() ფუნქცია Blink example პროგრამა ემსახურება როგორც შესვლის პუნქტს მომხმარებლის პროგრამებისთვის. ეს არის მარტივი ფუნქცია პარამეტრების და დაბრუნების მნიშვნელობის გარეშე. ეს ფუნქცია გამოიძახება მას შემდეგ, რაც სისტემა დაასრულებს ინიციალიზაციას, რომელიც მოიცავს ამოცანებს, როგორიცაა ჟურნალის სერიული პორტის ინიციალიზაცია, ერთი/ორმაგი ბირთვის კონფიგურაცია და დამკვირვებლის კონფიგურაცია.

app_main() ფუნქცია მუშაობს ძირითადი ამოცანის კონტექსტში. დატის ზომა და ამ ამოცანის პრიორიტეტი შეიძლება დარეგულირდეს მენიუს კონფიგურაციაში Componentconfig Common ESP-თან დაკავშირებული.

მარტივი ამოცანებისთვის, როგორიცაა LED-ის მოციმციმე, ყველა საჭირო კოდი შეიძლება განხორციელდეს პირდაპირ app_main() ფუნქციაში. ეს ჩვეულებრივ გულისხმობს LED-ის შესაბამისი GPIO-ს ინიციალიზაციას და 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-ს და წყაროს fileSRCS-ში დამატებული s შედგენილი იქნება. ამავდროულად, „.“, რომელიც წარმოადგენს გზას, სადაც მდებარეობს CMakeLists.txt, უნდა დაემატოს INCLUDE_DIRS-ს, როგორც სათაურის საძიებო დირექტორია. fileს. CMakeLists.txt-ის შინაარსი ასეთია:
1. #დააკონკრეტეთ v3.5 როგორც უძველეს CMake ვერსიას, რომელსაც მხარდაჭერილი აქვს მიმდინარე პროექტი 2. #v3.5-ზე დაბალი ვერსიები უნდა განახლდეს კომპილაციის გაგრძელებამდე 3. cmake_minimum_required(VERSION 3.5) 4. #Include CMake ნაგულისხმევი კონფიგურაციის ESP -IDF კომპილაციის სისტემა

თავი 4. განვითარების გარემოს შექმნა 55

5. მოიცავს($ENV{IDF_PATH}/tools/cmake/project.cmake) 6. #შექმენით პროექტი სახელად „blink“ 7. პროექტი (myProject)
მათ შორის, root დირექტორიაში CMakeLists.txt ძირითადად მოიცავს $ENV{IDF_ PATH}/tools/cmake/project.cmake, რომელიც არის მთავარი CMake კონფიგურაცია. file მოწოდებულია ESP-IDF-ის მიერ. იგი გამოიყენება კონ

დოკუმენტები / რესურსები

Espressif Systems ESP32-C3 Wireless Adventure [pdf] მომხმარებლის სახელმძღვანელო
ESP32-C3 Wireless Adventure, ESP32-C3, Wireless Adventure, Adventure

ცნობები

მომხმარებლის სახელმძღვანელო

ESP32-C3 უსადენო თავგადასავალი