ESP8266 bezpośrednia transmisja danych: 3 kroki

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:31

Wstęp

Wykonując kilka projektów z modułami Arduinos i nRF24l01, zastanawiałem się, czy mógłbym zaoszczędzić trochę wysiłku, używając zamiast tego modułu ESP8266. Zaletą modułu ESP8266 jest to, że na płycie znajduje się mikrokontroler, dzięki czemu nie jest potrzebna dodatkowa płytka Arduino. Dodatkowo rozmiar pamięci ESP8266 jest znacznie większy i pod względem szybkości ESP8266 pracuje z maksymalną prędkością 160 MHz zamiast 16 MHz Arduino. Oczywiście są pewne negatywne strony.

ESP8266 działa tylko na 3,3 V, ma mniej pinów i brakuje mu ładnych wejść analogowych, które ma Arduino (ma jedno, ale tylko na 1,0 V, a nie 3,3 V). Dodatkowo istnieje o wiele więcej przykładów kodu dla Arduino + nRF24l01 niż dla ESP8266, szczególnie jeśli chodzi o bezpośredni transfer danych.

Mając więc na uwadze projekt, przyjrzałem się tematowi szybkiego i lekkiego transferu danych między dwoma ESP8266 bez wszystkich rzeczy WWW i

Szukając przykładów w internecie (większość poniższego kodu została pobrana z sieci w różnych miejscach) natknąłem się na wiele pytań, jak zaimplementować bezpośredni transfer danych bez ładnych przykładów „zrób to w ten sposób”. Był jakiś przykładowy kod, ale głównie z pytaniem, dlaczego nie działa.

Więc po pewnym czytaniu i próbie zrozumienia stworzyłem poniższe przykłady, które pozwalają na szybki i prosty transfer danych pomiędzy dwoma ESP8266.

Krok 1: Granice i tła (TCP vs. UDP)

Aby się tam dostać, niektóre granice muszą zostać wyjaśnione w porównaniu z nRF24l01.

Aby korzystać z ESP8266 w środowisku Arduino, podstawową biblioteką do użycia jest ESP8266WiFi.h. Mogą być różne, ale większość przykładów korzysta z wymienionych dalej. Korzystając z tego, musisz uzyskać komunikację na poziomie Wi-Fi.

Tak więc do komunikacji potrzebny jest przynajmniej punkt dostępowy (AP) / serwer i klient. Punkt dostępowy podaje nazwę sieci i adresy IP, a klient połączy się z tym serwerem.

Tak więc w porównaniu z nRF24l01, gdzie kod na obu końcach jest mniej więcej taki sam (poza kanałami transmisyjnymi), kod ESP8266 jest zasadniczo inny, ponieważ jeden jest skonfigurowany jako AP, a drugi jako klient.

Kolejnym tematem jest to, że zamiast po prostu wysyłać kilka bajtów do nRF24l01, należy przestrzegać protokołów transmisji ESP8266.

Istnieją dwa powszechnie używane protokoły: TCP i UDP.

TCP (Transmission Control Protocol) to protokół, który umożliwia bezstratną transmisję między serwerem a klientem. Protokół zawiera „uściski dłoni” (wiele flag i potwierdzeń wysyłanych między obiema stronami) oraz numerację i wykrywanie pakietów w celu identyfikacji i ponownej transmisji utraconych pakietów. Dodatkowo, wykorzystując wszystkie te uściski dłoni, protokół zapobiega utracie danych z powodu wielu pakietów wysyłanych jednocześnie w sieci. Pakiety danych czekają, aż będą mogły zostać odebrane.

W protokole UDP (User Datagram Protocol) brakuje wszystkich uścisków dłoni, numeracji pakietów i retransmisji. Jego narzut jest zatem mniejszy i nie ma potrzeby wykonywania wszystkich uścisków dłoni, aby utrzymać połączenie. UDP zawiera kilka podstawowych funkcji wykrywania błędów, ale bez korekty (uszkodzony pakiet jest po prostu usuwany). Dane są przesyłane bez wiedzy o tym, czy odbiorca ma swobodę ich odbioru. Jednocześnie może dojść do kolizji wielu pakietów, ponieważ każda ze stron wysyła dane zawsze, gdy jest to potrzebne. Pomijając wszystkie uściski dłoni, istnieje jedna dodatkowa fajna funkcja UDP o nazwie „multicast” i „broadcast”. W przypadku „multicast” pakiety danych są wysyłane do predefiniowanej grupy członków, w przypadku „broadcast” pakiety danych są wysyłane do wszystkich połączonych członków. Zmniejsza to znacznie transfer danych w przypadku strumieni, które mają być odbierane przez wielu członków (np. wysyłając obraz wideo do wielu odbiorników lub wysyłając aktualny czas do wielu podłączonych urządzeń).

Na Youtube jest kilka dobrych filmów, które wyjaśniają to jeszcze lepiej.

Dlatego wysyłając dane, ważne jest, aby znać swoje potrzeby:

• nieuszkodzone dane, zarządzanie wieloma peerami przez uzgadnianie → TCP
• dane w czasie rzeczywistym, szybkie połączenie → UDP

Najpierw zacząłem od implementacji komunikacji opartej na TCP (pomiędzy jednym serwerem a jednym klientem). Podczas testowania miałem problemy z przeciąganiem transmisji. Na początku dane były wymieniane szybko, a po chwili prędkość drastycznie spadła. Doszedłem do wniosku, że jest to typowy problem podejścia TCP (co było błędne!), więc przeszedłem na rozwiązanie oparte na UDP. W końcu obaj podeszli do pracy. Więc oba rozwiązania zostaną dostarczone.

Poniższe szkice mają wspólne dla TCP i UDP to, że:

• są niezależne od istniejącej sieci WiFi. Dzięki temu będzie działać w dowolnym miejscu z dala od Internetu i podłączonych routerów.
• wysyłają dane ASCII do wydrukowania przez monitor szeregowy.
• wysyłają dane uzyskane przez funkcję millis(), aby przeanalizować prędkość transmisji.
• nie są testowane dla wielu klientów (ze względu na posiadanie sprzętu do skonfigurowania sieci w tej chwili)

Krok 2: Sprzęt

Do przetestowania całego zestawu użyłem dwóch modułów ESP8266. Jeden moduł to przejściówka ESP-01 + USB-do-UART. Drugi moduł to moduł oparty na ESP-12, zawierający złącze USB, regulator napięcia i kilka zabawnych rzeczy, takich jak przełączniki, LDR i wielokolorowa dioda LED.

Moduł USB-to-UART dla ESP-01 musiał zostać nieco zmodyfikowany, aby móc używać go jako programatora (znowu Youtube by Csongor Varga).

Aby uruchomić szkice należy zainstalować biblioteki ESP8266 (opisane w wielu miejscach w internecie). W obu przypadkach (TCP i UDP) istnieje szkic serwera i klienta. Nie ma znaczenia, który szkic jest wczytany do którego modułu.

Podziękowanie

Jak wspomniałem, szkice są oparte na wielu fragmentach, które znalazłem w sieci. Już nie pamiętam gdzie co znalazłem, a jaki jest oryginalny kod lub co zmieniłem. Chciałem więc podziękować całej dużej społeczności za opublikowanie wszystkich wspaniałych przykładów.

Krok 3: Szkice

Kodeks składa się z dwóch szkiców (jak wyjaśniono), szkicu serwera i szkicu klienta, dla każdego protokołu TCP i UDP.