ESP8266 WiFi: Bezpośrednia wymiana danych pomiędzy modułami

Autor: Tomasz Francuz
Redakcja: Dondu

Artykuł jest częścią cyklu: Moduły WiFi

W poprzednim odcinku udało nam się skonfigurować moduł ESP8266 do pracy w Internecie – podłączyliśmy się pod AP (Access Point), pobraliśmy adres, udało się (mam nadzieję) automatycznie dokonać update modułu.

Teraz czas na coś ciekawszego – wymianę danych pomiędzy modułami – w końcu m.in. w tym celu te moduły zakupiliśmy. Jednak zanim wymienimy dane musimy skonfigurować co najmniej dwa moduły WiFi pomiędzy którymi będziemy dane wymieniać.

Ze względu na wygodę oba moduły podłączymy do PC-ta, dzięki czemu łatwo będziemy mogli wysyłać polecenia i obserwować rezultaty. Czyli potrzebujemy dwa moduły z konwerterem RS232-USB.

A czy nie można prościej? Pamiętasz, jak pisałem, że wykorzystanie XMEGA jako konwertera USB-RS232 ma kilka zalet i lepiej w ten sposób podłączyć moduł do PC? Właśnie doszliśmy do jednej z zalet zastosowania XMEGA…

XMEGA jako wielokrotny konwerter USB-RS232

W drugiej części tego cyklu pokazując jak podłączyć ESP8266 do PC pokazałem prosty programik na XMEGA, który zamienia ją w konwerter USB-RS232. Ale XMEGA potrafi znacznie więcej. Jak być może wiesz, USB potrafi obsługiwać tzw. urządzenia złożone – co to takiego?

Normalnie jeśli podłączymy coś do USB to nam się pojawia nowe urządzenie w systemie. Lecz urządzenie USB może być widoczne jako kilka różnych typów urządzeń jednocześnie. W szczególności, kiedy podłączyliśmy XMEGA to pojawił się dodatkowy wirtualny port szeregowy. Ale możemy tak zaprogramować mikrokontroler (a raczej stworzyć taki deskryptor urządzenia USB), że ta sama XMEGA będzie emulowała kilka (1 do nawet 7) portów szeregowych. Ponieważ ten mikrokontroler dysponuje nawet 8 fizycznymi portami UART, możemy zmapować każdy wirtualny port szeregowy na fizyczny interfejs UART, do którego podłączymy moduł ESP8266!

Dzięki temu dwa moduły ESP8266 podłączymy do tej samej XMEGA. Będą one widoczne w systemie jako dwa oddzielne porty szeregowe, poprzez które będziemy się z modułami komunikować. Dzięki temu posiadając jeden komputer i XMEGA podłączymy sobie dwa moduły pomiędzy którymi będziemy wymieniać dane.

Nic nie stoi na przeszkodzie, aby moduły podłączyć do różnych komputerów PC – z tym, że nie jest to zbyt wygodne do testów i nic nam nie daje, poza zwiększeniem bałaganu na biurku.

Oczywiście jeśli nie używasz XMEGA to możesz podłączyć kolejne moduły przez USB przy pomocy innych sposobów, opisanych w części drugiej kursu.

Zacznijmy od części hardwarowej. Potrzebujemy tak jak poprzednio XMEGA podłączoną pod USB. Do USARTC0 tak jak do tej pory podłączymy moduł pierwszy (pin C2 – wyjście TxD modułu, pin C3 wejście RxD modułu), natomiast drugi moduł podłączymy pod USARTD0 (analogicznie pin D2 – wyjście TxD modułu, pin D3 wejście RxD modułu). Nic prostszego.

Pamiętaj, że każdy moduł WiFi może pobierać nawet 200 mA. Stąd też układ należy zasilić z zasilacza o odpowiedniej wydajności – można go także poprzez regulator LDO zasilić bezpośrednio z portu USB, co nam uprości układ.

Hardware mamy za sobą, czas na software. Tu nie będzie jakiś wielkich zmian – jedyne co musimy zrobić to nieznacznie zmodyfikować program pokazany w części drugiej niniejszego cyklu tak, aby XMEGA była widziana jako złożone urządzenie USB, emulujące dwa porty szeregowe.

W tym celu wystarczy w pliku conf_usb.h zmodyfikować linię:

# define  UDI_CDC_PORT_NB 1

 na:

# define  UDI_CDC_PORT_NB 2

Jak łatwo się domyśleć liczba 2 określa, że XMEGA będzie emulowała dwa porty szeregowe.

Jak pisałem XMEGA może emulować maksymalnie 7, co wynika z liczby obsługiwanych tzw. endpointów USB. Jednak nie przesadzaj z liczbą emulowanych portów – nasza implementacja pod każdy port rezerwuje sporo pamięci na bufor nadajnika i odbiornika. Jeśli uruchomimy ich zbyt wiele to tej pamięci nam zabraknie – nie jest to problem, musimy po prostu zmniejszyć wielkość używanych buforów. Ale jak to zrobić pozostawiam dociekliwym czytelnikom… Dość powiedzieć, że spokojnie możemy emulować dwa a nawet więcej wirtualnych portów szeregowych.

Druga zmiana, jaką musimy wprowadzić to modyfikacja identyfikatora PID urządzenia USB. W tym samym pliku dodajemy definicję:

#define  USB_DEVICE_PRODUCT_ID            USB_PID_ATMEL_ASF_TWO_CDC

Będziemy tu bazować na identyfikatorach PID przydzielonych poszczególnym urządzeniom przez firmę Atmel. Niezależnie, czy używamy urządzenia złożonego emulującego dwa, czy więcej porty szeregowe będziemy używać tego samego PID. Driver USB (a tak naprawdę tylko opis dostarczony przez Atmel, gdyż driver urządzeń CDC znajduje się w systemie operacyjnym), radzi sobie sam z taką sytuacją.

Drobna uwaga – jeśli zmienisz liczbę emulowanych portów szeregowych to być może Windows nie zaważy tej zmiany. Dlaczego? Ano twórcy systemu postanowili dodać mu trochę „inteligencji”, w efekcie Windows buforuje deskryptory urządzeń USB. Jeśli podłączymy urządzenie o tym samym VID/PID to Windows zamiast odczytać pełny deskryptor USB użyje deskryptora wcześniej zbuforowanego.

W efekcie, jeśli urządzenie zmieni liczbę emulowanych portów szeregowych to system tego nie zauważy. Rozwiązaniem jest zmiana PID lub odinstalowanie sterownika i ponowna jego instalacja. Jednak w naszym przypadku taki problem nie powinien wystąpić.

Teraz przejdźmy do pliku main.c. Tu musimy dodać po prostu obsługę kolejnego portu szeregowego i przekierowanie danych z USB na odpowiedni moduł. Zacznijmy od prostej tablicy, która mapuje wirtualne porty szeregowe na porty fizyczne w XMEGA:

USART_t *CDCtoUSART[UDI_CDC_PORT_NB]={&USARTC0, &USARTD0};    //Mapowanie kolejnych urządzeń USB CDC na porty USART

W efekcie wirtualny port szeregowy nr 0 będzie mapowany na USARTC0, a wirtualny port szeregowy nr 1 na USARTD0. Teraz czas na ich konfigurację. Tu widać piękno XMEGA w stosunku do starszych AVRów. Ponieważ wszystkie peryferia mają identyczne rejestry, wystarczy napisać jedną funkcję konfiguracyjną:

void usart_cfg(USART_t *usart)
{
 usart->CTRLB=USART_TXEN_bm | USART_RXEN_bm;   //Włącz nadajnik USART
 usart->CTRLC=USART_CHSIZE_8BIT_gc;            //Ramka 8 bitów, bez parzystości, 1 bit stopu
 usart->CTRLA=USART_RXCINTLVL_LO_gc;           //Włącz przerwanie odbiornika USART
}

Teraz po prostu wystarczy ją wywołać dla kolejnych interfejsów USART:

void usart_init()
{
 PORTC_OUTSET=PIN3_bm;
 PORTC_DIRSET=PIN3_bm;                          //Pin TxD musi być wyjściem
 PORTD_OUTSET=PIN3_bm;
 PORTD_DIRSET=PIN3_bm;                          //Pin TxD musi być wyjściem 
 
 usart_cfg(&USARTC0);
 usart_cfg(&USARTD0);
}

Dalej jest już z górki, tak jak poprzednio piszemy funkcje przekazujące odbierane z modułów znaki na odpowiednie wirtualne porty szeregowe:

ISR(USARTC0_RXC_vect)
{
 udi_cdc_multi_putc(0, USARTC0_DATA);
}

ISR(USARTD0_RXC_vect)
{
 udi_cdc_multi_putc(1, USARTD0_DATA);
}

i odwrotnie, kod przekazujący odebrane z PC dane na odpowiednie interfejsy USART:

 while (1)
 {
  if(udi_cdc_multi_is_rx_ready(0))
   USART_putchar(CDCtoUSART[0], udi_cdc_multi_getc(0));  //Przepisz to co otrzymałeś na USART sterujący modułem
  if(udi_cdc_multi_is_rx_ready(1))
   USART_putchar(CDCtoUSART[1], udi_cdc_multi_getc(1));  //Przepisz to co otrzymałeś na USART sterujący modułem
 }

Jak pewne zauważyłeś, zmieniły się nieco funkcje współpracy z USB – używamy udi_cdc_multi_putc zamiast udi_cdc_putc, udi_cdc_multi_is_rx_ready zamiast udi_cdc_is_rx_ready i udi_cdc_multi_getc zamiast udi_cdc_getc. Pomiędzy tymi funkcjami jest tylko jedna różnica - funkcje _multi_ przyjmują jako dodatkowy argument numer emulowanego wirtualnego portu szeregowego (w naszym przypadku będzie to 0 lub 1).

I to tyle – prawda, że proste? Pokazaną obsługę wielu wirtualnych portów szeregowych możemy wykorzystać szerzej, także w swoich aplikacjach – np. jeden port może służyć do normalnej wymiany danych, a drugi do przesyłania informacji o stanie aplikacji – co ułatwia jej debugowanie.


Do pobrania

Do pobrania pełny kod przykładu dla Atmel Studio: ESP-ESP-PC.ZIP (kopia)



Po zaprogramowaniu mikrokontrolera i jego podłączeniu do USB w menagerze urządzeń powinieneś zobaczyć dwa wirtualne porty szeregowe:

Menedżer urządzeń - widok na nowe porty szeregowe

U mnie akurat były to porty COM16 i COM15 (nazywają się one Communication Device Class ASF example2) W twoim przypadku zapewne będą to porty szeregowe o innym numerze. W razie czego numer portu możesz zmienić we właściwościach urządzenia – nam jednak do niczego taka zmiana nie jest potrzebna.

Co dalej?

Aby komunikować się z każdym modułem odpalimy sobie dwie instancje programu RealTerm (lub innego terminala, który używasz). Każdy terminal połączymy z jednym z wirtualnych portów szeregowych:

Terminale połączone z modułami

Dzięki temu w każdym terminalu będą informacje powiązane z jednym z podłączonych do PC-ta modułów ESP8266.

Mamy już podłączone do PC-ta dwa moduły ESP8266 – przy czym nowy moduł jest nieskonfigurowany. Zanim więc przejdziemy dalej musimy go skonfigurować tak jak to robiliśmy w poprzedniej części, czyli:

• przełączyć go w tryb klienta (stacji) WiFi,
• podłączyć go pod AP (access point),
• wykonać update firmware.

Jak to zrobić już wiesz, więc potraktuj konfigurację nowego modułu jako powtórkę i ćwiczenie.
Ponieważ będziemy w dalszej części nawiązywać najprostsze połączenie między dwoma modułami typu point-to-point, wygodniej będzie, jeśli modułom nadamy stałe adresy IP – nie będziemy korzystali z DHCP.

W tym celu pierwszemu modułowi nadamy adres 192.168.1.10, a drugiemu 192.168.1.11 (pamiętasz, że możemy to zrobić poleceniem AT+CIPSTA_DEF):

AT+CIPSTA_DEF="192.168.1.11","192.168.1.1","255.255.255.0"

Oczywiście adresy i maskę podsieci musisz dostosować do swojej konfiguracji sieci. Jeśli używasz innej konfiguracji sieci, to dostosuj do niej wszystkie adresy użyte w tym artykule.

Skoro mamy już skonfigurowane moduły, to przetestujmy, czy się wzajemnie „widzą”. W tym celu na jednym z modułów użyjemy bardzo pomocnego polecenia ping podając adres drugiego modułu:

AT+PING="192.168.1.10"

Jeśli wszystko jest ok, to dostaniemy odpowiedź:

+PING="192.168.1.10" +9
                                                                                
OK

Jeśli pomiędzy modułami nie ma łączności to uzyskamy:

+PING="192.168.1.10" +TIMEOUT
                                                                                
ERROR

Czym błąd może być spowodowany? Przede wszystkim:

• brakiem podłączenia do AP,
• złą konfiguracją sieci (błędny adres IP, błędna maska podsieci),
• niewłaściwą konfiguracją modułu,
• jeszcze jedną potencjalną przyczyną może być po prostu brak zasięgu – to łatwo sprawdzisz listując lokalne AP i sprawdzając parametr RSSI o którym pisałem w poprzedniej części. Niewykluczone też, że w przypadku braku zasięgu moduł po prostu nie zobaczy na liście naszego AP.
• kiepskim zasilaniem modułu. Pamiętaj, że dwa moduły pobierają impulsowo ponad 400 mA, napięcie musi być dobrze filtrowane – wszelkie zakłócenia znacznie ograniczają zasięg modułu.

Połączenie można sprawdzić znanym nam już poleceniem AT+CIPSTATUS, oba moduły powinny zwrócić:

+CIPSTATUS STATUS:2
                                                                                
OK

Znaczenie statusów:

• Status 2 oznacza, że moduł jest połączony z AP i ma prawidłowy adres IP.
• Status 3 oznacza, że jest połączony z AP, ale nie ma adresu IP (albo go nie ustawiliśmy, albo nie działa serwer DHCP), 
• Status 4 oznacza, że moduł nie jest połączony z AP. Oczywiście prawidłowe połączenie nie wyklucza błędnej konfiguracji sieci (adresu IP lub maski) – zawsze to dodatkowo musimy sprawdzić.

W końcu przesyłamy dane

Doszliśmy do momentu, w którym jesteśmy gotowi po raz pierwszy przesłać dane pomiędzy dwoma modułami. Aby zrozumieć nawiązywanie połączeń musimy dowiedzieć się czegoś więcej o komunikacji w sieci TCP/IP.

Urządzenia w sieci udostępniają tzw. usługi – taką usługa jest np. http, ftp, itd. Wiemy, że żeby połączyć się z jakąś stroną www musi ona być umieszczona na serwerze http. Nie inaczej jest w przypadku, gdy wymieniamy dane. Urządzenie (klient) wysyła je do innego urządzenia (serwer). Aby było to możliwe serwer musi nasłuchiwać połączeń ze strony klienta.

Musimy więc nasz moduł skonfigurować tak, aby nasłuchiwał połączeń. W sieci TCP/IP każde urządzenie ma do dyspozycji 65536 portów (numerowane 0-65535). Nasz serwer może nasłuchiwać na dowolnym z nich – no prawie dowolnym. Musimy pamiętać, że porty poniżej 1024 to porty specjalne, mające przypisane określone usługi, np. port 80 to http. Możemy je wykorzystać lecz musimy się liczyć z tym, że np. klient http (dowolna przeglądarka) będzie oczekiwać, że na tym porcie nasłuchuje serwer www. Ale to właściwie żaden problem.

Konfiguracja serwera

Zacznijmy od konfiguracji serwera – czyli modułu, który będzie oczekiwał na dane przesyłane z innych modułów – klientów. W tym celu musimy poznać parę nowych poleceń AT.

Aby było możliwe utworzenie serwera, moduł na którym chcemy to zrobić musi mieć możliwość przyjmowania wielu połączeń – w końcu do serwera może łączyć się wielu klientów, prawda? W tym celu wysyłamy polecenie:

AT+CIPMUX=1

na co moduł powinien odpowiedzieć:

+CIPMUX=1                                                                             
OK

Teraz czas na uruchomienie serwera, w naszym przypadku będzie nasłuchiwać na porcie 81:

AT+CIPSERVER=1,81

na co otrzymujemy:

IPSERVER=1,81                                                                                 
OK

Od tego momentu nasz serwer nasłuchuje na porcie 81. Łatwo możemy się o tym przekonać – w tym celu uruchamiamy przeglądarkę i w pasku adresu wpisujemy:

192.168.1.10:81

Powyższy adres to adres IP modułu, na którym uruchomiliśmy serwer, a 81 to port, na którym nasłuchuje. W efekcie w terminalu połączonym z serwerem zobaczymy informację o nawiązaniu połączenia:

0,CONNECT

i przesłane przez przeglądarkę dane:

+IPD,0,289:GET / HTTP/1.1
HOST: 192.168.1.10:81
USER-AGENT: MOZILLA/5.0 (WINDOWS NT 6.1; WOW64; RV:38.0) GECKO/20100101 FIREFOX/
38.0
ACCEPT: TEXT/HTML,APPLICATION/XHTML+XML,APPLICATION/XML;Q=0.9,*/*;Q=0.8
ACCEPT-LANGUAGE: EN-US,EN;Q=0.5
ACCEPT-ENCODING: GZIP, DEFLATE
CONNECTION: KEEP-ALIVE

W informacji o połączeniu widzimy, że połączenie zostało nawiązane (CONNECT), oraz otrzymujemy identyfikator połączenia – w tym przypadku 0. Identyfikator połączenia jest dla nas niezbędny – pamiętamy, że z serwerem na raz może łączyć się wiele klientów. Żeby wiedzieć które dane skąd pochodzą potrzebujemy identyfikator.

Kolejna część to dane przesłane przez przeglądarkę – są one poprzedzone nagłówkiem +IPD,0,289:

Co on oznacza?

• +IPD - informuje nas, że mamy połączenie, w którym przesłano dane (IP data), 
• 0 - identyfikator połączenia wynosi 0, 
• 289 - to łączna liczba odebranych bajtów. Po dwukropku znajdują się dane wysłane przez przeglądarkę. Teraz, jeśli zamkniemy okno przeglądarki lub naciśniemy przycisk przerwania połączenia, moduł wyśle informację:

0,CLOSED

czyli że połączenie o identyfikatorze 0 zostało zamknięte (CLOSED).

Jeśli z modułem połączą się kolejni klienci to uzyskają oni kolejne identyfikatory, a więc 1, 2, 3, itd.

Pamiętaj jednak, że sam identyfikator nie identyfikuje jednoznacznie klienta – jeśli połączenie zostanie zamknięte, to kolejny klient dostanie ten sam identyfikator. Musimy więc śledzić stan połączeń, lub stosować inne metody, o których napiszę później.

Proste, prawda? A więc serwer mamy skonfigurowany, czas na klienta.

Konfiguracja klienta

Konfiguracja klienta jest równie prosta. Najpierw musimy nawiązać połączenie, my zrobimy transparentny most RS232-WiFi przy pomocy protokołu TCP (o tym nieco więcej będzie w przyszłości):

AT+CIPSTART="TCP","192.168.1.10",81

Podany adres IP to adres naszego serwera, który konfigurowaliśmy w poprzednim kroku, a 81 to oczywiście port, na którym nasłuchuje. W odpowiedzi uzyskujemy:

+CIPSTART="TCP","192.168.1.10",333                                            
CONNECT
                                                                       
OK

Od tej chwili mamy połączenie z serwerem, o czym nas serwer informuje wyświetlając w jego terminalu:

0,CONNECT

Teraz musimy nasze połączenie skonfigurować. Ponieważ robimy transparentny most, to wybieramy odpowiednią opcję:

AT+CIPMODE=1

co informuje, że przesyłamy dane tak jak lecą (pass through). Od tej chwili możemy przesyłać dane. W tym celu wydajemy jeszcze jedno polecenie:

AT+CIPSEND

Po jego wydaniu zobaczymy w terminalu znak zachęty ‘>’ – od tej chwili wszystko, co wpiszemy do terminala zostanie przesłane do serwera.

Pamiętaj, że wysyłając komendy AT automatycznie dołączaliśmy do nich znaki CR+LF. Przy przesyłaniu danych nie chcemy tego robić – odznacz więc odpowiednią opcję w terminalu.

Wpiszmy w terminalu klienta:

NA SERWERZE POJAWIA SIE WPISANY TU TEKST

W terminalu serwera powinniśmy zobaczyć:

+IPD,0,42:NA SERWERZE POJAWIA SIE WPISANY TU TEKST

czyli ponownie +IPD,0,42: informuje nas, że otrzymaliśmy informację z ID połączenia 0 o długości 42 bajtów i dalej znajdują się przesłane dane.

W tym trybie klient przesyła do serwera wszystko, co mu wyślemy przez interfejs UART. Doskonale się to nadaje do przesyłania danych. Stworzyliśmy więc most radiowy, po którym przesyłamy dane.

A jak wrócić do trybu poleceń AT? 

W tym celu musimy nadać +++ ale co ważne znaki te muszą być poprzedzone co najmniej jednosekundową przerwą w nadawaniu, po nich też przez sekundę nic nie możemy do modułu wysłać. Pamiętaj, aby po +++ nie wysyłać znaków CR+LF – jeśli je wyślemy to polecenie nie zostanie zinterpretowane jako koniec transmisji danych.

Po wysłaniu +++ na serwerze nic się nie pojawi – nie jest też kończone połączenie – jedyne co osiągnęliśmy to wyjście klienta z trybu przesyłania danych i przejście ponownie w tryb poleceń AT. Aby zakończyć połączenie musimy je jawnie zamknąć:

AT+CIPCLOSE

co spowoduje w terminalu klienta wyświetlenie:

+CIPCLOSE CLOSED
                                                                      
OK

A na terminalu serwera:

0,CLOSED

Proste, prawda? Oczywiście to nie koniec możliwości przesyłania danych, ale jak na pierwszy raz wystarczy. W kolejnym odcinku coś więcej o typach połączeń i pakietach.