On Wed, 28 Jan 2015 12:26:50 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Możesz napisać coś więcej?

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)

http://cache.freescale.com/files/microcontrollers/do
c/app_note/AN2120.pdf

(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. Najważniejszym stanem
jest SM_IDLE, w której się oczekuje na "unsolicited codes". Kolejnym
stanem może być np. SM_RECEIVE_SMS, w który się przełączamy ze stanu
SM_IDLE po odebraniu np. +CMTI i powrót z powrotem do SM_IDLE, gdy
zakończyliśmy procesowanie odebranego smsa. Zaletą takiego modelu
jest to, że każdy stan jest nieblokujący mcu: gdy nie ma żadnego
znaku do pobrania z fifo to nie ma nic do roboty i można wrócić do
"main_loop". Gdy jest znak to go wyciągamy z fifo i sprawdzamy czy po
"dołożeniu" go do lokalnego bufora mamy już kompletną odpowiedź
modemu, jeśli nie znowu wracamy do "main_loop". Natomiast gdy mam już
kompletną odpowiedź to ją identyfikujemy i przełączamy się na
odpowiedni stan aby ją przeprocesować. Gdy api jest dłużej w jakimś
stanie procesującym (nie sprawdza czy coś jest "nowego" w fifo),
nieoczekiwane dane z modemu nie zginą bo są buforowane przez
przerwanie piszące do fifo. Te dane zostaną odebrane z fifo po
powrocie do stanu SM_IDLE.

"Unsolicited codes" nie pojawiają się np. w połowie odpowiedzi na
jakieś polecenie AT, stąd nie ma zagrożenia, że popsują kontekst tej
odpowiedzi (innego polecenia). Na uarcie musi być chwilowa cisza
między komendami AT aby modem zwrócił taki kod. Sposób wysyłania tych
kodów konfiguruje się poprzez AT+CNMI, najbezpieczniejsze jest
AT+CNMI=3,1,0,0,0 bo to własnie włącza buforowanie sygnalizacji
zdarzenia (gdy wystąpi w trakcie odpowiedzi na inne polecenie lub gdy
modem jest w trybie data a nie command). W takim przypadku kod
zostanie przesłany po zakończeniu transmisji poprzedniej odpowiedzi
(pod warunkiem chwilowej "ciszy", o której wspomniałem wyżej).

To tak bardzo ogólnie. Oczywiście każdy stan może mieć swój "lokalny"
idle, w których czeka np. na OK\r\n po jakimś poleceniu. Jak się
podgląda taka komunikację "nodelay" na uarcie to bardzo ładnie ona
wygląda, jest szybka i płynna.

--
Marek