W dniu 2013-01-01 13:59, Anerys pisze:

> Nasunął mi się taki pomysł - nie porównywać całości, ale po pojedynczym
> znaku.

Przyszło mi do głowy jeszcze jedno rozwiązanie. Poszczególne
przychodzące znaki można by analizować bezpośrednio po odebraniu, w
przerwaniu RX USART-a. Każdy zgodny znak przesuwa wskaźnik do przodu,
mylny zeruje go. Po dotarciu do końca badanego ciągu ostatnia instrukcja
warunkowa, która sprawdza czy słuchawka jest podniesiona. Jeśli tak -
wysyła "ATH\r", jeśli nie - uruchamia dzwonek.
Oczywiście każdy znak przeanalizowany w przerwaniu byłby nadal dostępny
dla procedury odczytującej bufor (nie przesuwałbym wskaźnika odczytu).

Jedną z największych zalet byłaby możliwość uśpienia uC, ponieważ ten
nie musiałby ciągle sprawdzać w głównej pętli programu, czy ktoś nie
dzwoni. Widełki również można by spiąć z linią obsługującą przerwanie
sprzętowe. Mam jednak kilka wątpliwości...

1) Czy dopuszczalne jest wysyłanie jakichkolwiek znaków przez USART w
przerwaniu obsługującym obiór znaków? Szczególnie jestem ciekaw jaki
byłby efekt, gdyby było włączone echo...
2) Chyba musiałbym zastosować linię DTR, aby powstrzymać modem od
wysyłania kolejnych znaków np. podczas tej całej operacji?

To dobry kierunek, czy raczej gra niewarta świeczki?

do góry

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?

do góry

On Tue, 01 Jan 2013 18:16:16 +0100, Atlantis <m...@w...pl>
wrote:
> 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?

Ath nie rozlaczysz połączenia przychodzącego, jeszcze nie odebranego.
Tym drugim - owszem.

--
Marek

do góry

W dniu 2013-01-01 20:37, Marek pisze:

> Ath nie rozlaczysz połączenia przychodzącego, jeszcze nie odebranego.
> Tym drugim - owszem.

A to dziwne, bo obecnie w programie używam właśnie "ATH" we wszystkich
sytuacjach, kiedy trzeba zakończyć połączenie. Działa równie dobrze w
przypadku połączeń odebranych, jak i tych, które trzeba odrzucić...

do góry

Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kbv5l4$4tj$1@portraits.wsisiz.edu.pl...
> Gdy dojdzie do końca badanego ciągu (wykrycie komunikatu "RING"), wyślę
> "ATH".

Coś mi mówi, że powinieneś dociągnąć do znaków CR-LF, jakoś nie bardzo mogę
sobie wyobrazić znaków dawanych pod wlos... Ale zastanawiam się, czy nie
przeszło by - po stwierdzeniu, że "RING", zakombinowaniem ze stanem linii
kontrolnych... Ale jak pisałem, nie znam modemów GSMowych, jednak jeśli
szybciej było by zrzucić połaczenie zamiast ATH, to ustawieniem/skasowaniem
którejś z linii kontrolnych, to nie lepiej?

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

On Tue, 01 Jan 2013 20:40:00 +0100, Atlantis <m...@w...pl>
wrote:
> A to dziwne, bo obecnie w programie używam właśnie "ATH" we
wszystkich
> sytuacjach, kiedy trzeba zakończyć połączenie. Działa równie dobrze
w
> przypadku połączeń odebranych, jak i tych, które trzeba odrzucić...

A to widać moduł modułowi nie równy :-), ja musiałem at+chup bo ath
nie działało dla nieodebranych.

--
Marek

do góry

W dniu 2013-01-01 20:46, Anerys pisze:

> Coś mi mówi, że powinieneś dociągnąć do znaków CR-LF, jakoś nie bardzo
> mogę sobie wyobrazić znaków dawanych pod wlos...

Oczywiście znaki kontrolne też uwzględniam, tutaj pominąłem dla
uproszczenia. Zresztą problem z pominięciem tych znaków miałem tylko
wtedy, gdy zaraz po odczytaniu komunikatu trzeba było wysłać jakieś
polecenie - wówczas moduł otrzymywał nowe znaki, gdy poprzedni komunikat
jeszcze był wysyłany. Prowadziło to do powstania błędu (przychodził
"krzaczek").

Gdy jedynie trzeba sprawdzić, czy dany ciąg wystąpił (i nic nie jest
zaraz potem wysyłane) ten problem nie występuje. Funkcja zwróci wartość
prawdziwą, gdy wystąpi ostatni znak poszukiwanego ciągu. Znaki kontrolne
zostaną po prostu zapisane do bufora. Przy następnym wywołaniu funkcji
sprawdzającej zostaną pominięte (a właściwie będą resetowały
sprawdzanie, dopóki nie pojawi się pasujący znak, albo nie upłynie
zadany czas).


> jednak jeśli szybciej było by zrzucić połaczenie zamiast ATH, to
> ustawieniem/skasowaniem którejś z linii kontrolnych, to nie lepiej?

Aż takie niuanse nie są wyprowadzone na osobne linie niestety. Jest
komplet linii rs232, do karty SIM, włączenia zasilania itp.

do góry

Atlantis <m...@w...pl> wrote:

> Zbadanie zawartości bufora zajmuje na tyle dużo czasu, że jeśli taka
> konieczność zajdzie w momencie kręcenia tarczą, program może przeoczyć
> część impulsów,

W jaki sposób rozpoznajesz impuls z tarczy?

--
Gof
http://www.chmurka.net/

do góry

W dniu 2013-01-02 08:40, Adam Wysocki pisze:

> W jaki sposób rozpoznajesz impuls z tarczy?

Chyba w najprostszy z możliwych sposobów. Starszą wersję kodu znajdziesz
tutaj:

http://www.elektroda.pl/rtvforum/topic2440230.html

Od tamtego czasu nauczyłem się paru rzeczy, rozwiązałem kilka problemów
i poprawiłem parę błędów. Sama procedura wybierania numeru (make_call)
nie zmieniła się jednak prawie wcale, a część odpowiedzialna za
odczytywanie tarczy jest praktycznie taka sama.

do góry

Atlantis <m...@w...pl> wrote:

>> W jaki sposób rozpoznajesz impuls z tarczy?
>
> Chyba w najprostszy z możliwych sposobów. Starszą wersję kodu znajdziesz
> tutaj:

Chodzi mi o to, w którym miejscu. Mam wrażenie, że nie robisz tego
w przerwaniu, tylko w głównej pętli, między innymi funkcjami, które
mogą być blokujące...

--
Gof
http://www.chmurka.net/

do góry