WiFi 250km - Nowy rekord Polski

Autor: Dondu

... a było to tak:

Kuba Jochimiak z Wydziału Elektroniki Politechniki Wrocławskiej.
Postanowiliśmy sprawdzić, na jakim najdłuższym dystansie można przesyłać dane drogą radiową przy pomocy WiFi.

Mariusz Kondratowicz, student Wydziału Elektroniki i prezes KN Wireless Group
Projekt Radiolinia realizujemy już drugi rok. To tak naprawdę dosyć skomplikowane przedsięwzięcie nie tylko do strony naukowej, ale też logistycznej.

Wiosna 2014 r. - Nawiązanie połączenia 2km pomiędzy dwoma budynkami kampusu Politechniki Wrocławskiej w pobliżu Placu Grunwaldzkiego, a akademikiem T-15 przy ulicy Wittiga na Biskupinie.


Październik 2014 r. - Podobna próba ale na dystansie 3,5km także zakończona sukcesem.

Listopad 2014 r. - Próba na dystansie 35km pomiędzy kampusem Politechniki oraz dolnośląskim miejscem kultu dawnych Słowian - górą Ślężą. Łączność nawiązano pomimo niesprzyjającej jesiennej pogody, chłodu i gęstej mgły oraz braku widoczności.

23 maja 2015 r. - 100km połączenie na trasie Wrocław - Śnieżka z takim rezultatem:





27 czerwca 2015 r. - Rekord Polski pobity - 250 km! Poprzedni rekord wynosił 218km.

Połączenie zostało nawiązane pomiędzy szczytami Babiej Góry i Wielkiej Sowy za pomocą nadajników MikroTik (5GHz):

Osiągnął to zespół w składzie: Kondratowicz, Jakub Jochimiak, Marek Wesołowski, Karol Struk, Daniel Szostak, Mateusz Chudziński, Marcin Maroszek, Kamil Sadowy, Piotr Maks i Daniel Kosowski.




Więcej o projekcie możecie znaleźć na stronie PW:
Czy da się przesłać sygnał WiFi z Wielkiej Sowy na Babią Górę?

Linki:
Wireless Group
Projekt Radiolinia
WiFi250km na Facebook
Radiolinia na Facebook
Wireless Group na Facebook

Czy to ich ostatnie słowo? Mamy nadzieję, że nie!!! :-)

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.

ESP8266 WiFi: SDK, polecenia (komendy) AT i aktualizacja firmware

Autorzy: Tomasz Francuz
Redakcja: Dondu

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

W poprzednich odcinkach cyklu o WiFi ESP8266 poznaliśmy różne typy modułów ESP8266 i sposoby ich podłączenia do komputera. Udało nam się także wysłać do modułu pierwsze polecenia. W tym odcinku dowiesz się jak nawiązać połączenie sieciowe, uaktualnić firmware i kilka innych przydatnych rzeczy, a to wszystko z wykorzystaniem poleceń (komend) AT.

Czym są polecenia (komendy) AT?

Polecenia AT sięgają odległych czasów z początków lat 80-tych, kiedy niejaki Dennis Hayes wymyślił proste zestawy poleceń, które pierwotnie służyły do kontroli pierwszych modemów (dla młodych czytelników – modem to było takie urządzenie, które podłączało się do słuchawki telefonicznej (a później bezpośrednio do linii telefonicznej) i umożliwiało wymianę danych pomiędzy dwoma komputerami).

Polecenia AT poznałeś już na przykładzie Bluetooth HC-05: Bluetooth + mikrokontroler

Polecenia musiały być krótkie (ze względu na niską szybkość transmisji) i zrozumiałe dla człowieka – komunikacja odbywała się przez terminal, a polecenia wydawał i interpretował człowiek. Prostota poleceń i ich łatwa interpretacja przez człowieka i maszynę stanowi o ich popularności do dnia dzisiejszego.

Stąd też w naszym kursie zacznę od poleceń AT. Nie umożliwiają one przejęcia pełnej kontroli nad modułem WiFi, lecz umożliwiają realizację wszystkich najważniejszych funkcji – nawiązywania połączenia i wymiany danych przez sieć. Nie będę tu się rozpisywał nad każdym poleceniem, gdyż ich prosty i zrozumiały opis znajdziesz w odpowiednim pdf – wystarczy go tylko przejrzeć.

SDK

Tutaj trochę uprzedzę fakty i wspomnę o czymś, co przyda nam się w kolejnych odcinkach – tzw. SDK. Co to takiego? Software Development Kit, czyli zestaw narzędzi umożliwiający tworzenie własnego oprogramowania. Tym będziemy się zajmować nieco później, na razie musisz tylko wiedzieć skąd go pobrać i gdzie znaleźć opis poleceń AT.

Ponieważ moduł ESP8266 jest stosunkowo nowym produktem, cierpi na wszystkie choroby wieku dziecięcego – jest on aktywnie rozwijany co pociąga za sobą istotne zmiany w jego oprogramowaniu, a co dla nas ważne – także w sposobie komunikacji z nim. 

Dlatego też zaczniemy od czegoś prostszego, czyli poleceń AT, których zestaw i funkcja praktycznie nie ulegają zmianie. Ponieważ jednak oprogramowanie ulega pewnej ewolucji, najnowszy opis wspieranych poleceń AT zawsze znajdziesz w najnowszej wersji SDK – w chwili pisania artykułu była to wersja 1.2.0 z interpreterem poleceń AT w wersji 0.3.

Wersja 0.3 sugeruje, że jest to mocno rozwojowa wersja oprogramowania – możemy więc spodziewać się jeszcze licznych zmian, zanim interfejs AT okrzepnie na tyle, żeby uznać go za stabilny. Stąd też czytając dalej nasz cykl zawsze pobieraj najnowszą wersję SDK, możesz ją pobrać ze strony: http://espressif.com/new-sdk-release/

W momencie pisania tego artykułu wykorzystałem: esp_iot_sdk_v1.2.0_15_07_03.zip (kopia)


Wersje SDK są numerowane – im wyższy numer tym nowsze wersja SDK. Po jego ściągnięciu rozpakuj zawartość archiwum, a następnie w katalogu ../esp_iot_sdk_v[wersja]/document/EN znajdziesz kilka plików pdf opisujących moduł.

Na tym etapie interesuje nas plik 4A-ESP8266__AT Instruction Set__EN_v0.30.pdf – zawiera on właśnie opis wszystkich wspieranych poleceń AT.

W Internecie można pobrać wiele rozszerzeń dla modułu ESP, które wspierają szerszy zakres poleceń AT – na tym etapie nie będziemy się nimi zajmować. W większości przypadków, przynajmniej na początku do niczego ci się one nie przydadzą.

Ok, zakładam, że udało ci się pobrać wskazany plik, otworzyłeś go i widzisz spis poleceń wraz z opisami w języku angielskim (jeśli wolisz to w katalogu CN masz to samo w języku chińskim). Przeraża cię ilość poleceń? Nie martw się, one są proste i intuicyjne.

Nawiązujemy połączenie sieciowe

Dobra, koniec ględzenia, czas na to, na co czekaliśmy od dawna, czyli nawiązanie połączenia sieciowego. W tym celu potrzebnych będzie kilka rzeczy:

• hardware, o którym pisaliśmy w poprzednich odcinkach – czyli moduł połączony przez przejściówkę z komputerem. Zakładam, że udało ci się z modułem nawiązać połączenie, tak jak to opisywałem w poprzednim odcinku.
• dostęp do sieci bezprzewodowej.

Ponieważ moduł czeka już gotowy do pracy i wiesz jak z nim przez terminal nawiązać połączenie, przejdźmy do sieci bezprzewodowej. Wygodnie będzie jeśli będziesz miał w zasięgu jakiś AP (Access Point), do którego możesz się zalogować.

Będziesz dysponował nazwą użytkownika i hasłem/kluczem potrzebnym do logowania do sieci WiFi – przygotuj je sobie w postaci pliku, z którego będziesz mógł zrobić copy/paste do terminala – przyda się.

Druga sprawa – AP, do którego się łączymy powinien automatycznie przydzielać adres IP – czyli musimy na nim mieć skonfigurowaną usługę DHCP. Nie jest to niezbędne, ale na początek nieco nam ułatwi pracę.

Co robimy?:

• nawiąż połączenie z modułem, tak jak to robiliśmy w poprzedniej części,
• w terminalu wyślij polecenie:

AT+CWLAP

W jego wyniku powinieneś uzyskać (może to zająć kilka sekund) mniej więcej coś takiego:

+CWLAP
+CWLAP:(4,"SCH_SCH",-92,"00:23:CD:20:20:AD",1,-12)
+CWLAP:(3,"AKTOGIM2013",-92,"C4:A8:1D:3A:98:22",11,-36)
+CWLAP:(4,"KAROLINKANET",-41,"00:1A:92:B3:EB:FC",11,-51)
+CWLAP:(0,"DARMOWE_ORANGE_WIFI",-91,"8A:74:2A:52:74:6D",6,-81)
+CWLAP:(4,"LIVEBOX-746D",-92,"84:74:2A:52:74:6D",6,-81)

OK

Jak widzimy zwrócona została lista access pointów (AP), które widzi moduł. Oczywiście w twoim przypadku lista będzie wyglądała inaczej (zależy jakie AP są w okolicy), jednak powinieneś uzyskać mniej więcej coś podobnego.

Jeśli żaden AP nie pojawił się to albo moduł nie ma zasięgu, albo po prostu żaden AP nie jest dostępny.

Jeszcze jedną możliwością jest włączenie w AP opcji ukrywania SSID (SSID to identyfikator sieci składający się maksymalnie z 32 znaków). Opcję ukrywania SSID można włączyć w AP, wtedy jego nazwa nie jest rozgłaszana, w efekcie moduł takiego AP nie widzi – ale ciągle może z nim nawiązać połączenie. Niemniej jednak do testów wygodnie będzie włączyć rozgłaszanie SSID.

A co oznaczają zwrócone wartości?

Pierwsza liczba po nawiasie oznacza typ sieci:

0	Sieć otwarta	Do takiej sieci nie trzeba się logować – jeśli tak wygląda twoja sieć domowa to masz problem – każdy może się podłączyć i przy jej pomocy np. przeglądać zasoby twojego komputera – czym prędzej to zmień
1	Sieć chroniona WEP	Czyli praktycznie sieć otwarta, chociaż wymaga użytkownika i hasła do logowania – też szybko to zmień.
2	WPA_PSK	Sieć chroniona z prewspółdzielonym kluczem.
3	WPA2_PSK	Sieć wykorzystująca nieco lepsze algorytmy szyfrowania z prewspółdzielonym kluczem.
4	WPA_WPA2_PSK	Najsilniejsze szyfrowanie, zasadniczo ten tryb pracy twojego AP powinieneś wykorzystywać.

Wszystkie sieci powyżej zera wymagają logowania, o czym nieco później.

Po typie zabezpieczenia sieci mamy nazwę sieci (SSID). Kolejna jest liczba określająca tzw. RSSI, czyli moc sygnału odbieranego w decybelach, im jest ona wyższa tym silniejszy sygnał.Następnie występuje adres MAC AP – jest to niepowtarzalny adres urządzenia, analogiczny do sieci Ethernet. Kolejny parametr to kanał, na którym pracuje AP. Ostatni parametr to tzw. offset częstotliwości. Dwie ostatnie informacje na tym etapie do niczego nam się nie przydadzą.

Przykład:

+CWLAP:(4,"SCH_SCH",-92,"00:23:CD:20:20:AD",1,-12)

oznacza:

• typ sieci: WPA_WPA2_PSK
• o nazwie sieci (SSID): SCH_SCH  
• moc sygnału (RSSI): -92dB
• adres MAC AP: 00:23:CD:20:20:AD
• kanał nr: 1
• offset częstotliwości: -12

Dla nas na razie ważne są tylko SSID i informacja o zabezpieczeniu sieci.

Czas się połączyć …

Dlaczego SSID jest ważny? Ano dlatego, że kolejne polecenia będą go wymagały. Żeby wymieniać dane musimy podłączyć się pod jakiś AP, czyli musimy znać jego SSID (no i ewentualnie hasło/klucze). SSID możemy uzyskać tak jak powyżej, dzięki poleceniu AT+CWLAP, lub po prostu możemy je znać.

_DEF, _CUR_, deprecated – o co w tym chodzi?

Zanim przejdziemy dalej mała dygresja – zaglądałeś do wspomnianego wcześniej pdfa ATInstructionSet, prawda? Jeśli tak to z pewnością zauważyłeś, że część opisanych w nim poleceń jest ztriplikowana – np. polecenie AT+CWJAP występuje jako AT+CWJAP, AT+CWJAP_CUR i AT+CWJAP_DEF.

O co w tym chodzi? Ano jak pisałem, moduł cierpi na choroby wieku dziecięcego, czyli częste zmiany koncepcji interfejsu. Stąd też przy niektórych poleceniach (np. AT+CWJAP) znajdziesz na czerwono informację – [@deprecated] Please use ….. instead. – czyli po naszemu polecenie zbędne, użyj zamiast niego polecenia:

Polecenia, których nie używamy

Tego typu polecenia nie powinny być stosowane – w nowszej wersji firmware np. mogą zostać usunięte. Są one tylko i wyłącznie dla zachowania wstecznej kompatybilności oprogramowania. Starajmy się poleceń przy których opisie widnieje takie ostrzeżenie nie używać.

Dobrze, a o co chodzi z tym _DEF i _CUR?

Moduł ESP8266 posiada pamięć nieulotną FLASH, w której mały fragment został wydzielony w celu przechowywania informacji o konfiguracji modułu. Stąd też wszelkie polecenia możemy podzielić na dwie grupy:

• polecenia, które nie zmieniają działania modułu na stałe – po resecie modułu lub zaniku zasilania przywrócona zostanie konfiguracja zapisana w pamięci FLASH. Polecenia tego typu mają końcówkę _CUR – zapewne od current – czyli bieżący.
• polecenia, które zmieniają konfigurację modułu zapisaną we FLASH, zmiany wprowadzone przy ich pomocy są stałe – przy każdym resecie i ponownym uruchomieniu modułu konfiguracja zostanie pobrana z pamięci FLASH. Polecenia te mają sufiks _DEF, zapewne od angielskiego default – czyli domyślny.

Jakich poleceń używać? Jeśli chodzi ci tylko o bieżące sprawdzenie różnych opcji to zapewne wygodniej jest używać poleń _CUR – w razie problemów resetujesz moduł i zaczynasz zabawę od nowa. Natomiast, jeśli moduł ma pracować zawsze ze ściśle określonymi parametrami, można go skonfigurować raz na PC, zapisać potrzebne informacje i zamontować w urządzeniu docelowym. Dzięki temu współpracujący z modułem mikrokontroler nie będzie musiał go konfigurować.

Warto pamiętać o jeszcze jednej rzeczy – pamięć FLASH ma ograniczoną, zwykle do kilku-kilkunastu tysięcy liczbę zapisów. Jeśli więc przy każdym uruchomieniu modułu będziesz zapisywać tą samą konfigurację (niepotrzebnie będziesz powtarzał polecenia z sufiksem _DEF) to być może ten FLASH ci w końcu padnie. Mała szansa, ale po co kusić los?

Wracamy do połączenia…

Ok, mamy już SSID i informacje do logowania do naszego AP. To teraz robimy dwie rzeczy. Pierwsza to określenie roli naszego modułu ESP8266. O co chodzi? Otóż nasz moduł może pracować w trzech trybach:

1	Tryb klienta sieci WiFi	W tym trybie podłącza się pod AP i działa tak jak karta radiowa w notebooku – korzysta z sieci, ale jej nie udostępnia.
2	Tryb AP	W tym trybie moduł potrafi udostępniać połączenie bezprzewodowe innym, działa więc jak AP.
3	Tryb AP + klient	Jest to połączenie obu trybów.

Przed przystąpieniem do dalszych działań musimy wybrać tryb pracy. My wybierzemy tryb pierwszy – klienta WiFi. Dlaczego? Przede wszystkim dlatego, że póki co chcemy się połączyć tylko z AP i rozpocząć wymianę danych z innymi stacjami. Ale jest jeszcze ważniejszy powód, o którym się zapomina:

Pamiętaj, że w trybie AP nasz moduł udostępnia połączenie sieciowe innym stacjom WiFi. Ponieważ moduł jest dostarczany jako nieskonfigurowany, jeśli odpalimy tryb AP lub mieszany to przez nasz moduł inni będą mogli się dostać do naszej sieci wewnętrznej. Pamiętaj o tym, że zabawa z WiFi może potencjalnie stworzyć poważne luki w bezpieczeństwie sieci!

Pamiętaj, żeby uważnie bawić się z modułami WiFi tak, żeby nie narazić się na utratę poufnych danych, być może lepiej jest stworzyć odrębną sieć do testów, do której nie są podłączone żadne komputery zawierające istotne dane. Oprogramowanie modułu jest ciągle w fazie rozwoju i nie ma żadnej gwarancji co do jego bezpieczeństwa, nawet jeśli włączysz wszelkie możliwe zabezpieczenia. Pamiętaj o tym w czasie dalszej zabawy.

O bieżącym trybie pracy możesz się przekonać wydając polecenie:

AT+CWMODE?

W odpowiedzi otrzymasz informację o trybie pracy modułu:

+CWMODE? +CWMODE:3

OK

Jak widzimy otrzymaliśmy informację o trybie (domyślnie sprzedawane urządzenia mają tryb 3) oraz potwierdzenie prawidłowej realizacji polecenia (OK). Ponieważ powinniśmy na tym etapie unikać odpalania AP, czym prędzej zmieńmy tryb pracy modułu na klienta sieci. W tym celu wydajemy polecenie:

AT+CWMODE_DEF=1

i otrzymujemy:

 WMODE_DEF=1                                                                                 
OK

Mała dygresja…

Jak widzisz każde polecenie AT składa się z opcjonalnej listy argumentów, a w wyniku jego wykonania uzyskujemy informacje zwrotne zakończone frazą OK, jeśli wszystko przebiegło pomyślnie lub ERROR w przypadku błędu.

Użyliśmy polecenia z sufiksem _DEF, żeby na stałe przestawić tryb pracy modułu. Od tego momentu jesteśmy względnie bezpieczni – naszego modułu nie da się już wykorzystać jako otwartego AP.

Teraz czas na połączenie z AP. W tym celu możemy użyć dwóch poleceń: AT+CWJAP_CUR lub AT+CWJAP_DEF. To drugie spowoduje zapisanie SSID i hasła w pamięci FLASH, dzięki czemu moduł będzie mógł automatycznie ponownie łączyć się ze wskazanym AP.

Pamiętaj, że hasło do twojej sieci znajdzie się w pamięci modułu. Takim modułem nie dziel się ze znajomymi, chyba, że naprawdę nie masz nic do ukrycia :)

Wydajemy więc polecenie:

AT+CWJAP_DEF="TWOJE SSID","TWOJE HASŁO"

w wyniku którego powinniśmy otrzymać odpowiedź:

WIFI CONNECTED

WIFI GOT IP



OK

Warto jeszcze przy okazji hasła wspomnieć o pewnej sprawie – hasło powinno zawierać różne znaki, nie powinny to być wyrazy, data urodzenia itd. To oczywiste. Ale w haśle mogą się znaleźć pewne znaki specjalne, które są interpretowane jako elementy polecenia AT, np. " lub / (slash) - musimy je odpowiednio zakodować. W tym celu taki znak specjalny poprzedzamy ukośnikiem (slash), i tak np. hasło które brzmi:

 a1"ds,/4 

powinniśmy zakodować jako:

a1/"ds,//4 

Pamiętajmy o tym, gdyż w przeciwnym razie polecenie AT zostanie źle zinterpretowane.

W efekcie nasz moduł połączył się ze wskazanym AP i uzyskał z niego adres IP (o ile w AP jest włączony serwer DHCP). Od tego momentu moduł ma pełny dostęp do zasobów udostępnianych przez AP ze wszystkimi tego konsekwencjami (także dla bezpieczeństwa sieci).


Teraz uwaga!

Do tej pory moduł każde polecenie poprawnie wykonane potwierdzał komunikatem OK, a wykonane błędnie komunikatem ERROR. Od chwili nawiązania połączenia z AP sytuacja nieco się komplikuje – musimy to uwzględnić pisząc oprogramowanie interpretujące wyniki poleceń AT. Otóż moduł utrzymuje połączenie z wybranym AP, niemniej, czasami, ze różnych powodów, połączenie może zostać rozłączone, czemu towarzyszy wysłanie na konsolę komunikatu:

WIFI DISCONNECT

Tego typu komunikat może się pojawić w dowolnej chwili – jeśli się pojawi, to znaczy, że połączenie zostało utracone. Moduł ESP8266 może automatycznie (tak jest domyślnie) próbować ponownie nawiązać połączenie i jeśli mu się to uda, to na konsolę zostanie wysłany komunikat:

WIFI CONNECTED

Jak widzimy oba komunikaty mogą się pojawiać niezależnie od wysyłanych poleceń AT, musimy więc je prawidłowo obsługiwać.

Przy okazji – możemy sprawdzić czy opcja automatycznego ponownego nawiązywania połączenia z AP jest aktywna, w tym celu w terminalu wysyłamy polecenie:

AT+CWAUTOCONN?

na co powinniśmy uzyskać odpowiedź:

+CWAUTOCONN? +CWAUTOCONN:1
OK

Wartość 1 świadczy, że moduł pracuje w trybie automatycznego ponawiania połączeń, 0 – automatyczne nawiązywanie połączenia jest wyłączone. Tryb możemy zmieniać, jak się domyślasz wystarczy wysłać polecenie:

AT+CWAUTOCONN=1 LUB 0

aby zmienić zachowanie modułu.

Sprawdzamy połączenie

Ok, podłączyliśmy się pod AP, jeśli wybrany AP udostępnia połączenie internetowe to możemy je wykorzystać do testu łączności. Pierwsze co zrobimy, to sprawdzimy własny adres IP i parametry sieci. W tym celu wysyłamy polecenie:

AT+CIPSTA?

W efekcie uzyskujemy potrzebne informacje:

+CIPSTA? +CIPSTA:IP:"192.168.1.2"
+CIPSTA:GATEWAY:"192.168.1.1"
+CIPSTA:NETMASK:"255.255.255.0"

OK

Widzimy nasz adres IP – w tym przypadku 192.168.1.2 – jest to adres przydzielony nam przez serwer DHCP pracujący w AP do którego się połączyliśmy, adres bramy (Gateway) – będzie to zazwyczaj adres AP w sieci lokalnej oraz maskę sieci – wszystkie te informacje uzyskaliśmy z serwera DHCP. Gdyby nie był on uruchomiony musielibyśmy nasz moduł skonfigurować samodzielnie.

Ok, teraz przetestujmy połączenie. Do testowania połączeń w sieci TCP/IP wygodnie jest użyć polecenia ping – ma ono swój odpowiednik także wśród poleceń AT:

AT+PING="192.168.1.1"

Jako argument polecenie przyjmuje adres IP lub nazwę stacji, którą pingujemy. W efekcie, jeśli połączenie przebiegło poprawnie powinniśmy otrzymać odpowiedź:

+PING="192.168.1.1"

+8

                                                                              

OK

Wartość +8 (zapewne inna w twoim przypadku), określa czas w milisekundach jaki upłynął od momentu wysłania żądania do czasu uzyskania odpowiedzi.

Ok, możemy więc pingować naszą bramę, powinniśmy móc też nawiązać połączenie z Internetem. Ale zanim to zrobimy, jeszcze jeden test – w Internecie nie posługujemy się zazwyczaj adresami IP, lecz nazwami. Aby się nimi posługiwać potrzebujemy działający serwer rozwiązujący nazwy na adresy IP, czyli tzw. DNS.

Możemy sprawdzić czy działa on poprawnie:

AT+PING="WWW.ONET.PL"

i uzyskujemy:

+PING="WWW.ONET.PL" +30

OK

Jeśli uzyskujesz takie odpowiedzi to znaczy, że wszystko jest ok. Jeśli nie, to sprawdź konfigurację swojego AP, w szczególności serwera DHCP.

Dla niektórych adresów IP i nazw możesz nie uzyskać odpowiedzi na polecenie ping. Niekoniecznie świadczy to o problemie z modułem – niektóre serwery są tak skonfigurowane, aby nie odpowiadać na ping. Z takim serwerem można się normalnie połączyć, leczy próba jego pingowania zawsze zakończy się niepowodzeniem.

Uaktualnianie firmware

Ok, nawiązaliśmy połączenie z Internetem, wszystko działa poprawnie to czas na coś nowego. Jak pisałem na wstępie moduł ESP8266 to stosunkowo nowy produkt i ciągle pojawiają się na niego aktualizacje oprogramowania. Na początku tego artykułu pisałem, żeby ściągnąć najnowsze SDK, gdyż znajdziemy w nim najnowszy pdf z opisem m.in. poleceń AT.

Skoro mamy już najnowszy SDK to warto byłoby też, żeby nasz moduł posługiwał się najnowszym firmware. Czyli jakoś musimy go uaktualnić. W Internecie znajdziesz wiele opisów flashowania pamięci modułu, wymagających różnych programów i wiedzy z pogranicza magicznej. Tym się zajmiemy w przyszłości, lecz póki co uaktualnimy software w najprostszy możliwy sposób – automatycznie. Jak? Po prostu wydamy odpowiednie polecenie AT:

AT+CIUPDATE

Po jego wydaniu moduł automatycznie łączy się z serwerem aktualizacji, sprawdza czy jest jakaś nowsza wersja, jeśli tak to ją pobiera i aktualizuje ESP8266:

+CIUPDATE +CIUPDATE:1
+CIUPDATE:2
+CIUPDATE:3
+CIUPDATE:4

OK

Jak widzimy aktualizacja podzielona jest na kilka etapów, które przebiegają automatycznie. Ściągnięcie nowego firmware może trochę potrwać, stąd zakończenie wykonywania tego polecenia nie jest natychmiastowe. Sporadycznie mogą zdarzać się błędy połączenia, wynikające z braku połączenia z Internetem lub wyłączenia serwera aktualizacji. W takiej sytuacji powinniśmy ponowić próbę aktualizacji za jakiś czas. Jeśli oprogramowanie się zaktualizowało, to moduł automatycznie się zrestartuje – aby zmiany weszły w życie moduł musi się ponownie uruchomić:

WIFI DISCONNECT
                                                             
ETS JAN  8 2013,RST CAUSE:4, BOOT MODE:(3,3)
WDT RESET
LOAD 0X40100000, LEN 1320, ROOM 16 
TAIL 8
CHKSUM 0XB8
LOAD 0X3FFE8000, LEN 776, ROOM 0 
TAIL 8
CHKSUM 0XD9
LOAD 0X3FFE8308, LEN 412, ROOM 0 
TAIL 12
CHKSUM 0XB9
CSUM 0XB9
                                                                   
2ND BOOT VERSION : 1.3(B3)
  SPI SPEED      : 40MHZ
  SPI MODE       : QIO
  SPI FLASH SIZE : 8MBIT
JUMP TO RUN USER2
                   
SLŹ‚RÚ
AI-THINKER TECHNOLOGY CO. LTD.
READY
WIFI CONNECTED
WIFI GOT IP

Po aktualizacji moduł jest gotowy do pracy.

Pamiętaj, że jeśli konfiguracja modułu nie była zapisywana do pamięci FLASH (używałeś poleceń z sufiksem _CUR) to moduł będzie wymagał ponownej konfiguracji.

Mamy nowy firmware o czym możemy się łatwo przekonać:

AT+GMR

i uzyskujemy:

+GMR AT VERSION:0.30.0.0(JUL 3 2015 19:35:49)
SDK VERSION:1.2.0
AI-THINKER TECHNOLOGY CO. LTD.
JUL 5 2015 15:06:58

OK

Proste, prawda? Warto nasz moduł czasami aktualizować, nie tylko możemy liczyć na jakieś nowe funkcje (które niekoniecznie nam będą potrzebne), ale przede wszystkim na usunięcie potencjalnych błędów, a przede wszystkim błędów związanych z bezpieczeństwem.

A co jeśli nie chcemy DHCP?

Do tej pory adres IP i konfiguracja sieci były pobierane automatycznie z AP przez DHCP. Ale nie zawsze jest to pożądane. Wadą DHCP jest to, że klient (nasz moduł IP) może otrzymywać różne adresy IP (niekoniecznie tak musi być, w niektórych przypadkach  DHCP może przydzielać IP po adresie MAC).

W przypadku, kiedy budujemy sieć czujników lepiej jest jeśli ich adresy IP są z góry znane. Co prawda możemy używać w tym celu nazw domenowych i sprytnie skonfigurowanego serwera DNS, ale wymaga to z kolei od nas poznania jak działa DNS, DHCP, itd. Niekoniecznie chcielibyśmy od tego zaczynać.

Stąd też najprościej jest po prostu przydzielić modułowi adres „ręcznie”. W tym celu możemy posłużyć się poleceniami AT, ponieważ adres ma być stały, najwygodniej jest używać poleceń z sufiksem _DEF, dzięki temu wszystkie parametry sieci będą przechowywane w pamięci FLASH. W tym celu musimy wysłać jednorazowo polecenie:

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

Polecenie to określa po kolei:

• adres IP modułu, 
• adres bramy, 
• maskę podsieci. 

W rezultacie powinniśmy otrzymać:

IPSTA_DEF="192.168.1.10","192.168.1.1","255.255.255.0"
OK

Od tej chwili moduł używa nowych parametrów sieci.

W kolejnych odcinkach pokażę jak wymieniać dane pomiędzy modułami ESP8266, modułem a serwerem internetowym itd.

ESP8266 WiFi: Podłączenie modułu i komunikacja z komputerem

Autor: Tomasz Francuz
Redakcja: Dondu

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

W pierwszej części naszego mini-cyklu o ESP8266 dowiedzieliśmy się co nieco o tym jaki moduł kupić i czym one się między sobą różnią. Skoro mamy już moduł nadszedł czas, aby go ożywić, czyli się z nim skomunikować. W tej części pokażę jak połączyć moduł z mikrokontrolerem i jakie na użytkownika czyhają potencjalne pułapki.

Pamiętajcie tylko, że na rynku jest dużo różnych wersji modułów ESP i jeszcze więcej wersji firmware. Po prostu nie jestem w stanie przetestować wszystkich. Jeśli więc traficie na moduł, który zachowuje się odmiennie niż w naszym opisie to dajcie proszę znać pisząc komentarz do tego artykułu.

---

Kabelkologia

Zanim zaczniemy grzebać przy module jeszcze raz przypomnę – moduł wymaga zasilania z zakresu 3,0-3,6V, czyli w praktyce standardowego 3,3V. Ponieważ impulsowo może pobierać nawet ponad 200mA, musimy zadbać o to, aby zasilacz był w stanie taki prąd dostarczyć. Stąd też, jeśli używasz np. Arduino, do którego podłączonych jest sporo różnych urządzeń, to pomyśl o lepszym zasilaniu niż wbudowany na płytce stabilizator. Pamiętaj też, że dodatkowe kondensatory: elektrolityczny (do kilkuset µF) i ceramiczny 100nF nie zaszkodzą, a mogą pomóc.

Pamiętaj, moduł nie toleruje zasilania 5V, jego piny sterujące też nie są 5V-tolerant, chyba że kupiłeś moduł z translatorami poziomów.

Stąd też połączenie ESP8266 z mikrokontrolerami zasilanymi typowo z 5V nie może odbywać się bezpośrednio. W takiej sytuacji będziemy potrzebowali:

• dodatkowego stabilizatora low-drop (LDO), który z 5V zrobi nam 3,3V do zasilania modułu,
• konwertera poziomów 5V na 3,3V – rezystor lub dzielnik rezystorowy – taki konwerter potrzebny jest na linię RxD modułu, którą łączymy z wyjściem TxD UART mikrokontrolera i ewentualnie na wykorzystywane linie GPIO (wejścia/wyjścia).

A może prościej będzie przesiąść się na zasilanie 3,3V i raz na zawsze zakończyć problemy związane z różnymi domenami zasilania? Pamiętajmy, że niektóre wersje AVR-ów można zasilać z 3,3V – klasyczne (ATtiny, ATmega - np. ATmega8A lub ATmega8L), będą wymagały tylko ograniczenia maksymalnej częstotliwości taktowania.

Ale np. AVR z rodziny XMEGA będą pracowały nawet z taktowaniem 32MHz przy zasilaniu 3,3V. Ponieważ bardzo lubię tą rodzinę mikrokontrolerów, a mają one w kontekście naszego modułu ESP także inne zalety, w dalszej części pokażę przykłady oparte na tych mikrokontrolerach.

Odsłona pierwsza – łączymy moduł z PC

Ponieważ naszą zabawę z modułem ESP8266 zaczniemy od prostych poleceń i po prostu oswojenia się z nową zabawką, wygodnie będzie połączyć moduł z komputerem PC. Tu pojawia się drobny problem – moduł do komunikacji wykorzystuje interfejs UART, a współczesne PC-ty raczej go nie mają – z interfejsów szeregowych posiadają m.in. USB.

Nawet jeśli ktoś ma jeszcze w domu komputer z RS232 to też nie ma się co cieszyć – ESP wykorzystuje tzw. RS232-TTL, czyli stany logiczne kodowane są w nim tak jak w układach logicznych, czyli stan niski to ok. 0V, a wysoki to 3,3V. Natomiast klasyczny RS232 pracuje przy poziomach napięć ±12V, stąd też podłączenie ESP do klasycznego RS232 niechybnie zakończy jego życie.

Ok, potrzebujemy więc przejściówkę USB-RS232-TTL z poziomami 3,3V. Tak się dobrze składa, że tego typu przejściówki możemy kupić za parę złotych z darmową dostawą np. na AliExpress.

Możemy też kupić opisywany w poprzedniej części tego cyklu moduł wyposażony już w przejściówkę na USB – w takiej sytuacji moduł po prostu łączymy z PC-tem kablem USB i możemy rozpocząć przygodę. A jeśli nie mamy modułu z wbudowanym USB? To musimy sobie sami połączyć moduł z przejściówką wg pokazanego poniżej rysunku:

FT232-moduł

Czyli łączymy:

• RxD modułu z TxD przejściówki
• TxD modułu z RxD przejściówki
• łączymy GND i Vcc (3,3V) – tu uwaga:

Nigdy nie wykorzystuj napięcia 3,3V z przejściówki do zasilania modułu. W przejściówce znajduje się stabilizator LDO, który zasila część logiki oraz bufory IO układu, lecz ma ograniczoną wydajność prądową. W przypadku FT232 daje max 50mA – czyli ponad czterokrotnie mniej niż wymaga tego moduł ESP8266!

• pin CH_PD łączymy z 3,3V bezpośrednio lub przez rezystor 4k7-10k
• jeśli moduł ma wyprowadzony pin GPIO15 to łączymy go z GND (w dalszej części wyjaśnię o co chodzi)
• pin REST (RESET) łączymy przez rezystor z 3,3V lub zostawiamy niepodłączony.

Wybierając przejściówkę pamiętajmy, aby wybrać taką, która daje na wyjściu poziomy logiczne w standardzie 3,3V. Niektóre dają na wyjściu 5V – w takim przypadku niepotrzebnie sobie skomplikujemy podłączenie ESP – wymagany będzie dodatkowy stabilizator i prosta translacja poziomów napięć.

I to tyle, proste, prawda? Wykorzystanie chipu FT232 jest proste i tanie, ale my przecież zajmujemy się mikrokontrolerami, może więc trochę skomplikujemy to proste połączenie?

Wykorzystanie modułu Xplained Mini

W drugim wydaniu swojej książki „Język C dla mikrokontrolerów AVR. Od podstaw do zaawansowanych aplikacji” wykorzystuję do realizacji przykładów moduł Xplained Mini – kosztuje on niewiele (w USA parę dolarów), ale w Polsce też go można kupić tanio, np. w Seguro za niecałe 50 zł. Trochę więcej o tym fajnym module możesz poczytać na naszym blogu w artykule: Xplained Mini – czyli to, co Atmel już dawno temu zrobić był powinien

Dlaczego Xplained jest fajny? Bo na pokładzie ma mikrokontroler ATMega168/328P, czyli ten sam, który jest w popularnym Arduino, cała płytka ma format Arduino i pasują do niej shieldy Arduino, a co więcej na płytce jest programator/debugger, czyli mamy wszystko, co potrzebne, aby wystartować z AVR. Ale mamy jeszcze jedną fajną rzecz – płytka zawiera konwerter RS232-TTL-USB! A więc możemy ją wykorzystać jako przejściówkę do podłączenia modułu ESP8266 do PC-ta. W tym celu musimy odnaleźć na płytce dwa punkty oznaczone jako RX i TX:

Xplained Mini

Znajdują się one po lewej stronie mikrokontrolera leżącego przy gnieździe USB, tuż pod napisem ATMega328P. Jeśli do tych punktów podłączymy UART modułu ESP to będziemy mogli się z nim komunikować przez USB. Z tym, że musimy pamiętać o ważnej rzeczy – standardowo moduł Xplained Mini pracuje z zasilaniem 5V (można to zmienić na 3,3V, wymaga to jednak drobnych zmian w module, które na razie pominiemy).

Stąd też o ile sygnał TxD modułu możemy bezpośrednio doprowadzić do dziurki oznaczonej jako RX na Xplained, o tyle, sygnał z dziurki oznaczonej TX musimy doprowadzić do wejścia RxD ESP poprzez rezystor lub dzielnik rezystorowy, tak aby zbić napięcie do bezpiecznego poziomu 3,3V. W tym celu możemy np. zbudować dzielnik z rezystorami 10k i 20k, tak jak na rysunku (wartości rezystorów nie są krytyczne, ważny jest ich stosunek):

Dzielnik rezystorowy

Musimy pamiętać jeszcze o jednej drobnej rzeczy – piny RX i TX modułu Xplained są połączone z pinami TxD i RxD mikrokontrolera ATMega168/328P znajdującego się na module – musimy pamiętać, aby przed wykorzystaniem modułu jako przejściówkę RS-USB wczytać do ATMegi program, który nie wykorzystuje tych pinów. W przeciwnym przypadku mogą pojawić się zakłócenia w transmisji. Dodatkową zaletą Xplained jest to, że posiada on na pokładzie stabilizator 3,3V, możemy więc z niego zasilać ESP – stosowne napięcie dostępne jest na listwie po lewej stronie modułu.

I to tyle. Jak widzimy wykorzystanie Xplained Mini jest równie proste jak dedykowanej przejściówki RS232-USB.

---

XMEGA pokazuje pazurki…

Jak już napisałem, bardzo lubię mikrokontrolery XMEGA, pokażę więc jak je wykorzystać do zbudowania przejściówki USB-RS232 i podłączenia modułu ESP do PC-ta. Po co wykorzystywać XMEGA? Ano jest ku temu kilka powodów. Po pierwsze, pracuje on przy zasilaniu 3,3V, odpada więc konieczność wykonania jakiejkolwiek konwersji poziomów logicznych. Czyli jest prosto.

Jest jeszcze jedna zaleta – w cenie układu FTDI (oczywiście jeśli kupujemy osobny układ, a nie chiński gotowiec), możemy kupić XMEGA-ę z wbudowanym interfejsem USB. Daje nam to o wiele większe możliwości zabawy i przyda się w kolejnych odcinkach o ESP8266. Do tego na naszym rodzimym rynku jest kilka firm (LeonInstruments, Modułowo), które sprzedają świetne płytki rozwojowe z XMEGA – dlaczego więc ich nie wykorzystać?

Osoby regularnie czytające bloga wiedzą, że XMEGA-ę można w prosty sposób oprogramować tak, aby działała jako przejściówka USB-RS232 – pokazałem to w tym artykule: XMEGA: Emulacja portu szeregowego na XMEGA

Teraz wykorzystamy to rozwiązanie do stworzenia uniwersalnej przejściówki. W tym celu wystarczy wgrać prosty gotowiec i dodać dosłownie parę linii kodu. A konkretnie, musimy skonfigurować interfejs UART wykorzystywany do komunikacji z ESP8266 – w naszym przypadku będzie to USARTC0 (wykorzystamy piny 2 i 3 PORTC, do których należy podłączyć piny TxD i RxD modułu):

void usart_init()
{
 PORTC_OUTSET=PIN3_bm;
 PORTC_DIRSET=PIN3_bm;                          //Pin TxD musi być wyjściem
 USARTC0.CTRLB=USART_TXEN_bm | USART_RXEN_bm;   //Włącz nadajnik USART
 USARTC0.CTRLC=USART_CHSIZE_8BIT_gc;            //Ramka 8 bitów, bez parzystości, 1 bit stopu
 USARTC0.CTRLA=USART_RXCINTLVL_LO_gc;           //Włącz przerwanie odbiornika USART
}

Warto zwrócić uwagę na to, że konfigurując USART nigdzie nie ustawiamy szybkości, z jaką będzie działał. Nastąpi to dopiero w chwili, gdy PC otworzy nasz port szeregowy, przesyłając deskryptor z konfiguracją portu wybraną przez użytkownika. Zignorujemy większość danych zawartych w przesłanym deskryptorze, wykorzystamy tylko jedną – określającą szybkość pracy USART:

void uart_config(uint8_t port, usb_cdc_line_coding_t * cfg)
{
 //Konfiguracja w odpowiedzi na otwarcie CDC
 usart_set_baudrate(&USARTC0, cfg->dwDTERate, F_CPU);   //Konfigurujemy USARTC0 tak jak użytkownik skonfigurował VCOMM, ale uwzględniamy tylko baudrate
}

Teraz musimy jeszcze napisać funkcję odbierającą znaki z modułu i wysyłającą je na USB:

ISR(USARTC0_RXC_vect)
{
 udi_cdc_putc(USARTC0_DATA);
}

Po każdym odebranym znaku zgłoszone zostanie przerwanie, w którym odebrany znak będzie transmitowany przez USB do PC-ta. To samo musimy jeszcze zrobić ze znakami odbieranymi z PC-ta przez USB i wysyłać je do ESP:

while (1)
 {
  if(udi_cdc_is_rx_ready())
   USART_putchar(&USARTC0, udi_cdc_getc());  //Przepisz to co otrzymałeś na USART sterujący modułem
 }

Tym razem w pętli głównej (i tak nie mamy nic ciekawszego do roboty) czekamy aż coś zostanie przesłane przez USB i wysyłamy to przez USARTC0 do modułu ESP8266.

Do pobrania (kompletny projekt w Atmel Studio): ESP8266-PC.ZIP (kopia)

Po odpaleniu programu na PC powinniśmy zobaczyć nowy port szeregowy – to co na niego wyślemy trafi do ESP, a to co odbierzemy to komunikaty wysłane do nas z ESP. Proste prawda?

Zachęcam do wykorzystania XMEGA do realizacji komunikacji PC-USB-RS232-TTL-ESP8266 – jest to bardzo uniwersalne rozwiązanie i ma kilka zalet, o których już wspomniałem. Ale ma także inne.

Przede wszystkim jest to mikrokontroler, więc daje nam dużą elastyczność w dodawaniu potrzebnych funkcji. W szczególności możemy wymyślić inny sposób komunikacji niż poprzez wirtualny port szeregowy – ale to dla zaawansowanych. Zaletą, którą z pewnością wykorzystamy to posiadanie wielu linii IO, którymi możemy sterować, a przede wszystkim możemy je połączyć z liniami GPIO modułu, dzięki czemu możemy badać jego stan, sterować nimi, lub np. realizować komunikację z modułem przy pomocy innych interfejsów, np. SPI. Ale o tym później. Dla mnie najważniejszą zaletą wykorzystania XMEGA jest to, że mam ją pod ręką :-)

---

Pierwsze testy komunikacji

Ok, podłączyliśmy moduł z PC-tem – nie ważne na który sposób się zdecydowałeś, dalsze kroki wyglądają identycznie. Czas przetestować połączenie. Lecz zanim to zrobisz – warto jeszcze raz sprawdzić poprawność połączeń elektrycznych – głupio byłoby sobie na wstępie uszkodzić moduł WiFi (strata niewielka, ledwie parę złotych), lub port USB (tu straty mogą być większe). Ponieważ zapewne nie możesz się doczekać pierwszej odpowiedzi z modułu jeszcze w tym odcinku nawiążemy z nim połączenie…

Terminal

Co prawda mamy już wszystkie połączenia, ale na PC potrzebujemy jeszcze wygodny program, który umożliwi wysyłanie i odbiór danych z i do modułu. W sieci dostępnych jest sporo różnych programów terminali, osobiście lubię RealTerm – jest on całkowicie za darmo i ma wiele użytecznych funkcji. Zresztą czytelnicy naszego bloga już go kilkakrotnie poznali.

Można go pobrać ze strony domowej projektu: realterm.sourceforge.net

Po jego pobraniu, odpalamy go i w zakładce Port wybieramy parametry konfiguracyjne połączenia (szybkość, format danych), wirtualny port szeregowy, który posłuży do realizacji połączenia, a następnie klikamy Open.

Przykłady użycia Realterm:

• RS-232: Komunikacja ATmega8 z komputerem
• HC-05 (Bluetooth) - Test komunikacji z komputerem

Co po resecie?

Moduł ESP8266 tuż po resecie wysyła na pin TxD krótki komunikat informujący o przyczynie resetu oraz informacje diagnostyczne. Możemy to wykorzystać do testu komunikacji. W tym celu odpalamy terminal, ustawiamy szybkość transmisji na 76800 bodów (tak, Chińczycy to dziwny ludek, najwyraźniej mają kłopoty z konsekwencją, moduł co chwilę zmienia szybkość pracy UART), bez parzystości, 8 bitów danych i jeden bit stopu, czyli w skrócie:

76800 8N1

Po ustawieniu terminala i nawiązaniu połączenia na chwilę łączymy wejście modułu REST (od RESET, kolejny Chiński akronim) do masy, po czym zostawiamy je niepodłączone lub łączymy do Vcc. W efekcie powinniśmy zaobserwować komunikat wysyłany przez moduł:

Pierwsza komunikacja

Jeśli otrzymaliśmy taki lub podobny komunikat to znaczy, że wszystko jest na dobrej drodze i mamy połączenie.

Pamiętaj, że jeśli zamiast powyższego komunikatu otrzymasz ciąg dziwnych znaków to też nie jest źle – po prostu wybrałeś niewłaściwą szybkość transmisji, lecz komunikacja jest ok i nie ma się czym przejmować.

Jeśli natomiast nie uzyskałeś nic to:

• sprawdź jeszcze raz wszystkie połączenia i poprawność montażu (nawet, jeśli sprawdzałeś to już 100 razy to sprawdź i sto pierwszy),
• sprawdź, czy połączyłeś piny TxD przejściówki z RxD modułu i RxD przejściówki z TxD modułu,
• co jest mało prawdopodobne, ale możliwe – Chińczycy znowu coś zmienili w firmware i twój moduł nie wysyła żadnych komunikatów przy starcie – nie liczyłbym na to, ale kto wie. Jeśli spotkasz się z taką sytuacją to koniecznie daj nam znać.

Magia z GPIO15

Dla poprawnego startu modułu pin GPIO15 (o ile występuje na module) powinien mieć stan niski. Na modułach, na których pin ten nie jest wyprowadzony najprawdopodobniej odpowiednie wejście chipsetu jest połączone z masą na stałe. Na modułach, które posiadają ten pin może być różnie.

Jak zwykle musimy zdawać sobie sprawę z tego, że normy, standardy i logika to coś zupełnie dla inżynierów z Chin niepojętego i nie przywiązują do tych pojęć dużej wagi. W niektórych modułach pin ten jest połączony z masą (poprzez jakiś rezystor ściągający do GND?), na innych najwyraźniej nie.

W efekcie, jeśli widzisz w terminalu, że bootowanie kończy się na napisie „waiting for host” (tak jak na poprzednim screenshocie), to spróbuj połączyć GPIO15 na stałe do masy. Bez tego chip nie wejdzie w tryb poleceń AT i dalsza komunikacja nie będzie możliwa. Jeśli bootowanie przebiegło pomyślnie to powinieneś zobaczyć coś mniej więcej takiego:

Prawidłowe bootowanie

Jak widzisz, po kilku liniach sensownych informacji, pozwalających się zorientować m.in. w typie modułu i ilości dostępnej pamięci FLASH, na końcu mamy jakieś śmieci. Czy to problem? Otóż nie, to kolejny przykład na to, że myśli Chińczyków biegną własnymi, niekoniecznie prostymi torami … otóż jak już wspomniałem, moduł rozpoczyna bootowanie ustawiając UART na 76800 8N1, ale w trakcie zmienia ustawienia na 9600 8N1 lub na 115200 8N1 (zależy to od wersji firmware, więc sprawdź obie możliwości).

Ponieważ dalsze komunikaty są wysyłane już przy innej szybkości USART będziemy obserwować właśnie owe śmieci. W efekcie, jeśli ustawimy szybkość UART na docelową dla danego modułu (9600 lub 115200) to początek komunikatu będzie składał się ze śmieci, za to końcówka będzie zrozumiała:

Prawidłowe bootowanie ze zmienioną szybkością

Dla nas istotne jest jedno – cały przesłany komunikat powinien zakończyć się ciągiem „ready \n\r”. Jeśli tak się stało to znaczy, że moduł jest gotowy do pracy i oczekuje na nasze polecenie.

Wydajmy więc pierwsze polecenie (komendę AT)

AT+GMR – jest to polecenie wyświetlające aktualną wersję firmware i SDK używanego przez moduł. Polecenia przesyłamy w zależności od używanego terminala. W RealTerm, przechodzimy do zakładki Send, w której wpisujemy polecenie AT+GMR, jednocześnie pamiętając, żeby w polu EOL (znaki końca linii) koniecznie zaznaczyć +CR + LF. Dzięki temu terminal do każdego wysyłanego łańcucha automatycznie doda znaki końca linii, które są wymagane przez moduł dla poprawnego rozpoznania polecenia.

W odpowiedzi powinniśmy uzyskać mniej więcej coś takiego:

Pierwsze polecenie - AT+GMR

Jak widzimy uzyskaliśmy informację, że moduł zawiera wersję parsera komend AT 0.23.0.0 z kwietnia 2015 roku oraz wersję SDK 1.0.1. Co ważne każde polecenie AT kończy się komunikatem OK. Dzięki temu wiemy, że moduł poprawnie zinterpretował i wykonał polecenie.

Możemy jeszcze wydać polecenie AT+RST, w wyniku którego moduł jest resetowany, a my uzyskujemy komunikaty jak poniżej:

Resetowanie modułu poleceniem AT+RST

Dlaczego o tym poleceniu wspominam? Właściwie z jednego powodu – aby po raz kolejny pokazać „konsekwencję” inżynierów. Tym razem, podczas resetu nie jest zmieniana szybkość UART, w efekcie poprawnie zobaczymy wszystkie komunikaty towarzyszące resetowi.

Możemy jeszcze przetestować część radiową modułu – w tym celu wydajemy polecenie AT+CWMODE=3 i AT+CWLAP, w efekcie powinniśmy otrzymać listę Access Pointów znajdujących się w otoczeniu:

Pierwsza komunikacja radiowa

Ok, najtrudniejsze mamy za sobą – mamy komunikację z modułem, widzimy sieci bezprzewodowe, w kolejnej części zajmiemy się nawiązywaniem połączenia i przesyłaniem danych.

ESP8266 WiFi: Wstęp

Autor: tmf

Redakcja: Dondu

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

Do niedawna każda rozmowa o wykorzystaniu WiFi i mikrokontrolera kończyła się tak:

WiFi i mikrokontroler? Hmm, to musi być drogie i skomplikowane!

Ale Chińczycy przekonali nas, że wcale tak być nie musi. Jakiś czas temu wypuścili tani moduł ESP8266 pełniący rolę łącznika z siecią bezprzewodową. Jest to kompletny moduł, który wymaga tylko podłączenia do mikrokontrolera przy pomocy interfejsu RS232-TTL lub SPI i już możemy korzystać z dostępu do sieci WiFi!

Ile ta przyjemność kosztuje?  2$ - 3$ w  zależności od wersji modułu.

Prostota podłączenia, niska cena, to wszystko powoduje, że WiFi stało się dostępne dla hobbystów i możemy je szeroko wykorzystywać w naszych projektach. Warto się więc nieco bliżej przypatrzeć temu modułowi.

Gdzie go kupić w dobrej cenie?

Jesteś wstępnie zainteresowany WiFi, tylko nie wiesz, gdzie go kupić? Obecnie jest on dostępny w wielu sklepach internetowych, a jego popularność stale rośnie, niewykluczone więc, że będzie także w twoim ulubionym „sklepie za rogiem”™.

W Polce można go kupić za około 25 zł (+koszty wysyłki). Jest to sporo, ale jeśli zależy ci na czasie, to jest to jedyna możliwość szybkiego zakupu. Niestety podatki i koszty prowadzenia działalności w Polsce nie ułatwiają życia hobbystom, stąd wysokie ceny.

Inna opcja to zakup na AliExpress lub eBay-u. Tu ceny są niskie (na poziomie 2-3$), lecz musimy się liczyć z czasem dostawy rzędu od 7 do 30 dni. Ale za to dostawa jest gratis!

W praktyce może nas spotkać przykra niespodzianka w postaci dodatkowych kosztów związanych z cłem i VATem, lecz jeśli zakup nie jest duży, najczęściej tego typu problemy nas ominą. Przytoczę więc informacje celne:

Z zastrzeżeniem art. 24 zwolnione z należności celnych przywozowych są przesyłki zawierające towary o niewielkiej wartości wysyłane bezpośrednio z państwa trzeciego do odbiorcy znajdującego się we Wspólnocie.

Do celów ust. 1 „towary o niewielkiej wartości” oznaczają towary, których rzeczywista wartość nie przekracza 150 EUR na przesyłkę.

oraz podatkowe dot. VAT:

Zwalnia się od podatku import towarów umieszczonych w przesyłkach wysyłanych z terytorium państwa trzeciego bezpośrednio do odbiorcy przebywającego na terytorium kraju, pod warunkiem że łączna wartość towarów w przesyłce nie przekracza kwoty wyrażonej w złotych odpowiadającej równowartości 22 euro.

Jeżeli zamawiasz towary w jednej przesyłce o znacznej wartości sprawdź aktualnie obowiązujące kwoty zwolnień.

Na zachętę dodam, że zazwyczaj czas dostawy jest znacznie krótszy i zdarzyło mi się otrzymać przesyłki wysłane z Chin już po paru dniach. Warto przed zakupem poczytać opinie o sprzedającym i sprawdzić ile układów sprzedał. Czasami warto dopłacić parę centów, ale kupić u pewnego sprzedawcy (co najmniej kilkaset pozytywnych komentarzy i wysokie oceny powyżej 95%) niż ryzykować.

---

Typy modułów

Przed zakupem musimy sobie odpowiedzieć na kilka ważnych pytań dotyczących typu modułu, który kupimy. Warto pamiętać, że niezależnie od oznaczeń, wszystkie moduły ESP8266 zawierają dokładnie ten sam chipset, lecz różnią się wielkością, typem wyprowadzeń, ich ilością i innymi szczegółami. Warto przed zakupem przemyśleć czego oczekujemy, żeby uniknąć sytuacji, gdy kupimy moduł z anteną PCB, a potem okaże się, że jego zasięg jest niewystarczający.

Moduł do podłączenia do PC

Moduł w wersji DIL – wszystkie sygnały wyprowadzone są w postaci goldpinów, o rozstawie pasującym do płytki stykowej. Do tego na module dostępny jest konwerter RS232-TTL-USB, dzięki czemu moduł możemy podłączyć bezpośrednio do komputera. Jest to wygodne, jeśli moduł wykorzystujemy jako wypasiony mikrokontroler z opcją WiFi i chcemy pisać programy dla niego bezpośrednio. Moduł taki nie nadaje się do podłączenia do mikrokontrolera. Cena wynosi ok. $9.

Moduł z konwerterem USB-RS232TTL

Gdy rozmiar jest ważny

Dla osób chcących kupić gotowy moduł zawierający wszystko, co potrzebne do pracy, godne polecenia są moduły z antena drukowaną, umieszczoną na PCB. Rozwiązanie to gwarantuje małe wymiary modułu, jednocześnie moduł zawiera wszystko, co potrzebne, aby nawiązać połączenie bezprzewodowe. Oczywiście jak zawsze coś za coś. Anteny na PCB są małe, ale co gorsze, w pobliżu mogą się znajdować inne elementy jeszcze bardziej pogarszające nadawanie i odbiór.

Moduł z anteną na PCB

Pamiętajmy, że wykorzystując tego typu moduły musimy zapewnić, aby w pobliżu anteny nie było dużych pól masy, ekranów, większych elementów elektronicznych, które mogą tłumić sygnał. Tego typu moduły nie mogą być umieszczone w metalowych obudowach. Musimy pamiętać, że nawet, jeśli spełnimy te wszystkie wymagania to zasięg modułu nie będzie duży.

Moduł z gniazdem antenowym i mikro anteną

Dla użytkowników, dla których ważny jest zasięg WiFi niezwykle ważne jest posiadanie na module gniazda dla anteny. Warto pamiętać, że anteny w postaci nadruku na PCB nie umożliwiają uzyskania dużego zasięgu i to z kilku powodów. Po pierwsze sprawność takiej anteny nie jest duża, po drugie – moduł zwykle lutujemy do płytki, umieszczamy w obudowie, co pogarsza warunki pracy anteny.

Jeśli na module mamy gniazdko do anteny zewnętrznej, to zawsze możemy wykorzystać lepszą antenę, wyprowadzić ją na zewnątrz, z dala od ekranów i elementów mogących zakłócić jej pracę.

Dlaczego po prostu samemu nie można kupić gniazdka i je wlutować? Pamiętajmy, że WiFi działa w paśmie 2,4 GHz, przy tej częstotliwości niezwykle ważne są efekty falowe, a każde połączenie to duża strata sygnału. Stąd też lepiej, jeśli producent umieścił gniazdo antenowe, zazwyczaj umieścił także inne elementy umożliwiające dopasowanie torów wyjściowych modułu do właściwości falowych gniazda i ścieżek łączących moduł z antena.

Moduł z gniazdem antenowym oraz mikro anteną Rainsun 

Mikro antena zastosowana w module to AN9520 o następujących parametrach:

Mikro antena: AN9520 (kopia)

Na module mogą znajdować się różne wersje gniazda antenowego. Zazwyczaj nie jest to gniazdo SMA (SubMiniature version A) ze względu na ograniczoną dostępność miejsca. Stąd też często wykorzystywane jest złącze MMCX (micro-miniature coaxial), a do modułu dodawany jest kabelek-przejściówka na zwykłe złącze SMA.

Konwerter na gniazdo SMA

Goldpiny, czy pola lutownicze?

Kolejny istotny wybór, jakiego musimy dokonać przy zakupie to decyzja o typie wyprowadzeń modułu. Do dyspozycji mamy dwa rozwiązania – goldpiny lub pola lutownicze. Goldpiny (listwy kołkowe) (zazwyczaj) umożliwiają łatwe łączenie modułu z płytką stykową, ewentualnie możemy je wykorzystać do przylutowania modułu we własnym układzie.

Jest to nieco mniej wygodne rozwiązanie, ale z „dziwnych” powodów część początkujących elektroników uwielbia elementy przewlekane, twierdząc, że łatwiej się je lutuje. Nie jest to prawdą, ale nie będziemy tego tu roztrząsać. Goldpiny mogą być wyprowadzone po obu stronach modułu (wtedy łatwo jest je wsunąć w płytkę stykową) lub po jednej stronie, najczęściej w postaci listwy dwurzędowej – w takiej sytuacji o wciśnięciu modułu w płytkę stykową możemy zapomnieć.

Moduł ze złączem DIL

Drugą opcją jest moduł z polami do lutowania. Moduł taki „nakłada” się na płytkę PCB, do której go chcemy przylutować, a na płytce-matce musimy umieścić odpowiednie pola lutownicze. Podstawową zaletą takiego połączenia jest to, że goldpiny nie zajmują dodatkowego miejsca na płytce, w efekcie całość wychodzi po prostu mniejsza.

Moduł z polami lutowniczymi

Jest jeszcze jedna istotna zaleta wykorzystania pól lutowniczych – te wersje modułu mają wyprowadzone zazwyczaj wszystkie sygnały IO (linie GPIO i ADC), natomiast moduły z goldpinami, często mają wyprowadzone tylko sygnały RS232-TTL, zasilanie i dwie linie GPIO.

Nie zawsze jest to przeszkodą, ale kupując moduł zawsze warto sprawdzić jakie sygnały mamy do dyspozycji.

---

Podłączenie modułu i zasilanie

Ok, mamy już moduł, czas zacząć przygodę. Moduł możemy wykorzystać na dwa sposoby:

• połączyć go z mikrokontrolerem i wykorzystać jako zwykły moduł bezprzewodowy,
• wykorzystać fakt, że moduł to układ SoC (system on chip), zwierający wydajny mikrokontroler, sporo RAM i FLASH, a więc możemy go programować bezpośrednio i w wielu wypadkach nie będziemy potrzebowali dodatkowego mikrokontrolera.

Tą druga możliwość omówimy później, zacznijmy na razie od typowego zastosowania – czyli modułu komunikacyjnego realizującego połączenie bezprzewodowe dla mikrokontrolera.

Zasilanie

Moduł wymaga zasilania w zakresie 3,0 - 3,6V, a średni pobierany prąd wynosi ok. 80 mA, przy czym w trakcie aktywnej pracy może wzrosnąć nawet do 200 mA. Stwarza to pewne problemy.

Przede wszystkim musimy zadbać o odpowiednią wydajność prądową zasilacza. Przy module warto też umieścić kondensator elektrolityczny o pojemności 47 - 220 µF i dodatkowo kondensator ceramiczny 100nF.

Drugi problem wynika z napięcia zasilającego – typowo 3,3V. Osoby stosujące nowoczesne mikrokontrolery (AVR, XMEGA, PIC i ARM) mogą moduł podłączyć z nimi bezpośrednio – mikrokontrolery te również zasilamy napięciem 3,3V.

Osoby wykorzystujące starsze AVRy (ATMega, ATTiny), często zasilane napięciem 5V mają dodatkowy problem – po pierwsze muszą w układzie umieścić dodatkowy stabilizator, generujący napięcie zasilania dla modułu WiFi (ew. kupić moduł zawierający już taki stabilizator), a dodatkowo musimy zbić napięcie na pinach wyjściowych (np. TxD) mikrokontrolera, łączących go z modułem WiFi.

Piny IO

Kolejną rzeczą na jaką należy zwrócić uwagę przy zakupie modułu to dostępne piny IO. Najprostsze moduły mają tylko 6 pinów, z czego część to piny zasilające i sterujące:

• GND
• Vcc (5V)
• Vcc (3,3V)
• TxD
• RxD
• chip enable (wybór układu)

Moduł bez wyprowadzonych pinów GPIO

Tego typu moduły mają niewielkie rozmiary, idealnie sprawdzają się w układach, w których moduł łączymy z mikrokontrolerem sterującym – w takiej sytuacji nie potrzebujemy dodatkowych pinów IO, wystarczą nam piny RxD i TxD do realizacji komunikacji mikrokontroler-moduł. Moduły te często (np. moduł pokazany na rysunku), posiadają dodatkowo konwertery poziomów, dzięki czemu piny IO można podłączyć do systemu mikrokontrolerowego zasilanego 5V, na module bywa też stabilizator 3,3V, dzięki czemu moduł możemy zasilać napięciem 5V lub, jeśli mamy do dyspozycji, napięciem 3,3V z pominięciem wbudowanego stabilizatora.

Warto pamiętać, że moduły posiadające na pokładzie stabilizator 3,3V często na liniach TxD i RxD mają odpowiednie konwertery napięć 5V-3,3V. Natomiast na innych liniach GPIO takich konwerterów nie ma. Jeśli je chcemy wykorzystać w naszym projekcie to musimy zadbać, aby napięcie na tych pinach nigdy nie wzrosło powyżej 3,6V, co grozi uszkodzeniem modułu.

Moduły, które nie mają wyprowadzonych GPIO bezpośrednio posiadają zworkę (lub pole lutownicze), które umożliwia wejście modułu w tryb uaktualniania oprogramowania.

Pola lutownicze umożliwiające upload nowego firmware i zmianę typu interfejsu

Tego typu moduły mają zwykle możliwość wykorzystania innych wyjść GPIO, lecz wymaga to bezpośredniego lutowania połączeń do modułu SoC. Dlatego, jeśli planujemy wykorzystać GPIO lepiej zakupić wersję modułu, w której piny te są wyprowadzone bezpośrednio.

Pokazana poniżej wersja modułu:

Moduł z wyprowadzonymi wszystkimi pinami GPIO

posiada wyprowadzone wszystkie sygnały. W tabeli poniżej zostały one pokrótce opisane:

Sygnał	Funkcja
Vcc	Zasilanie modułu (3,0-3,6 V), chyba, że moduł ma na pokładzie dodatkowy stabilizator napięcia
GND	Masa układu
MTMS	Sygnał interfejsu szeregowego lub pin GPIO14
MTDI	Sygnał interfejsu szeregowego lub pin GPIO12
MTCK	Sygnał interfejsu szeregowego lub pin GPIO13
MTDO	Sygnał interfejsu szeregowego lub pin GPIO15
RxD	Wejście sygnału RxD – należy połączyć z wyjściem TxD mikrokontrolera
TxD	Wyjście sygnału TxD – należy połączyć z wejściem RxD mikrokontrolera
REST, RSTB	Sygnał zerowania układu, aktywny w stanie niskim
ADC	Wejście sygnału dla 10-bitowego przetwornika ADC
CH_PD, CHIP_EN	W czasie normalnej pracy powinien być w stanie wysokim, podanie stanu niskiego wymusza uśpienie układu i wejście w tryb o niskim poborze energii
GPIO0, GPIO2	Piny IO ogólnego przeznaczenia, lecz w czasie startu ich stan określa tryb pracy układu
GPIOx	Piny IO ogólnego przeznaczenia, mogą być wykorzystane do komunikacji z innymi układami

W czasie resetu modułu sygnały MTDO, GPIO0 i GPIO2 pełnią specjalną funkcję:

MTDO	GPIO0	GPIO2	Funkcja
1	X	X	Wybór interfejsu SDIO/SPI
0	0	1	Uaktualnianie firmware przez USART
0	1	1	Bootowanie z FLASH

Sygnał MTDO powinien mieć stale stan niski – powoduje to, że moduł będzie się komunikował poprzez interfejs UART, jeśli nadamy mu stan wysoki to wybrany zostanie interfejs SDIO/SPI.

Jeśli wybierzemy interfejs UART (znakomita większość przykładów go wykorzystuje), to sygnały GPIO0/2 określają skąd SoC będzie brał kod programu.

Jeśli GPIO0/2 będą w stanie wysokim to moduł zabootuje się z obecnej na nim pamięci FLASH (tą opcję powinniśmy wybrać), jeśli GPIO0 będzie miało niski poziom logiczny to moduł będzie oczekiwał nowego firmware dostarczonego przez interfejs UART.

W kolejnej części poznamy nieco więcej tajemnic układu ESP8266.