Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
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 2049 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 40  

    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
    373522
    Usunięty  
  • #8 13 Lut 2017 11:54
    Piotrus_999
    Poziom 40  

    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 32  

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

    @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
    373522
    Usunięty  
  • #12 13 Lut 2017 13:28
    Piotrus_999
    Poziom 40  

    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.

 
Black Friday do -15%
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
Ferguson