ESP8266 - brak odpowiedzi serwera przy wysyłaniu zapytania przez UART

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:


i po chwili


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:


i po chwili


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:



która korzysta z:



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


i po chwili


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

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.

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

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 ?

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

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.

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

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.

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

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

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

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.

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

@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.

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

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

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

Możesz odpalić sobie pod wierszem poleceń kompilację i włożyć biblioteki pod Eclipse - choć wtedy nie trwa to 5 minut

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.

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"

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

Wersja oprogramowania to:

AT - 0.25.0.0.

SDK - 1.1.1

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