Mikrokontrolery - Jak zacząć?

... czyli zbiór praktycznej wiedzy dot. mikrokontrolerów.

środa, 30 marca 2011

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 ESP8266
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 ESP8266
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.
Oceń artykuł.
Wasze opinie są dla nas ważne, gdyż pozwalają dopracować poszczególne artykuły.
Pozdrawiamy, Autorzy
Ten artykuł oceniam na:

25 komentarzy:

  1. Witam. Czy będzie przykład jak serwer odpowiada do poszczególnych klientów?

    OdpowiedzUsuń
    Odpowiedzi
    1. Tak, w kolejnej części. Niemniej pozycja serwer-klient nie ma znaczenia, Odpowiedź wysyła się identycznie jak po stronie klienta.

      Usuń
  2. Ja z kolei czekam na programowanie samych ESP, np ADC I2C itd aby wykorzystać jak atmegę. Jednak dzięki za udostępnienie kolejnej części i z niecierpliwością czekam na następne!

    OdpowiedzUsuń
    Odpowiedzi
    1. Będzie i to, ale raczej już po Świętach, z przyczyn oczywistych...:)

      Usuń
  3. artykuł zachęcił mnie do zakupu ESP

    OdpowiedzUsuń
  4. Witam,
    Czy da się pozbyć tego elementu: "+IPD,0,42:"
    Czy ustawiając komunikację na AT+CIPMUX=1 (single connection) ten element zniknie?

    Abstrahując od powyższych pytań. W dokumencie: https://acrobotic.com/downloads/ESP8266_at_commands.pdf

    Znalazłem takie coś:
    " UART-WiFi passthrough mode (transparent transmission) can only be enabled in TCP single connection mode or UDP of which remote IP and port won’t change (parameter is 0
    when using command “AT+CIPSTART” to create a UDP transmission) . "

    Zgodnie z powyższym nie można ustawić transparent transmission (UART-WiFi passthrough mode) dla multiple connection.

    Prosiłbym o wyjaśnienie.
    Pozdrawiam
    PK

    OdpowiedzUsuń
  5. Witam, chciałbym dowiedzieć się czy w takiej konfiguracji moduły komunikują się bezpośrednio ze sobą czy przez AP w moim przypadku to router?

    OdpowiedzUsuń
    Odpowiedzi
    1. Zawsze poprzez router, chyba, że jeden z nich pracuje w trybie AP.

      Usuń
  6. Byłby ktoś w stanie powiedzieć jak skonfigurować moduły tak aby móc je łączyć bezpośrednio ze sobą?

    OdpowiedzUsuń
    Odpowiedzi
    1. W sensie bez routera

      Usuń
    2. A zastanów się, czy sieć WiFi umożliwia wymianę danych bez AP...

      Usuń
    3. Bez routera w sensie bez dodatkowego urządzenia.
      Próbowałem tworzyć AP i komunikować się, ale nie wychodziło mi.

      Usuń
    4. Tak chyba działa WiFi Direct :-) Taka opcja faktycznie była by przydatna.

      Usuń
  7. Czyli nie da się skomunikować dwóch modułów bezpośrednio ze sobą bez routera? Jeżeli tak to szkoda bo noszenie ze sobą dodatkowego routera przy wykorzystaniu modułu jako aparatura RC będzie uciążliwe:/

    OdpowiedzUsuń
    Odpowiedzi
    1. Ja sam nie próbowałem / nie testowałem, ale wg źródeł internetowych bez problemu da się:
      http://www.esp8266.com/viewtopic.php?f=152&t=8720

      Jeśli szerzej poczytasz ten serwis, to okaże się że generalnie nie ma takiej dziedziny ludzkiego życia, której nie obsłuży się za pomocą ESP8266 ;-)


      Usuń
  8. A ja mam pytanie i innej bajki. W jaki sposób sprawdzić IP i Port z którego nadeszła wiadomość do ESP po odebraniu pakietu UDP? Czy w ogóle jest taka możliwość ? Mam podłączone ESP pod atmegę.

    OdpowiedzUsuń
    Odpowiedzi
    1. Tu masz przykładowy kod jak odczytać IP nadawcy z komunikatu UDP:

      http://www.esp8266.com/viewtopic.php?p=42244

      Testowałem osobiście, działa OK.

      Usuń
  9. A ilu klientów może obsłużyć UDP server?

    OdpowiedzUsuń
    Odpowiedzi
    1. Protokół UDP jest bezpołączeniowy, więc nie ma limitu klientów. Kwestia tylko jak szybko obsługujesz nadchodzące pakiety.

      Usuń
  10. Witam, mam pytanie...czy miał ktoś problem z prędkością wysyłania pakietów poleceniem AT+CIPSEND=0,6? Mianowicie ESP8266-01 wysyła 2-3 pakietów/sek co w połączeniu z czujnikami typu akcelerometr prowadzi do tracenia ogromnej ilości informacji (akcelerometr pracuje z częstotliwością 100Hz). Istnieje jakieś rozwiązanie?

    OdpowiedzUsuń
  11. W artykule zabrakło opisu jak zrobić wysyłanie danych od klienta do serwera. Czy ktoś mógłby napisać jak to zrobić? Czy trzeba stworzyć nowy kanał, dwa serwery?

    OdpowiedzUsuń
    Odpowiedzi
    1. Napisano :) AT+CIPSEND :) W druga stronę zresztą robi się to dokładnie tak samo :)

      Usuń
  12. Tego własnie potrzebowałem.

    OdpowiedzUsuń
  13. Witam forumowiczów, może jeszcze ktoś do tego artykułu zagląda.
    Brak mi totalnej podstawy, fundamentu.
    Może ktoś znajdzie chwile i napiszę zdanie lub dwa, proszę bo stoję z projektem.
    Potrafię ESP skonfigurować na różne tryby pracy. Wszystko mi działa ale brak mi podstaw, doświadczenia jak zorganizować komunikację.
    Mam cztery czujniki i jedna stację odbiorczą. Stacja co jakiś czas ma odczytywać dane ale ma też istnieć możliwość wysłania danych przez czujnik w wyniku zajścia nieoczekiwanej zmiany.
    Do tej pory pracowałem po kablu więc wiadomo rs485 i układ master/slave.
    Teraz chcę zacząć przygodę z TCPIP.
    Czy powinienem czujniki ustawić na serwery które nasłuchują kiedy stacja je odpyta, ale co w przypadku kiedy czujnik chce nadać. Bez podłączenia stacji jako klient czujnik nie ma zestawionego połączenia i nie ma jak oddać informacji.
    A może czujniki powinny być serwerami i stacja centralna również. Wtedy jak jest planowe odczytanie pomiarów to stacja przełącza konfigurację na klienta i podłącza się kolejno do czujników zbierając dane. W takim układzie jak czujnik będzie chciał przesłać informację o niespodziewanej zmianie to przełączy się na klienta podłączy do stacji centralnej i wyśle co ma wysłać.
    W tym przypadku trzeba by obsłużyć ewentualne błędy w komunikacji gdy stacja będzie w trybie klient a jakiś czujnik będzie chciał coś wysłać ale to się da zrobić.
    Czy tak powinienem zorganizować komunikację w mojej sytuacji?
    Sposób komunikacji jest tu kluczową sprawą dlatego tak to drążę.
    Robert

    OdpowiedzUsuń

Działy
Działy dodatkowe
Inne
O blogu




Dzisiaj
--> za darmo!!! <--
1. USBasp
2. microBOARD M8


Napisz artykuł
--> i wygraj nagrodę. <--


Co nowego na blogu?
Śledź naszego Facebook-a



Co nowego na blogu?
Śledź nas na Google+

/* 20140911 Wyłączona prawa kolumna */
  • 00

    dni

  • 00

    godzin

  • :
  • 00

    minut

  • :
  • 00

    sekund

Nie czekaj do ostatniego dnia!
Jakość opisu projektu także jest istotna (pkt 9.2 regulaminu).

Sponsorzy:

Zapamiętaj ten artykuł w moim prywatnym spisie treści.