ESP8266 Direkte datakommunikasie: 3 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:26

Inleiding

Terwyl ek 'n paar projekte met Arduinos en nRF24l01 modules gedoen het, het ek gewonder of ek moeite kon bespaar deur eerder 'n ESP8266 -module te gebruik. Die voordeel van die ESP8266 -module is dat dit 'n mikrobeheerder aan boord bevat, dus is geen bykomende Arduino -bord nodig nie. Boonop is die geheue grootte van die ESP8266 baie groter en wat spoed betref, loop die ESP8266 op maksimum 160MHz in plaas van die Arduino se 16MHz. Daar is natuurlik 'n paar negatiewe kante.

Die ESP8266 werk slegs op 3.3V, het minder penne en ontbreek die goeie analoog insette wat die Arduino het (dit het een, maar slegs vir 1.0V en nie 3.3V). Boonop is daar baie meer kodevoorbeelde vir die Arduino + nRF24l01, dan is dit ook vir die ESP8266, veral as dit kom by direkte data -oordrag.

Met 'n projek in gedagte, het ek die onderwerp van 'n vinnige en ligte data -oordrag tussen twee ESP8266 ondersoek sonder al die WWW- en HTTP -goed.

Terwyl ek op die internet na voorbeelde gesoek het (die meeste van die onderstaande kode is op verskillende plekke uit die internet gekies), het ek baie vrae teëgekom oor hoe om 'n direkte data -oordrag te implementeer sonder die goeie "doen dit so" voorbeelde. Daar was 'n voorbeeldkode, maar meestal met die vraag waarom dit nie werk nie.

Na 'n bietjie lees en probeer verstaan, het ek die onderstaande voorbeelde geskep wat 'n vinnige en eenvoudige oordrag van data tussen twee ESP8266 moontlik maak.

Stap 1: Grense en agtergronde (TCP vs UDP)

Om daar te kom, moet sommige grense duidelik gemaak word in vergelyking met die nRF24l01.

Om die ESP8266 binne die Arduino -omgewing te gebruik, is die basiese biblioteek die ESP8266WiFi.h. Dit kan anders wees, maar die meeste voorbeelde gebruik die genoemde. As u dit gebruik, moet u u kommunikasie op WiFi -vlak bring.

Dus, om te kommunikeer, moet daar ten minste 'n toegangspunt (AP) / bediener en 'n kliënt wees. Die AP verskaf die naam van die netwerk en die IP -adresse, en die kliënt sal met hierdie bediener skakel.

In vergelyking met die nRF24l01, waar die kode aan beide kante min of meer dieselfde is (behalwe vir die transmissiekanale), is die kode van die ESP8266 fundamenteel anders, aangesien die een as AP gekonfigureer is en die ander as kliënt.

Die volgende onderwerp is dat in plaas van net 'n paar grepe na die nRF24l01 te stuur, die oordragprotokolle van ESP8266 in ag geneem moet word.

Daar is twee algemene protokolle: TCP en UDP.

Die TCP (Transmission Control Protocol) is 'n protokol wat 'n verliesvrye oordrag tussen 'n bediener en 'n kliënt moontlik maak. Die protokol bevat 'handdrukke' (baie vlae en aflewerings wat tussen beide partye gestuur word) en pakkienummering en -opsporing om verlore pakkies te identifiseer en weer oor te dra. Deur al hierdie handdrukke te gebruik, voorkom die protokol dat data verlore gaan weens baie pakkies wat op dieselfde tyd in die netwerk gestuur word. Datapakkies wag totdat dit ontvang kan word.

Die UDP (User Datagram Protocol) ontbreek alle handdrukke, pakkienommering en heruitsending. Die bokoste daarvan is dus kleiner en dit is nie nodig dat al die handdrukke 'n verbinding het nie. UDP bevat basiese foutopsporing, maar geen regstelling nie (die beskadigde pakket word net laat val). Data word gestuur, sonder die medewete as die ontvangende party vry is om die data te ontvang. Terselfdertyd kan verskeie pakkies bots, aangesien elke party die data stuur wanneer dit nodig is. Deur al die handdrukke weg te laat, is daar nog 'n goeie funksie van UDP genaamd 'multicast' en 'broadcast'. In die 'multicast' -geval word datapakkies na 'n voorafbepaalde groep lede gestuur, in 'n' uitsending 'word datapakkies na alle gekoppelde lede gestuur. Dit verminder data -oordrag aansienlik as strome deur verskeie lede ontvang moet word (byvoorbeeld deur 'n videostroom na verskeie ontvangers te stuur of deur die huidige tyd na verskeie gekoppelde toestelle te stuur).

Daar is 'n paar goeie video's op Youtube wat dit nog beter verduidelik.

By die stuur van data is dit dus belangrik om u behoeftes te ken:

• onbeskadigde data, bestuur van verskeie eweknieë deur handdruk → TCP
• intydse data, vinnige verbinding → UDP

Ek het eers begin met die implementering van 'n TCP -gebaseerde kommunikasie (tussen een bediener en een kliënt). Tydens die toets daarvan het ek probleme met die oordrag gehad. Aan die begin is die data vinnig uitgeruil, en na 'n rukkie het die snelheid dramaties gedaal. Ek het tot die gevolgtrekking gekom dat dit 'n tipiese probleem van die TCP -benadering was (wat verkeerd was!), En toe verander na 'n oplossing gebaseer op UDP. Uiteindelik het ek albei genader om te werk. Dus sal beide oplossings verskaf word.

Die sketse hieronder het vir TCP en UDP gemeen dat hulle:

• is onafhanklik van enige bestaande WiFi -netwerk. Dit sal dus oral ver van die internet en gekoppelde routers werk.
• stuur ASCII -data om via die seriële monitor gedruk te word.
• stuur data wat verkry is deur die millis ()-funksie, om die snelheid van die transmissie te ontleed.
• word nie vir meer as een kliënt getoets nie (omdat hulle oor die hardeware beskik om die netwerk op te stel)

Stap 2: Hardeware

Om die hele opstelling te toets, het ek twee ESP8266 -modules gebruik. Een module is 'n ESP-01 + USB-na-UART-adapter. Die ander module is 'n ESP-12-gebaseerde module met die USB-aansluiting, spanningsreguleerder en 'n paar lekker dinge soos skakelaars, LDR en veelkleurige LED.

Die USB-na-UART-module vir die ESP-01 moes 'n bietjie gewysig word om dit as programmeerder te kan gebruik (weer Youtube deur Csongor Varga).

Om die sketse uit te voer, moet u die ESP8266 -biblioteke installeer (soos op baie plekke op die internet beskryf). In beide gevalle (TCP en UDP) is daar elk 'n bediener- en kliëntskets. Watter skets word gelaai na watter module maak nie saak nie.

Erkennings

Soos genoem, is die sketse gebaseer op baie stukke wat ek op die internet gevind het. Ek kan nie meer onthou waar ek wat gekry het nie, en wat die oorspronklike kode is of wat ek verander het. Dus wou ek net dankie sê aan die groot gemeenskap in die algemeen wat al die goeie voorbeelde gepubliseer het.

Stap 3: Die sketse

Die kode bestaan uit twee sketse elk (soos verduidelik), 'n bedienerskets en kliëntskets, elk vir TCP en UDP.