Nad tym problemem siedzę już pół dnia, być może jutro go sam jakoś rozwikłam,
ale,
gdyby ktoś chciał pochylić się nad wyjaśnieniem, to byłoby miło.

Problem jest taki, PRZED pętlą główną wysyłam do urządzenia cztery komendy.
Po każdej ma być odpowiedź OK\r i to muszę wiedzieć, bo wtedy jest wszystko że tak powiem OK.

Z kolei w funkcji zdarzeniowej jak wiadomo, bo korzystam z bibliotek z BB i GB, if ascii_line, to odbieram string z bufora cyklicznego i wywołuję funkcję collbackową, która miedzy innymi wygląda tak:

Na wyświetlaczu LCD otrzymuję co te 0,5 sek (wiersz 0 i wiersz 1):
AT0
0
następnie:
AT1
1
następnie:
AT2
2
a teraz uwaga:
null
3 4 5 6 7
Powiedzmy, że po komendzie AT2 otrzymuję odpowiedź OK z dodatkowymi czterema znakami CR (ile tych znaków, tego nie wiem).
Gdyby były dodatkowe znaki CR, nawet i 100, to string byłby pusty, zwiększa się tylko licznik ascii_line.

Zdarzenie UART_RX_STR_EVENT(uart_buf) obsługuje jeden string, to skąd mam tę 7?

Z góry dziekuję za zainteresowanie.

------------------------ [ Dodano po: 24 minutach ]

Chyba wiem.
W pętli głównej mam tylko to:

Ponieważ po ostatniej komendzie AT3 nie dałem jakiegoś delaya więc nie widziałem, że wszystko było poprawnie.
A te nadmiarowe CR to zapewne już są (były) odpowiedziami urządzenia po AT3, ale już z pętli głównej i dlatego doliczało do 7.

Jutro to sprawdzę.

Po pierwsze, jak widać nie należy się śpieszyć z otwarciem nowego postu, bo to może być mało interesujące dla forumowiczów.

Po drugie ten post jest przykładem na to, że jak się opisze problem, to zaraz jest łatwiej dojść o co chodzi.

Twoim problemem w kodzie jest niestety przede wszystkim i od tego trzeba zacząć MEGA nieszczęsny _delay_ms(500); a do tego użycie zdarzenia kompletnie niezgodnie z jego przeznaczeniem

to wszystko MUSI się dziać zupełnie asynchronicznie a tymczasem to co robisz to jakiś powrót do programowania liniowego niestety ...

-------------------------------------

trzeba sobie dobrze przemyśleć algorytm działań asynchronicznych

jeśli potrzebujesz wysyłać kilka poleceń, jedno po drugim, ale tak że każde następne ma być wysłane aż nadleci odpowiedź z poprzedniego to MUSISZ jeszcze rozważyć:

1. reakcję na błędy: ERROR (zakładam, że mówisz o modemie)
2. reakcję na brak odzewu z urządzenia czyli TIMEOUT

a nie tylko reakcję na komunikat OK

Zatem jak widzisz wygląda to tak jakby się sytuacja gmatwała coraz bardziej i była coraz trudniejsza, ale


.... co za problem powołać sobie np timer programowy, który będzie odpalany po każdej odpowiedzi OK z urządzenia, zaś w tym timerze będą cyklicznie wysyłane jakieś polecenia z tablicy którą wcześniej przygotujesz. Wtedy wystarczy, że ręcznie zainicjujesz wysłanie pierwszego polecenia - a kolejnymi już zajmie się timer programowy. Oczywiście możesz wtedy również spokojnie reagować i na błędy i na timeout'y

-----------------------

jest jeszcze trochę innych sposobów ale najpierw wypróbuj choćby ten - żeby przede wszystkim zrozumieć NAJWAŻNIEJSZĄ rzecz

ZAPOMNIJ o _delay'ach przy obsłudze odbioru danych z RS232 w oparciu o zdarzenia. ZAPOMNIJ o takim stosowaniu zdarzenia odbiorczego - jakby ono miało być jakimś cudownym oczekiwaniem na reakcję - a widać po twoich próbach kodu - że to tak nie działa, dlatego próbowałeś się dramatycznie ratować paskudnym DELAYEM po wysłaniu komendy... Uwierz mi to jest zgroza I jak już zaszedłeś na tyle daleko żeby sięgnąć po zdarzenia do obsługi UART'a , callbacki i parsowanie danych - to nie zapominaj np o technice timerów programowych itp

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Instrukcje muszą się u mnie wykonać tylko RAZ, a ja nie wiem jak długo muszę czekać na odpowiedź. Dlatego powróciłem do programowania liniowego PRZED pętlą główną.

Dopiero dalej, w pętli głównej mam działanie nieblokujące, bez delay.

P.S. Resztę odpowiedzi przemyślę później.

Już przemyślałem.

Dziękuję za cenne uwagi.

Wprawdzie post mój z początku dotyczył czegoś innego,
a sprawę elegancji (gdyż od początku zdawałem sobie sprawę z ułomności mojego kodu ) zostawiłem na później.

Teraz zabieram się zgodnie z podpowiedziami do napisania kodu elegancko, wykorzystując timer programowy i tablicę z instrukcjami.

No tak, dałem plamę, wszystko mam przecież ładnie opisane w Green Booku, rozdział UART- zdarzenia, parsowanie danych.

Z czego zresztą już nieraz korzystałem w innych prostszych sytuacjach.
A teraz w tej trochę bardziej zawiłej ratuje mi życie przed zapętleniem w "szponach if if if".

Żeby już zakończyć dyskusję z samym sobą dodam, że u mnie jest akurat odwrotna sytuacja niż opisywana w w/w rozdziale.

Tam z PC wysyłamy jakieś komendy AT do uC.
U mnie uC wysyła komendy do urządzenia i trzeba parsować odpowiedzi.

Więc tabela z komendami jest niepotrzebna (wydaje mi się), co najwyżej potrzebuję tabeli z odpowiedziami.

Dziękuję za zainteresowanie, mam nadzieję, że uwagi Mirka w powyższym temacie komuś się przydały. Bo mnie jak najbardziej.

Dokładnie jak mówisz, w książce jest odwrotna komunikacja niż z urządzeniem typu modem jeśli to zauważyłeś to fajnie bo to znaczy, że dobre analizujesz rozdział

Jak wspominałem obsługa "W DRUGĄ" stronę jest co nieco trudniejsza ale nie niemożliwa

Ja właśnie robię komunikację z modemem GSM do Yellowbooka i używam dokładnie tych samych mechanizmów dlatego byłem w stanie ci coś na szybko podpowiedzieć i zasugerować .... Jaką można iść drogą


Tablica z komendami AT - nie potrzebna ? ... no ciekawe - ja tam bez niej nie mogę się obejść a dodatkowo można ją tak zorganizować, żeby ta sama tablica służyła w wielu przypadkach komend zarówno jako odpowiedzi jak i same komendy jak ?

proszę bardzo

"+CMGF"
"+CNMI"
"+CREG"
"+CPAS"
"E1"
"E2"
"I1"

to tablica i komend i odpowiedzi jakie od nich dostajemy w JEDNYM

nie sądzisz ? Jeśli chcemy wykorzystać jako tablicę komend AT, wystarczy sobie wysłać przed stringiem z tablicy sekwencję "AT"

A jeśli odsyłają dane np:

+CREG: 1,1

to już mam do parsowania wzór w tablicy

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dziękuję za cenne uwagi.

Aczkolwiek na razie odbieram tylko SMS-y, więc zrobiłem na razie trochę na skróty.
Chociaż przerobiłem też wysyłanie SMS, odbieranie dzwonienia i dzwonienie i za chwilę okaże się, że trzeba będzie pisać bardziej uniwersalnie.

Dla ciekawskich w main mam tak:

Z kolei w funkcji parsującej:


P.S. Czekam niecierpliwie na YB

Mam nadzieję, że w związku z powyższym mocno się przyda "w razie czego" Yelloboook" nad którym obecnie pracuję a to właśnie będzie jeden z wiodących tematów książki

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]