Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ESP8266 - wysyłanie zapytania do serwera?

robiw 14 Lut 2017 14:14 1698 23
  • #1 14 Lut 2017 14:14
    robiw
    Poziom 26  

    Witam Kolegów,
    Borykam się z problemem wysłania kompletnego zapytania do serwera pogodowego. Proces ten wykonywany z terminala RealTerm lub Terminal by Br@y++ kończy się powodzeniem, czyli odebraniem wysyłanych po chwili danych z serwera pogodowego, zaś wykonywany z poziomu procesora (przez UART'a) kończy się brakiem odpowiedzi ze strony serwera i timeout'em serwera. Podejrzewam, że funkcja po stronie procesora w inny sposób interpretuje i wysyła znaki specjalne, zaś terminale w inny sposób i stąd serwer nie dostaje kompletnego zapytania. Poniżej podam przykłady:

    w RealTerm'ie wysyłam:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    i po chwili
    Kod: c
    Zaloguj się, aby zobaczyć kod


    zaznaczając każdorazowo by dołączał na końcu CR+LF i na takie zapytanie dostaję poprawną odpowiedź serwera. Podobnie w terminalu Br@y++ wysyłam:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    i po chwili
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Czyli generalnie to samo, tylko w inny sposób koduję znaki specjalne. Jeśli chodzi o procesor to do wysyłania zaprzęgam prostą funkcję, jak niżej:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    która korzysta z:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    i wysyłam to samo, co wyżej w następujący sposób:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    i po chwili
    Kod: c
    Zaloguj się, aby zobaczyć kod


    No i lipa... serwer nie odpowiada tylko oczekuje i oczekuje po czym zgłasza timeout...tak, jakby zapytanie nie było kompletne. Prośba o sugestie, za które z góry dziękuję... robiw

  • #2 14 Lut 2017 14:56
    raceman
    Poziom 18  

    Kolego, robie różne projekty na ESP8266 i powiem jedno. Zapomnij o używaniu koment AT. Też straciłem mnóstwo czasu na walke z web serwerem. Chodziło to to jako tako, ale po przejściu na interfejs arduino z menadżerem płytki ESP8266, jak ręką odjął.
    Programujesz normalnie jak w C pod środowiskiem arduino, ale kod jest kompilowany od razu na ESP8266.

    Tutaj znajdziesz wszystko : https://github.com/esp8266/Arduino

    Do tego masz gotowe biblioteki.

  • #3 14 Lut 2017 15:01
    robiw
    Poziom 26  

    Nie znam Arduino i w zasadzie nie chcę znać. Poza tym projekt wykorzystuje TFT i inne podzespoły. Muszę to obsługiwać przez AT...robiw

  • #4 14 Lut 2017 15:11
    raceman
    Poziom 18  

    No, ale Arduino (software) to tylko nakładka. Przecież twój kod jest w C+.
    Nie mówie o Arduino w kontekscie sprzętu tylko software.
    Może opisz dokładnie co robisz i na jkim sprzęcie ?

  • #5 14 Lut 2017 16:03
    robiw
    Poziom 26  

    Wysyłam USARTem, jak napisałem. Niestety z terminala działa a z USARTanie chce, więc to pewnie kwestia znaków specjalnych...robiw

    Dodano po 3 [minuty]:

    Mój kod jest w C. Poza tym ten sam procesor obsługuje jeszcze wyświetlacz TFT. Skoro na terminalu działa a z USARTa nie to wina jest kodu...robiw

  • #6 14 Lut 2017 19:23
    raceman
    Poziom 18  

    Doświadczyłem wielokrotnie problemu, gdy ciągi znaków były zbyt długie. Nie do końca wiem z czym to było związane, ale coś gdzieś czytałem o małym buforze.
    Spróbuj podzielić ostatnią sekwencję na 3 osobne (kończąć linie znakami \r\n ). Powinno pomóc.

  • #7 14 Lut 2017 21:01
    robiw
    Poziom 26  

    Ale skoro z terminala Windowsowego idzie bez problemu, to nie wydaje się, że to jest problem bufora. Poza tym, w tym długim ciągu są elementy \r\n, więc jakbym miał go podzielić? Poza tym jaką wartość wtedy ustawić dla AT+CIPSEND=126\r\n??? robiw

  • Pomocny post
    #8 15 Lut 2017 10:43
    raceman
    Poziom 18  

    Napisz proszę czego używasz do komunikacji z ESP8266. Jak rozumiem w pierwszym przypadku jest to PC (terminal), a w drugim jakiś zewnętrzny mikroprocesor (Raspberry czy co ?). W obu przypadkach komunikacja odbywa się po RS232 z modułem ESP8266.Czy tak?

    Domyślam się, że chcesz ściągnąć dane o przewidywanej pogodzie poprzez API dostawcy usług wether underground.

    Wejdz tu https://github.com/squix78/esp8266-weather-station.. Tam masz wszystko, wraz z kodem zrodlowym.

    Zapytanie do serwera powinno wyglądać następująco:

    client.print(String("GET ") + url + " HTTP/1.1\r\n" + "Host: api.wunderground.com\r\n" + "Connection: close\r\n\r\n");

    i z tego co widzę prawidłowo do skonstruowałeś, ale nie wiem czy prawidłowo działa w tym przypadku funkcja PSTR. Możliwe, że znaki specjalne (\) musisz jakoś oznaczyć.
    Zeby to sprawdzić wpisz po prostu adres (nie jako zmienna do konwersji na string) i zobacz czy zadziała.

  • #9 15 Lut 2017 11:54
    94075
    Usunięty  
  • #10 15 Lut 2017 17:19
    robiw
    Poziom 26  

    albertb napisał:
    Zamiast marnować czas swój, nasz i zasoby internetu wyślij oba ciągi do komputera i porównaj odebrane. Albert


    Nie ma to, jak błyskotliwa odpowiedź ;-). Problem rozwiązany, więc opiszę go tutaj. Ach te chińskie zabawki...

    Należało po wysłaniu każdego bajta wstawić niewielkie opóźnienie (5ms dla 9600bps) wtedy pięknie wszystko działa. Dziwne, bo przecież powinno to działać przy wysyłaniu bajtu po bajcie...a jednak nie działało...robiw

  • #12 17 Lut 2017 13:19
    raceman
    Poziom 18  

    dondu napisał:
    Nie ma potrzeby wstawiania jakiegokolwiek opóźnienia. W jakiej wersji masz moduł i jaki firmware?


    To wszystko zależy. Sterując komendami AT modułem ESP z zewnętrznego kontrolera często bywa, że są z tym problemy (jak już pisałem wyżej) i opóźnienie może pomóc, ale nie musi.

    Obawiam się, że skoro do tej pory nie uzyskaliśmy odpowiedzi czego kolega używa jako sterownika modułu ESP to i wersja samego modułu i firmware pozostanie tajemnicą.

    Chyba można zamknąć temat

  • #13 17 Lut 2017 13:46
    dondu
    Moderator Mikrokontrolery Projektowanie

    raceman napisał:
    dondu napisał:
    Nie ma potrzeby wstawiania jakiegokolwiek opóźnienia. W jakiej wersji masz moduł i jaki firmware?


    To wszystko zależy. Sterując komendami AT modułem ESP z zewnętrznego kontrolera często bywa, że są z tym problemy (jak już pisałem wyżej) i opóźnienie może pomóc, ale nie musi.

    Nie spotkałem się z żadnymi problemami dot. tego co kolega sugeruje.
    Transmisje latają bez żadnych dodatkowych opóźnień.

    Być może jest to problem jakiejś starszej wersji firmware, dlatego też pytałem o to.

  • #14 17 Lut 2017 14:21
    robiw
    Poziom 26  

    Odpowiem, odpowiem, tylko muszę dorwać chwilę wolnego czasu na sprawdzenie. Kontroler to Atmega64. Bez opóźnienia w funkcji wysyłającej bajty nie działa, z terminala działa. Robiw

  • #15 17 Lut 2017 15:01
    piotrva
    Moderator Mikrokontrolery

    @robiw
    To zachowanie i dodawanie opóźnień jest dziwne. Mam spore doświadczenie z ESP8266 i powiem tak - firmware do komend AT to totalny złom.

    Ja w swoich projektach robię tak, ze piszę na ESP własny firmware, który zajmuje się całą komunikacją sieciową. Np. co minutę sprawdza zawartość jakiejś strony, analizuje jej treść a do uC posyła po UART tylko obrobione dane (np. temperaturę, stan jaki mają mieć diody, tekst do wyświetlenia na LCD, ...). W druga stronę podobnie wysyłam do ESP prosty ciąg, np. 10, a już ESP wie, że ma wywołać stronę http: //bal.bla.com/abecadlo/zapisz.php?x=10.

    Tobie też polecam takie rozwiązanie.

    Ostatnio tak robiłem moduł do transmisji podczerwieni po WiFi - ponieważ ESP nie daje rady z dekodowaniem kodów (nie ma odpowiednich timerów dostępnych) to w układzie siedzi sobie malutki STM32F0, który dekoduje ramki i kontroluje nadawanie, i do ESP wysyła np. IR:typ_transmisji:kod\r\n, i podobnie oczekuje na IRSEND:typ:kod\r\n, aby coś nadać. Zaś sama transmisja po UDP lub TCP (w tym szyfrowanie SSL) i interfejs do konfiguracji urządzenia przez http siedzi w ESP.

  • #16 17 Lut 2017 16:05
    robiw
    Poziom 26  

    Nie znam softu ESP, więc nie chcę pisać oddzielnego programu dla modułu (w tym kompilować go i wgrywać) i dla mojego urządzenia, które oprócz obsługi wyświetlacza TFT obsługuje też klawiaturę, podczerwień, czujnik temperatury itp itd...robiw

  • #17 17 Lut 2017 16:22
    piotrva
    Moderator Mikrokontrolery

    robiw napisał:
    Nie znam softu ESP, więc nie chcę pisać oddzielnego programu dla modułu (w tym kompilować go i wgrywać)

    To najwyższy czas poznać. Skoro piszesz w C czy C++ - kwestia instalacji pod Arduino (5 minut) i pogrzebania w examplach (30 minut) i viola. Uwierz - będzie prościej niż bawić się z komendami AT - ale rób jak uważasz ;)

  • #18 17 Lut 2017 18:01
    robiw
    Poziom 26  

    Nie lubię Arduino ;-) znaczy się Bascomino hehe. Już dawno temu przesiadłem się z Bascoma na C by znowu wracać do środowiska podobnego...robiw

  • #20 17 Lut 2017 19:19
    raceman
    Poziom 18  

    robiw napisał:
    Nie lubię Arduino ;-) znaczy się Bascomino hehe. Już dawno temu przesiadłem się z Bascoma na C by znowu wracać do środowiska podobnego...robiw


    Jak gra w szachy z gołębiem. Arduino w przypadku nakładki do ESP nie jest w niczym podobne do Bascoma. Programujesz normalnie w C++. i jak byś chciał wiedzieć W ESP masz procesor 80Mhz z kilkoma fajnymi rozwiązaniami w odróżnieniu od AVR, które właściwie jest tym samym co płytki arduino (ATMEGA itp), ktorymi tak gardzisz.

    Używanie komend AVR do sterowania ESP komendami AT to ....brak słów.

  • #21 18 Lut 2017 13:14
    krzbor
    Poziom 13  

    Muszę poprzeć kolegów. Arduino (czyli język C) to najlepsze oprogramowanie do ESP. Nie stwarza problemów, a jeśli w przyszłości będziesz musiał zmienić uszkodzony moduł ESP to lepiej do niego wgrać ponownie swój program, a nie martwić się o różniący firmware (komendy AT). Jeśli ktoś chce stworzyć kilka urządzeń, to może się okazać, że działają różnie, gdyż pochodzą od różnych producentów i mają rożny firmware. Wiele rzeczy można zrobić bezpośrednio na ESP, ale jeśli ktoś chce lub musi, wystarczy użyć UART, po którym idzie własna, dopasowana komunikacja, a nie AT.
    I jeszcze jedna uwaga - sugeruję użycie protokołu http 1.0 a nie 1.1. Niektóre serwery mogą kombinować przy wysyłce w 1.1. Szczególnie kłopotliwy jest "Chunked transfer-coding"

  • #22 18 Lut 2017 13:28
    robiw
    Poziom 26  

    Niczym nie gardzę, to po pierwsze. Po drugie odnosiłem się do samego Arduino w kwestii składni typu Serial.Find i tym podobnych, czyli używania gotowców, bibliotek itp...ale nie chcę tu rozpętywać wojny nt. języka. W swoim projekcie potrzebuję ponad 20 portów, więc muszę użyć kontrolera zewnętrznego zwłaszcza, że programuję w C na AVR (nie C++). Tyle z grubsza...robiw

  • #23 21 Lut 2017 09:40
    robiw
    Poziom 26  

    Wersja oprogramowania to:

    AT - 0.25.0.0.

    SDK - 1.1.1

  • #24 21 Lut 2017 13:17
    raceman
    Poziom 18  

    No to mega stara wersja zarówno AT jak i SDK.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME