ESP8266 Direkt datakommunikation: 3 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

Introduktion

Medan jag gjorde några projekt med Arduinos och nRF24l01 -moduler undrade jag om jag kunde spara lite ansträngning genom att använda en ESP8266 -modul istället. Fördelen med ESP8266 -modulen är att den innehåller en mikrokontroller ombord, så inget extra Arduino -kort behövs. Dessutom är minnesstorleken på ESP8266 mycket större och med avseende på hastigheten kör ESP8266 på max 160MHz istället för Arduino's 16MHz. Naturligtvis finns det några negativa sidor.

ESP8266 körs bara på 3.3V, har färre stift och saknar de fina analoga ingångarna som Arduino har (den har en, men bara för 1.0V och inte 3.3V). Dessutom finns det många fler kodexempel för Arduino + nRF24l01 än det finns för ESP8266, särskilt när det gäller direkt dataöverföring.

Så med ett projekt i åtanke tittade jag på ämnet snabb och lätt dataöverföring mellan två ESP8266 utan alla WWW- och HTTP -saker.

När jag sökte på internet efter exempel (de flesta av nedanstående kod plockades från nätet på olika ställen) stötte jag på många frågor om hur man genomför en direkt dataöverföring utan de fina "gör så här" -exemplen. Det fanns någon exempelkod, men mestadels med frågan varför den inte fungerade.

Så efter lite läsning och försök att förstå skapade jag nedanstående exempel som möjliggör snabb och enkel överföring av data mellan två ESP8266.

Steg 1: Gränser och bakgrunder (TCP vs UDP)

För att komma dit måste vissa gränser förtydligas jämfört med nRF24l01.

För att använda ESP8266 inom Arduino -miljön är det grundläggande biblioteket ESP8266WiFi.h. Det kan vara olika, men de flesta exemplen använder det som nämns på. När du använder detta måste du få din kommunikation till WiFi -nivå.

Så för att kommunicera måste det finnas åtminstone en åtkomstpunkt (AP) / server och en klient. AP tillhandahåller namnet på nätverket och IP -adresserna och klienten kommer att ansluta till den här servern.

Så jämförde nRF24l01, där koden i båda ändar är mer eller mindre densamma (förutom överföringskanalerna) är koden för ESP8266 fundamentalt annorlunda, eftersom den ena är konfigurerad som AP och den andra som klient.

Nästa ämne är att istället för att bara skicka några byte till nRF24l01, måste ESP8266 överföringsprotokoll observeras.

Det finns två vanliga protokoll: TCP och UDP.

TCP (Transmission Control Protocol) är ett protokoll som tillåter en förlustfri överföring mellan en server och en klient. Protokollet innehåller”handskakningar” (massor av flaggor och acknoledges som skickas mellan båda parter) och paketnummerering och upptäckt för att identifiera och vidarebefordra förlorade paket. Genom att använda alla dessa handskakningar förhindrar protokollet dessutom data som går förlorade på grund av många paket som skickas samtidigt i nätverket. Datapaket väntar tills de kan tas emot.

UDP (User Datagram Protocol) saknar alla handskakningar, paketnummerering och återöverföring. Dess overhead är därför mindre och det behövs inte alla handskakningar för att upprätthålla en anslutning. UDP innehåller en del grundläggande feldetektering, men ingen korrigering (det skadade paketet har bara tappats). Data skickas, utan att veta om den mottagande parten är fri att ta emot data. Samtidigt kan flera paket kollidera, eftersom varje part skickar data när det behövs. Genom att utelämna alla handslag finns det ytterligare en trevlig funktion i UDP som kallas "multicast" och "broadcast". I fallet "multicast" skickas datapaket till en fördefinierad grupp medlemmar, i en "broadcast" skickas datapaket till alla anslutna medlemmar. Detta minskar dataöverföringen avsevärt vid strömmar som ska tas emot av flera medlemmar (t.ex. genom att skicka ett videoflöde till flera mottagare eller genom att skicka den aktuella tiden till flera anslutna enheter).

Det finns några bra videor på Youtube som förklarar det ännu bättre.

Så när du skickar data är det viktigt att känna till dina behov:

• okorrekt data, hantering av flera kamrater genom handslag → TCP
• realtidsdata, snabb anslutning → UDP

Jag började först med implementeringen av en TCP -baserad kommunikation (mellan en server och en klient). När jag testade det hade jag stallningsproblem i överföringen. I början utbyttes data snabbt, sedan efter ett tag sjönk hastigheten dramatiskt. Jag drog slutsatsen att detta var ett typiskt problem med TCP -metoden (vilket var fel!), Så bytte sedan till en lösning baserad på UDP. Slutligen fick jag båda kontaktade arbetet. Så båda lösningarna kommer att tillhandahållas.

Skisser nedan har för TCP och UDP gemensamt att de:

• är oberoende av alla befintliga WiFi -nätverk. Så det kommer att fungera var som helst långt från internet och anslutna routrar.
• skickar ASCII -data som ska skrivas ut via den seriella bildskärmen.
• skickar data som erhållits med millis ()-funktionen för att analysera överföringshastigheten.
• testas inte för flera klienter (på grund av att de har hårdvara för att konfigurera nätverket just nu)

Steg 2: Hårdvara

För att testa hela konfigurationen använde jag två ESP8266 -moduler. En modul är en ESP-01 + USB-till-UART-adapter. Den andra modulen är en ESP-12-baserad modul som innehåller USB-anslutning, spänningsregulator och några roliga saker som switchar, LDR och flerfärgad LED.

USB-till-UART-modulen för ESP-01 behövde modifieras lite för att kunna använda den som programmerare (igen Youtube av Csongor Varga).

För att köra skisserna måste du installera ESP8266 -biblioteken (som beskrivs på många ställen på internet). I båda fallen (TCP och UDP) finns det en server- och klientskiss. Vilken skiss som laddas till vilken modul spelar ingen roll.

Kvitteringar

Som nämnts är skisserna baserade på många bitar som jag hittade på webben. Jag kommer inte längre ihåg var jag hittade vad, och vad är originalkoden eller vad jag ändrade. Så jag ville bara tacka det stora samhället i allmänhet där ute för att publicera alla bra exempel.

Steg 3: Skisserna

Koden består av två skisser vardera (enligt förklaringen), en serverskiss och klientskiss, vardera för TCP och UDP.