W dniu 2015-01-28 o 10:33, Marek pisze:

> A chyba już wiem, wysyłają polecenie AT, delay oczekując na odpowiedź,
> po czym sprawdzają bufor odbiorczy uarta... ależ to jest bardzo
> nieefektywne, zamiast delay procek mógłby robić w tym czasie coś innego.

No właśnie wiem. ;)
Dlatego gdybym ja się za to zabierał, to wszystko robiłbym na flagach i
zdarzeniach. Na przykład wysyłając dane ustawiamy odpowiednią flagę i
podajemy funkcji w pętli głównej wskaźnik do bufora. Dopóki flaga jest
ustawiona, nie możemy rozpocząć kolejnego wysyłania, a czyści się ją po
odebraniu "SEND OK".
Podobnie można postąpić z "ready" i innymi sygnałami kontrolnymi.
Sprawdzane byłoby też pojawienie się ">\r\n".
Oczywiście wszystkie odpowiedzi byłyby odbierane i parsowane "w tle",
przez funkcję w pętli głównej.

Nieco problematyczny jest tylko odbiór danych, które mogą się pojawić w
dowolnym momencie jako "+IDP,<soc>,<len>:<data>\r\n".
Sęk w tym, że ciąg danych może składać się z większej ilości linii, więc
odebranie "\r\n" nie musi oznaczać końca odbioru danych. Trzeba by dać
instrukcję warunkową, która sprawdza czy linijka po ":" zawiera mniej
znaków niż "len" - jeśli tak, trzeba by uruchomić specjalny tryb odbioru
danych, w którym kolejne napływające znaki nie są parsowane jako
komendy, ale doklejane do końca bufora, aż do pobrania zadanej ilości.