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

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

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.

do góry

Użytkownik "Adam Wysocki" <g...@s...invalid> napisał w wiadomości
news:gof.pme.1357112441@news.chmurka.net...
> 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?

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.

do góry

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

> Ja bym sprawdzał stan 0/1, potem ewentualnie przeliczył jego zmiany.

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


> 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

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.

do góry

Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kc4ks5$cmo$1@portraits.wsisiz.edu.pl...
>> Ja bym sprawdzał stan 0/1, potem ewentualnie przeliczył jego zmiany.
>
> W gruncie rzeczy przecież tak to się właśnie odbywa. Tarcza ma dwie pary

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

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

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

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

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

do góry

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

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

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

do góry