ESP8266 Közvetlen adatkommunikáció: 3 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:42

Bevezetés

Míg néhány projektet elvégeztem az Arduinos és az nRF24l01 modulokkal, azon tűnődtem, vajon spórolhatnék -e némi erőfeszítéssel az ESP8266 modul használatával. Az ESP8266 modul előnye, hogy mikrovezérlőt tartalmaz a fedélzeten, így nincs szükség további Arduino kártyára. Ezenkívül az ESP8266 memória mérete sokkal nagyobb, és a sebesség tekintetében az ESP8266 legfeljebb 160 MHz -en működik az Arduino 16 MHz -je helyett. Természetesen vannak negatív oldalai is.

Az ESP8266 csak 3,3 V -on működik, kevesebb tűvel rendelkezik, és hiányzik az Arduino szép analóg bemenete (van egy, de csak 1,0 V -os és nem 3,3 V -os). Ezenkívül sokkal több példa létezik az Arduino + nRF24l01 -re, majd az ESP8266 -ra, különösen a közvetlen adatátvitel esetében.

Tehát egy projektet szem előtt tartva vizsgáltam a gyors és könnyű adatátvitel témáját két ESP8266 között, minden WWW és HTTP cucc nélkül.

Miközben az interneten kerestem példákat (az alábbi kód nagy részét a netről vették fel különböző helyeken), sok kérdés merült fel bennem, hogyan lehet megvalósítani a közvetlen adatátvitelt a szép "csináld így" példák nélkül. Volt néhány példakód, de leginkább azzal a kérdéssel, hogy miért nem működik.

Így némi olvasás és megértés után létrehoztam az alábbi példákat, amelyek lehetővé teszik az adatok gyors és egyszerű átvitelét két ESP8266 között.

1. lépés: Határok és hátterek (TCP vs. UDP)

Ahhoz, hogy eljussunk, bizonyos határokat tisztázni kell az nRF24l01 -hez képest.

Az ESP8266 Arduino környezetben történő használatához az alapkönyvtár az ESP8266WiFi.h. Lehet, hogy különbözőek, de a legtöbb példa a fentieket használja. Ennek használatakor a kommunikációt WiFi szintre kell hozni.

Tehát a kommunikációhoz legalább hozzáférési pontnak (AP) / szervernek és ügyfélnek kell lennie. Az AP megadja a hálózat nevét és az IP -címeket, és az ügyfél csatlakozik ehhez a szerverhez.

Tehát összehasonlítva az nRF24l01 -et, ahol a kód mindkét végén nagyjából megegyezik (kivéve az átviteli csatornákat), az ESP8266 kódja alapvetően különbözik, mivel az egyik AP -ként, a másik kliensként van konfigurálva.

A következő téma az, hogy ahelyett, hogy csak néhány bájtot küldenénk az nRF24l01 -re, az ESP8266 átviteli protokollokat kell betartani.

Két általánosan használt protokoll létezik: TCP és UDP.

A TCP (Transmission Control Protocol) egy protokoll, amely lehetővé teszi a veszteségmentes átvitelt a szerver és az ügyfél között. A protokoll magában foglalja a „kézfogásokat” (sok zászlót és elismerést mindkét fél között), valamint a csomagok számozását és észlelését az elveszett csomagok azonosítására és továbbítására. Ezenkívül mindezen kézfogások használatával a protokoll megakadályozza az adatok elvesztését a hálózaton egyszerre küldött sok csomag miatt. Az adatcsomagok megvárják, amíg meg nem érkeznek.

Az UDP-ből (User Datagram Protocol) hiányzik az összes kézfogás, csomagszámozás és újraküldés. A rezsi tehát kisebb, és nincs szükség minden kézfogásra a kapcsolat fenntartásához. Az UDP tartalmaz néhány alapvető hibafelismerést, de nincs javítás (a sérült csomag csak leesett). Az adatok elküldésre kerülnek, anélkül, hogy tudnánk, hogy a fogadó fél szabadon fogadhatja -e az adatokat. Ugyanakkor több csomag is ütközhet, mivel minden fél elküldi az adatokat, amikor szükség van rájuk. Az összes kézfogás kihagyásával az UDP egy további szép tulajdonsága, a „multicast” és a „broadcast”. A „multicast” esetben az adatcsomagokat a tagok előre meghatározott csoportjába küldik, a „broadcast” adatcsomagokat pedig az összes csatlakoztatott tagnak. Ez jelentősen csökkenti az adatátvitelt abban az esetben, ha a streameket több tag fogadja (pl. Egy videotáblázat több vevőre történő elküldésével vagy az aktuális idő elküldésével több csatlakoztatott eszközre).

Van néhány jó videó a Youtube -on, amelyek még jobban elmagyarázzák.

Tehát az adatok küldésekor fontos, hogy ismerje igényeit:

• nem sérült adatok, több társ kezelése kézfogással → TCP
• valós idejű adatok, gyors kapcsolat → UDP

Először egy TCP -alapú kommunikáció megvalósításával kezdtem (egy szerver és egy ügyfél között). A tesztelés során akadtak problémák az átvitelben. Az elején gyorsan kicserélték az adatokat, majd egy idő után a sebesség drámaian csökkent. Arra a következtetésre jutottam, hogy ez a TCP -megközelítés tipikus problémája (ami rossz volt!), Ezért azután UDP -n alapuló megoldásra váltottam. Végül mindkettőt megközelítettem, hogy dolgozom. Tehát mindkét megoldás megtalálható lesz.

Az alábbi vázlatok közösek a TCP és az UDP vonatkozásában:

• függetlenek minden létező WiFi hálózattól. Tehát az internettől és a csatlakoztatott útválasztóktól távol bárhol működni fog.
• ASCII adatokat küldenek nyomtatásra a soros monitoron keresztül.
• a millis () függvény által kapott adatokat küldik az átviteli sebesség elemzéséhez.
• nincs tesztelve több ügyfél számára (mivel a hardver a hálózat beállításához szükséges)

2. lépés: Hardver

A teljes beállítás teszteléséhez két ESP8266 modult használtam. Az egyik modul egy ESP-01 + USB-UART adapter. A másik modul egy ESP-12 alapú modul, amely tartalmazza az USB csatlakozást, a feszültségszabályozót és néhány szórakoztató dolgot, például kapcsolókat, LDR-t és többszínű LED-et.

Az ESP-01 USB-UART modulját kicsit módosítani kellett, hogy programozóként lehessen használni (ismét Varga Csongor Youtube-ja).

A vázlatok futtatásához telepítenie kell az ESP8266 könyvtárakat (az internet sok helyén leírtak szerint). Mindkét esetben (TCP és UDP) van egy -egy szerver- és kliensvázlat. Nem mindegy, hogy melyik vázlat melyik modulhoz van betöltve.

Köszönetnyilvánítás

Amint már említettük, a vázlatok sok olyan részen alapulnak, amelyeket a weben találtam. Már nem emlékszem, hogy hol találtam mit, és mi az eredeti kód, vagy mit változtattam. Szóval csak azt akartam megköszönni a nagy közösségnek általában, hogy közzétették az összes nagyszerű példát.

3. lépés: A vázlatok

A kód két vázlatból áll (a magyarázat szerint), egy szervervázlatból és egy ügyfélvázlatból, mind a TCP, mind az UDP számára.