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 - konstrukcja odpowiedzi AT

robiw 12 Lut 2017 15:44 1539 13
  • #1 12 Lut 2017 15:44
    robiw
    Poziom 26  

    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.

  • #2 12 Lut 2017 18:28
    Piotrus_999
    Poziom 39  

    robiw napisał:
    "CO"..., nie zwraca dla przykładu znaku ">"
    po prostu funkcja nie działa tak jak myślisz, osobiście uważam że bład jest w linii 34 lub 35. Nie wiem czy koledzy się ze mną zgodzą?

    Dodano po 31 [minuty]:

    Ciekawe po co mnie zgłaszać do moderatora. Jak bez kodu można pomóc?

  • #3 12 Lut 2017 19:57
    robiw
    Poziom 26  

    ;-). Kod załączę jutro...robiw

  • #4 13 Lut 2017 09:25
    robiw
    Poziom 26  

    Zmienne:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Funkcja:

    Kod: c
    Zaloguj się, aby zobaczyć kod


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

  • #6 13 Lut 2017 11:17
    robiw
    Poziom 26  

    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

  • #7 13 Lut 2017 11:32
    niveasoft
    Poziom 34  

    Nie, nie jest.
    Kiedyś też używałem LF do wykrycia końca linii, ale to w przypadku ESP8266 nie jest dobry sposób.
    Lepiej jest wiedzieć jakiej odpowiedzi oczekujesz i szukać jej w odebranych danych z jakimś Timeoutem.

    Na dodatek przy starcie ESP wysyła jakieś binarne dane do softu na PC i z tym tez niektóre parsery sobie nie radzą.

  • #8 13 Lut 2017 11:54
    Piotrus_999
    Poziom 39  

    niveasoft napisał:
    tylko string do znaku NULL a w buforze może już być następny znak a Ty ustawiasz Index na 0
    Nie może być z dwóch przyczyn.

    1. Jesteś w środku przerwania a sei nie było
    2. Kopiowanie jest raczej szybkie


    Jedna uwaga na marginesie. Używanie takich funkcji jak strcpy, o których kompilator nic nie wie w przerwaniu może skutkowac odkładaniem dużej ilości rejestrów na stosie (bo w końcu on nie wie jakich funkcja używa) i powodować wzrost czasu wykonania przerwania oraz rozmiaru kodu w stosunku do np jakiegoś loopa kopiującego dane.

    Przy okazji sprawdzałeś czy komunikacja idzie jak należy?

  • #9 13 Lut 2017 12:30
    grko
    Poziom 31  

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

  • #10 13 Lut 2017 13:12
    Piotrus_999
    Poziom 39  

    @grko Po prostu w przerwaniu jak użyjesz funkcji "nieznanej" to masz:

    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    i to zasygnalizowałem, pamiętając ostatnie dyskusje o odkładaniu dużej ilości rejestrów na stos. Może właśnie użycie funkcji bibliotecznej było problemem . Warto brać pod uwagę.

  • #11 13 Lut 2017 13:23
    niveasoft
    Poziom 34  

    @Piotrus
    Kiedy zauważyłem że to USART0_RX_vect to wycofałem się z tej wypowiedzi i nie ma jej w moim poście.

    @robiw
    Program Realterm ma tę właściwość (pewnie jakiś inny też), że pokazuje znaki CR i LF nawet je kolorując. Można sprawnie podejrzeć która odpowiedź modemu jest nimi zakończona.
    Wydaje mi się ze modem w którymś miejscu wysyła samo polecenie nowej linii po czym zaczyna pisać. To chyba tym wszystkim parserom sprawia trudność bo sa w trakcie analizy po znaku LF a nowe dane spływają natychmiast.
    Pisze trochę z pamięci, ale jak pisałem lepiej podejrzeć to Realtermem.

  • #12 13 Lut 2017 13:28
    Piotrus_999
    Poziom 39  

    niveasoft napisał:
    To chyba tym wszystkim parserom sprawia trudność bo sa w trakcie analizy po znaku LF a nowe dane spływają natychmiast
    Toż to żaden parser. Tylko czeka na koniec linii. A'propos przy takiej prędkości, sądzę że w przerwaniu i tokenizację jakiegoś języka byś zdążył zrobić.

  • #13 13 Lut 2017 14:04
    robiw
    Poziom 26  

    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

  • #14 16 Lut 2017 00:45
    dondu
    Moderator Mikrokontrolery Projektowanie

    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.

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