Jak ustawić moduł GSM, aby odrzucał połączenia przychodzące z sygnałem zajętości?

Tue Jan 01, 2013 8:52 pm   

On Tue, 01 Jan 2013 20:40:00 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

--
Marek

Tue Jan 01, 2013 9:12 pm   

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


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).



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

Wed Jan 02, 2013 9:40 am   

Atlantis <marekw1986NOSPAM@wp.pl> wrote:


W jaki sposób rozpoznajesz impuls z tarczy?

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

Wed Jan 02, 2013 7:11 pm   

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


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.

Wed Jan 02, 2013 9:10 pm   

W dniu 2013-01-02 20:52, Adam Wysocki pisze:


Nie tyle w głównej pętli, co w pętli umieszczonej w procedurze
wywoływanej po podniesieniu słuchawki i stwierdzeniu, że nie ma
połączenia przychodzącego. Nie widzę konieczności korzystania z przerwań
przy obsłudze odczytu stanu tarczy.
Wypadałoby je jednak zaprząc do pracy przy sprawdzaniu stanu dzwonka i
widełek. Teraz ciągle sprawdzam je w pętli głównej. Po przejściu na
zasilanie bateryjne powinienem to jednak zrobić trochę inaczej...

A co do głównego tematu, to faktycznie tamta funkcja działała blokująco,
na co już wcześniej zwrócono mi uwagę. Po prostu w pośpiechu
skorzystałem z gotowej procedury oczekującej na pojawienie się
określonego ciągu znaków w buforze. Jej wywołanie zajmowało na chwilę
procesor. Teraz analizuję po jednym znaku w każdej iteracji pętli
sprawdzającej tarczę, co nie powoduje praktycznie żadnego znaczącego
obciążenia.

Wed Jan 02, 2013 9:52 pm   

Atlantis <marekw1986NOSPAM@wp.pl> wrote:


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/

Thu Jan 03, 2013 1:13 am   

Użytkownik "Adam Wysocki" <gof@somewhere.invalid> napisał w wiadomości
news:gof.pme.1357112441@news.chmurka.net...

Ja bym sprawdzał stan 0/1, potem ewentualnie przeliczył jego zmiany. Choć
nie wiem, czy tu nie lepiej zrobić na 7490 z jakimiś małymi przyległościami,
7490 wystawi wartość, a przyległości np. wystawią sygnał przerwania, które
da się obsłużyć. Może trochę naokoło, ale IMHO powinno przynajmniej
częściowo uniezależnić, przecież już za elektromechanicznych łacznic
telefonicznych, rozdzielono sterowanie od komutacji, w urządzeniach o
inteligencji choć ciut większej, niż Strowger... Dzięki czemu na moduł 1024
numery (24 pozakatalogowe - PC) wystarczą dwa cechowniki, no i sama
komutacja jest wydajniejsza.

--
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.

Thu Jan 03, 2013 8:06 pm   

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


W gruncie rzeczy przecież tak to się właśnie odbywa. Tarcza ma dwie pary
styków (w stanie spoczynku złączonych), które łączą dwie linie uC z
masą. Gdy tarcza zostanie zakręcona, jedna z nich się rozwiera i
pozostaje rozwarta do momentu powrotu. Druga para styków rozwiera się
przy każdym impulsie.

Tak więc cała procedura jest banalna:
W pętli sprawdzam, czy na linii połączonej z pierwszą parą pojawił się
stan wysoki. Jeśli tak - przeczekuję drgania styków, wykonuję kilka
innych operacji, a potem inicjuję kolejną pętlę, która ma trwać dopóki
trwa stan wysoki na tej linii. Wewnątrz tej drugiej pętli sprawdzam stan
drugiej linii - gdy pojawi się stan wysoki przeczekuję drgania,
zwiększam zmienną o jeden, a potem w pustej pętli czekam do końca impulsu.

Procesor i tak nic innego (poza ewentualnym odbieraniem znaków w
przerwaniu USARTA) wtedy nie musi robić.



Nie widzę powodu, żeby rozbudowywać część sprzętową i korzystać z
przerwań, skoro obsługa tarczy numerowej sprawdza się do prostego,
sekwencyjnego wykonywania pewnych czynności, jedna po drugiej.

Problem, na który się natknąłem wynikał z głupiego błędu w programie -
zastosowałem o jedną pętlę za dużo niż powinienem. A właściwie użyłem
przygotowanej wcześniej funkcji, w której ta pętla występowała.

Thu Jan 03, 2013 9:16 pm   

Użytkownik "Atlantis" <marekw1986NOSPAM@wp.pl> napisał w wiadomości
news:kc4ks5$cmo$1@portraits.wsisiz.edu.pl...

Chodzi mi o optymalizację procesu. Załóżmy, mam program, liczący ile komórek
pamięci zawiera daną wartość.
1:
DIM a(255)
FOR t = 0 TO 65535
IF PEEK (t) = 0 THEN a(0) = a(0) + 1
....
IF PEEK (t) = 255 THEN a(255) = a(255) + 1
NEXT t
(wyprowadzenie listy wyników)

2:
DIM a(255)
FOR t=0 TO 65535: p=PEEK(t)
a(p) = a(p)+1
NEXT t
(wyprowadzenie listy wyników)

program drugi wykona się wielokrotnie szybciej, nie ma badania warunku...


Jeden scalaczek liczący i dwa uniwibratory, uprościły by konstrukcję.


....ale tu już nie zapyskuję, nie rozkminialem tego aż tak bardzo programowo.
Sam jestem ciekaw zabawy nad czysto programową obsługą całości, jak się uda
sfinalizować :)

--
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.

Thu Jan 03, 2013 10:29 pm   

W dniu 2013-01-03 21:16, Anerys pisze:


No cóż... Pomysły interesujące, jednak moje doświadczenie jest zbyt
małe, żeby bawić się w coś takiego. Lata temu, w czasach liceum,
pisywałem jakieś programiki w Pascalu (sam się dziwię dlaczego wtedy tak
unikałem C...). Mikrosterownikami nie bawiłem się wcale. To pierwszy
poważniejszy projekt (to znaczy taki, który będzie robił coś
konkretnego, a nie tylko w celach edukacyjnych mrugał diodami albo
wysyłał znaki do wyświetlacza).

Idę więc po mniejszej linii oporu, korzystając z rozwiązań najprostszych
do zaprogramowania. W tym przypadku zresztą mikrosteronik taktowany 8MHz
kwarcem powinien przecież dysponować odpowiednio dużym zapasem mocy
obliczeniowej.

A co do czysto programowej obsługi całości, to ta strona projektu jest
już praktycznie gotowa. Za pomocą tarczy można prawidłowo wybierać
numery, program odpowiednio reaguje na podniesienie słuchawki, informuje
o połączeniach przychodzących. Pozostało jeszcze kilka drobiazgów do
zrobienia - generowanie dialtone'u chociażby, albo regulacja głośności w
słuchawce.

Reszta to kwestie typowo sprzętowe. Zarówno mniej jak i bardziej
kłopotliwe. Najpierw podłączenie mikrofonu i słuchawki (nota modułu
zaleca dodanie wzmacniaczy). Potem dzwonek (w grę wchodzi przewinięcie
albo zastosowanie jakiejś przetwornicy) no i układ ładowania
akumulatorka. Będę musiał po prostu w chwili wolnego czasu usiąść i
zrobić kilka prób na płytce stykowej.