W dniu 2012-12-15 20:04, Marek pisze:

> Pisząc rs232 nasz na myśli usart mcu? Używasz jakieś przejściówki
> usart<->rs232 czy usart<->usb w przypadku łączenia się z pc?

Tak, miałem na myśli właśnie usart Atmegi.
Łącząc się z pecetem używam modułu na max3232.
Przelotkę na USB będę musiał kupić, ale do takich "warsztatowych"
zastosowań używam leciwego ThinkPada T23, który posiada port COM.


> ja jestem zwolennikiem buforu odbiorczego typu ring, które wypełnia
> przerwanie po odbiorze znaku + funkcje odczytu zawartosci bufora.
> Algorytm to m.in. dwie funkcje (w psedokodzie):
> wyslij("at&f\r\n");
> czekajna("OK\r\n", 1000);

Hmm... Zainteresuję się tematem. Na razie zrobiłem to "po swojemu". Jest
to może rozwiązanie proste, nawet i nieco toporne, ale w pewnym sensie
to jego zaleta.

W każdym razie najważniejsze - miałeś rację co do przyczyny. Zmieniłem
procedurę odbierającą znaki. W sposób opisany w poprzedniej wiadomości i
teraz transmisja przebiega prawidłowo. W komunikatach wysyłanych przez
moduł nie ma żadnych "krzaczków". Wracają czyste komunikaty.

Jednak teraz w oczy rzuciła mi się jeszcze jedna kwestia, której nie
dostrzegłem wcześniej. Mianowicie komunikaty są odbierane liniami. Puste
są ignorowane, ale przyjście każdej następnej pełnej zastępuje
poprzednią zawartość last_line[].
Sęk w tym, że np. na zapytanie "AT+CPIN?" moduł odpowiada w następujący
sposób:

+CPIN: SIM PIN\r\n
\r\n\
OK\r\n

Efekt jest oczywisty - oczekiwana, pierwsza linia zostaje niemal
momentalnie zastąpiona przez trzecią (druga zostaje zignorowana).
Można by to wyłączyć (np. jakąś komendą AT) czy jedynie w grę wchodzi
zmiana algorytmu odbierania komunikatów?