Witam ponownie, może tym razem ktoś pomoże? Już na czacie większy ruch...
Chodzi o to że dalej morduję komunikację z modemem i wreszcie ruszyłem o dwa kroki do przodu po czym musiałem się cofnąć o półtora kroku w efekcie jestem pół kroku dalej ale nie w tym rzecz. Po kilkudniowej walce z rozumem doszedłem do wniosku że parsowanie danych będzie mi działało jeśli odbiorę stringa w jednej linii. Funkcja odbierająca Mirka z zielonej książki odbiera ale dzieli stringa na sztuki po każdym wykryciu znaku <CR> przez co zamiast jednej odpowiedzi modemu dostaję 2/3/4 zależnie o co pytam. Doszedłem więc do wniosku że pasuje zliczyć ile leci enterów <CR> i po ostatnim ustawić tylko zmienną ascii_line na 1. Eureka! udało się, działa... ale no właśnie jest pewne ale. Chodzi o to że "nie wiem" ile ma przylecieć tych <CR> wiec narazie mam na sztywno 4. Jednak nie dla wszystkich komend to pracuje poprawnie. Jak zatem zrobić tę funkcję bardziej uniwersalną? Aha jeszcze pytanie co sie stanie jak przyjdzie np. sms dłuuuuugi? Nie zapaskudzi przypadkiem bufora odbiorczego? Bufor mam na 100 znaków.
Poniżej kod który naskrobałem, dziękuje za wszelkie sugestie i pozdrawiam Dexter.

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

Kod w tej chwili wygląda tak że w powyższym przerwaniu odbieram stringa co powoduje wywołanie eventu odbiorczego i zarazem funkcji parsującej dane. String jest w niej dzielony na tokeny w zależności od tego co przyszło podejmowana jest jakaś akcja. Działa to różnie bo nie wiem jak zrobić sensownie odbiór uzależniony od tego co wysyłam. Chodzi o to że jak wyślę samą komendę AT to mam czekać na OK, jak wyślę AT+CSQ to mam oczekiwać +CSQ: 20,99 OK. Próbowałem ustawiać flagę co wysyłam do telefonu żeby po niej sprawdzić co ma zostać odebrane ale to nie działa bo jak w międzyczasie przyleci inna odpowiedź np. przychodzące połączenie) to cały program sie sypie bo nie oczekiwał tego co przyszło.
Próbowałem też zrobić czekanie na daną komendę za pomocą timeout'u ale to też nie wyszło. Działało to na tej zasadzie że wysyłam komendę po czym czekam określony czas na odpowiedź i jeśli przyszła właściwa to zwracam OK jeśli nie to error i ponawiam wysyłanie. Tyle że to też sie sypało bo jak w czasie czekania zadzwoniłem na telefon to procek odebrał inną komendę niż oczekiwane OK i wywalał error. A do tego nie reagował na połączenie bo się go nie spodziewał.

Potrzebuję zarys sposobu komunikacji, czyli jak zaplanować przesyłanie danych żeby uwzględnić błędy transmisji albo jakieś zdarzenia nieoczekiwane bez konieczności blokowania całego programu.

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka