W dniu 2013-01-01 16:44, J.F. pisze:

> A moze sie nie przejmowac ? Sytuacja na tyle rzadka, ze mozna odebrac.

Zależy mi jednak na stabilnym i przewidywalnym działaniu programu...


> Do sprawdzenia - a co bedzie jesli w takim stanie wyslesz normalna
> komende ATDnnn; ? Nie uda sie zadzwonic bo "linia zajeta" czy wlasnie
> polaczy, a nie odbierze ?

Nie uda się zadzwonić, zwraca "NO CARRIER".


> No nie przesadzajmy - sprawdzenie bufora to pare, moze parenascie rozkazow.

Problem polegał na tym, że nieopatrznie skorzystałem z gotowej,
standardowej procedury oczekiwania na pojawienie się danego komunikatu w
buforze. Działa ona w ten sposób, że przez zadany okres czasu czeka na
pojawienie się oczekiwanego ciągu. Jeśli ciąg się pojawi - zwraca
wartość prawdziwą. Jeśli czas upłynie - zwraca fałsz. Niestety przez ten
czas procek jest zajęty.

Teraz wypróbuję inne podejście. W każdej iteracji głównej pętli
procedury wybierania numeru będę sprawdzał jeden znak. Jeśli będzie się
zgadzał - wskaźnik++. Jeśli nie - wskażnik = 0 (sprawdzanie od nowa).
Gdy dojdzie do końca badanego ciągu (wykrycie komunikatu "RING"), wyślę
"ATH".


> I wcale nie wiadomo czy chcesz sprawdzac w czasie krecenia - rozsadne
> byloby wlaczyc dzwonek, i niech uzytkownik decyduje - naciska widelki,
> podnosi i odbiera, czy kreci dalej - a pod koniec sprawdzasz czy nic nie
> czeka.

Odpada. Program ma dokładnie naśladować zachowanie starego telefonu, bo
(że tak powiem) będzie działał w starym telefonie. ;) Chodzi o
zabudowanie urządzenia GSM w obudowie starego, bakelitowego telefonu
RWT, z mikrosterownikiem pośredniczącym w komunikacji z widełkami,
tarczą numerową i elektromechanicznym dzwonkiem. ;)


> A w ogole jest jakies polecenie do odrzucenia ? ATH nie wiem czy zadziala.

"ATH" działa.
Tak BTW jaka jest różnica między "ATH" a "AT+CHUP"? Dokumentacja modułu
podaje lakoniczne wyjaśnienie jego działania jako "hangs up call". Jak
dla mnie dokładnie to samo robi "ATH"... Dwa redundantne polecenia?