W dniu 2015-01-28 o 16:23, Marek pisze:

> Oj to dużo pisania, trochę nie na temat grupy. Ale tak ogólnie to są
> dwie ważne sprawy, pierwsza to prawidłowa obsługa bufora cyklicznego
> fifo, do którego pisze przerwanie uarta po odebraniu znaku. Bardzo
> fajnie jest to opisane w tym dokumencie (od strony 36)

Z buforami cyklicznymi akurat jakoś sobie radzę - stosuję je standardowo
w swoich projektach, zarówno po stronie odbiorczej, jak i nadawczej.


> (nota bene dokument opisuje fajną minimalistyczną implementację
> ppp/tcp/udp na 8 bit mcu, sprawdzone, działa). Drugi bufor, to podręczny
> bufor api (aplikacyjny), do którego są "wyciągane" z fifo kolejne znaki
> i na podstawie jego zawartości api przełącza się w odpowiednie stany,
> obsługujące dane zdarzenie. Druga sprawa to opisanie wszystkich
> możliwych stanów maszyny.

Hmm... Czyli krótko mówią mogę zrobić to np. za pomocą tablicy, w której
będę trzymał typ strukturalny złożony z łańcucha tekstowego (wszystkie
możliwe komendy zmieniające stan) oraz jakiejś zmiennej (np. enum)
określającej ten stan.
Potem w pętli głównej cyklicznie pobieram kolejny znak z bufora
cyklicznego i na bieżąco sprawdzam (strncasecmp_P) czy zawartość bufora
pokrywa się z którymś z tekstów umieszczonych w tabeli. Jeśli tak -
ustawiam przypisany mu stan.
Oczywiście to, co odbywa się w danym momencie w pętli głównej musiałoby
zależeć od obecnego stanu - inaczej program zachowywałby się podczas
oczekiwania na komendę, inaczej podczas odbierania znaków składających
się na SMS-a albo nadchodzące dane TCP.