ESP8266 - specyfikacja zakończenia odpowiedzi AT (CR, LF, CR CR LF?)

Witam Kolegów,
Moje pytanie dotyczy specyfikacji odpowiedzi modemu ESP8266 wysyłanych do mikrokontrolera (USART, 115200bps). Czy każda odpowiedź modemu kończy się parą znaków CR i LF, a może być to CR CR i LF czy jeszcze inaczej? Napisałem prostą funkcję opartą o ISR odbiornika USART, która każdy bajt przychodzący zapamiętuje w C-stringu, aż do napotkania znaku LF. Po jego napotkaniu zwraca C-string, jako odpowiedź modułu (przepisuje C-string funkcji ISR do innego C-stringa dla funkcji main - takie buforowanie)...no i właśnie, nie zawsze działa to dobrze. Np. odpowiedź modułu "CONNECT" zwraca tylko jako "CO"..., nie zwraca dla przykładu znaku ">", który modem wysyła w oczekiwaniu na dane TCP...itd. Ma ktoś jakieś doświadczenia w tej materii? Z góry serdeczne dzięki... robiw

PS.
Nie umieszczam kodu, który jest banalnie prosty, bo jestem poza domem bez dostępu do komputera, w którym go mam.

. Kod załączę jutro...robiw

Zmienne:



Funkcja:



No i nie działa prawidłowo, jak pisałem wcześniej... robiw

@robiw Może po prostu kolejne dane od ESP8266 nadpisują Ci dane w modemReply zanim je zdążysz wyświetlić na porcie szeregowym.

Nie, bo one przychodzą rzadko. Zmniejszyłem prędkość ze standardowych 115200 na 9600 i działa jakby lepiej, tzn. przychodzi już cała odpowiedź "CONNECT" a nie tylko "CO". Pytanie, czy każda linia odpowiedzi modemu zakończona jest sekwencją bajtów CR+LF? robiw

@Piotrus_999 Używanie pętli for zamiast standardowych funkcji memcpy/strcpy. Świetny pomysł na zastępowanie specjalnie zoptymalizowanej dla AVR funkcji na rzecz tępej pętli for.

@robiw Możesz uniknąć tego kopiowania robiąc sobie 2 bufory. Jeden wypełniasz w przerwaniu a z drugiego korzystasz w wątku głównym. Po otrzymaniu znaku końca linii zmieniasz po prostu po prostu wskaźnik na aktywny bufor.

Jutro sprawdzę dokładnie, ale wydaje się, że po zmniejszeniu prędkości do 9600 bps wszystko "śmiga" lepiej. Procesor taktowany jest 11.059MHz, więc te 115200 bps to nie było dla niego mało, zwłaszcza, że docelowo w przerwaniu mają być parsowane dane do wielu zmiennych zebranych w strukturę. W Realterm'ie podglądałem i linie kończone są albo sekwencją CR+LF lub znacznie częściej samym LF. Wyjątkiem jest OK, który występuje, jako sekwencja CR+LF OK CR+LF. Czasami w odpowiedziach pojawia się też sam LF... robiw

robiw napisał:

W Realterm'ie podglądałem i linie kończone są albo sekwencją CR+LF lub znacznie częściej samym LF. Wyjątkiem jest OK, który występuje, jako sekwencja CR+LF OK CR+LF. Czasami w odpowiedziach pojawia się też sam LF... robiw

A jaki tryb wyświetlania wybrałeś Ansi? Ascii? ... oba są złe, bo Realterm nie wyświetla wszystkich odebranych bajtów.

Zawsze podglądaj w trybie Hex, najlepiej Hex+Ascii.