zajętości linii GSM

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.

Reply to
Atlantis
Loading thread data ...

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.
Reply to
Anerys

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.

Reply to
Atlantis

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kc4ks5$cmo$ snipped-for-privacy@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ć :)

Reply to
Anerys

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

Reply to
Atlantis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.