Re: :-)))



Masz problem? Zapytaj na forum elektroda.pl z bramką pl.misc.elektronika!

Poprzedni Następny
Wiadomoœć
spis treści
From: "Jerzy Szczesiul" <Jerzy.Szczesiul_at_nospam_ep.com.pl>
Subject: Re: :-)))
Date: Sun, 18 Apr 1999 19:31:42 +0300


Czesc

Michał napisał(a) w wiadomości: ...

Wielkie dzieki za tak duzy odzew.
I mam pytanko dotyczace wykorzystania portu
jako wejscie np. klawisz.
Zalozmy ze program wykonuje jakies czynnosci w zaleznosci
od stanu portu (wejscia) z kilkoma klawiszami.
Jak rozpoznawac ten stan?
Przez rozkaz skoku warunkowego tzn zeby program "przemiatal" wszystkie
linie wejsc, czy lepiej zeby wcisniecie dowolnego klawisza
generowalo przerwanie i w obsludze tego przerwania sprawdzac
stan wejsc? Wtedy trzeba by zrobic sprzetowo bramke AND na liniach wejsc
i jej wyjscie podlaczyc do INT0 lub INT1.

Pozdrawiam
MIC
sumator_at_nospam_friko5.onet.pl


---------------------------
Metod jest mnostwo - w zaleznosci od ilosci klawiszy, wolnych
linii portow itd. Natomiast zawsze istotny jest problem drgan
zestykow mechanicznych powodujacy przez kilkadziesiat ms
cykliczne zalaczanie/rozlaczanie. Z tego wzgledu raczej
niewskazane jest odczytanie stanu zestykow bezposrednio
w obsludze przerwania - prawdopodobne jest, ze trafimy akurat
na moment odbicia styku. Przy tym bedzie to mialo charakter losowy
co znacznie utrudni lokalizacje buga. Mozna te drgania wygasic
sprzetowo ( tak jak sie to robilo np. przy licznikach cyfrowych) ale
zazwyczaj wprowadzamy programowe opoznienie odczytu.
Schematycznie wyglada to tak :
1. stwierdzenie zmiany stanu klawiatury
2. programowe opoznienie odczytu
3. wykonanie akcji zwiazanej z klawiszem

Ad1. Mozna cyklicznym sprawdzaniem a mozna - jak piszesz
powolny proces : fizyczne przycisniecie klawisza to w najlepszym
razie kilkaset ms - dla procesora to cala epoka nawet przy jakichs
dlugich procedurach przeliczeniowych. Poza tym powstaja problemy
dodatkowe :
- wspomniane drgania wygeneruja jedno po drugim znaczna liczbe
przerwan / mozna to zablokowac ale to dodatkowa robota,
- proponowany uklad AND nie zglosi przerwania po puszczeniu
klawisza ani po wcisnieciu drugiego itd.
W sumie wydaje sie, ze przerwanie pozostanie niezle dla
wspolpracy z oddzielnym kontrolerem klawiatury ktory zajmie sie
szczegolami i zglosi obecnosc kodu klawisza do odczytania,
natomiast dla wlasnych kilku klawiszy wygodniejszy bedzie polling.

Ad 2. Filtr klawisza mozna zrealizowac na przyklad jako licznik
programowy dekrementowany do zera przy klawiszu zwolnionym
i inkrementowany do potrzebnej wartosci przy wcisnietym.
Osiagniecie zera oznacza zwolnienie klawisza ( mozesz np.
ustawic wtedy flage KeyUp ) natomiast osiagniecie gornej
wartosci - nacisniecie ( flaga KeyDown ). Jak widac taki filtr
dziala w obie strony. Gorna wartosc licznika bedzie zalezec od
czestotliwosci sprawdzania - mozna to wykonywac w glownej
petli programu jednak wtedy trudno przewidziec rzeczywiste
ostateczne opoznienia. Proponuje testowanie przyciskow
realizowac w obsludze przerwania T0 - np. przy przerwaniu 10 ms
wartosc filtru 15 da czas filtracji 150 ms ( na ogol i tak uzywamy
przerwania T0 dla realizacji timerow systemowych )
Przy wiekszej ilosci klawiszy moze byc szkoda zasobow na
wlasny filtr dla kazdego klawisza - mozna uzyc wspolnego
badajacego zmiane stanu klawiatury i ustawiajacego jakas
flage ( KeybChanged ) do poinformowania petli glownej.

Ad 3. Na ogol wykonujemy w petli glownej. Nalezy tylko zwrocic
uwage czy chcemy akcji jednorazowej, czy powtarzalnej ( zazwyczaj
beda potrzebne dodatkowe flagi ew. timery )
Np dla jednorazowej :
KLAWISZ1_DOWN:
JNB K1DOWN,END_K1DOWN
JB K1DOWN_DONE, END_K1DOWN ;juz wykonane

CLR K1UP_DONE ;przywrocenie funkcjonalnosci w przeciwna strone
.....
AKCJA
.....

SETB K1DOWN_DONE ;zrobione

END_K1DOWN:
RET

( w tym przykladzie nie kasuje bezposrednio flagi K1DOWN
w innych procedurach ).

Jeszcze na marginesie dwie ogolne sprawy.
a) proponuje program assemblerowy pisac jako szereg
procedur ( jak w powyzszym przykladzie ). Jest to do
dyskusji bo zabiera czas procesora ale jak dla mnie
znacznie ulatwia pisanie i uruchamianie - wtedy petla
glowna ma praktycznie forme :
LOOP:
CALL PROC1
CALL PROC2
...
JMP LOOP

a wszelkie zaleznosci warunkowe sa zamkniete w procedurach
( sa oparte na flagach ustawianych jako rezultat obslugi przerwan
lub dzialania innych procedur ).
Wydaje sie to sporo latwiejsze do opanowania niz rozbudowane
drzewo skokow warunkowych dla calego programu.
b) sprawa peryferiow ( wspomniales np. o ukladzie AND dla
przerwan ). Sa rozne szkoly. Jedna to maly procesor obstawiony
roznymi rejestrami przesuwnymi , dekoderami itd do obslugi
klawiatur ,wyswietlaczy etc. Druga - dedykowana jednoukladowka
przystosowana do danego zadania ( ilosc linii, A/C, PWM itd ).
Zalezy co robisz : w serii zadecyduje cena, w egzemplarzach
amatorskich czesto prostota wykonania plytki itp.

To tyle na razie

Powodzenia
Jurek Szczesiul
Jerzy.Szczesiul_at_nospam_ep.com.pl

PS. Na stronie EP jest kilka plikow 'kurs programowania 51'.




Poprzedni Następny
Wiadomoœć
spis treści
From: "Michał" <sumator_at_nospam_friko5.onet.pl>
Subject: Re: :-)))
Date: Mon, 19 Apr 1999 15:39:14 +0200



Jerzy Szczesiul napisał(a) w wiadomości: ...
Czesc

Michał napisał(a) w wiadomości: ...

Wielkie dzieki za tak duzy odzew.
I mam pytanko dotyczace wykorzystania portu
jako wejscie np. klawisz.
Zalozmy ze program wykonuje jakies czynnosci w zaleznosci
od stanu portu (wejscia) z kilkoma klawiszami.
Jak rozpoznawac ten stan?
Przez rozkaz skoku warunkowego tzn zeby program "przemiatal" wszystkie
linie wejsc, czy lepiej zeby wcisniecie dowolnego klawisza
generowalo przerwanie i w obsludze tego przerwania sprawdzac
stan wejsc? Wtedy trzeba by zrobic sprzetowo bramke AND na liniach wejsc
i jej wyjscie podlaczyc do INT0 lub INT1.

Pozdrawiam
MIC
sumator_at_nospam_friko5.onet.pl


---------------------------
Metod jest mnostwo - w zaleznosci od ilosci klawiszy, wolnych
linii portow itd. Natomiast zawsze istotny jest problem drgan
zestykow mechanicznych powodujacy przez kilkadziesiat ms
cykliczne zalaczanie/rozlaczanie. Z tego wzgledu raczej
niewskazane jest odczytanie stanu zestykow bezposrednio
w obsludze przerwania - prawdopodobne jest, ze trafimy akurat
na moment odbicia styku. Przy tym bedzie to mialo charakter losowy
co znacznie utrudni lokalizacje buga. Mozna te drgania wygasic
sprzetowo ( tak jak sie to robilo np. przy licznikach cyfrowych) ale
zazwyczaj wprowadzamy programowe opoznienie odczytu.
Schematycznie wyglada to tak :
1. stwierdzenie zmiany stanu klawiatury
2. programowe opoznienie odczytu
3. wykonanie akcji zwiazanej z klawiszem

Ad1. Mozna cyklicznym sprawdzaniem a mozna - jak piszesz
- przerwaniem. Osobiscie uwazam, ze szkoda przerwania na tak
powolny proces : fizyczne przycisniecie klawisza to w najlepszym
razie kilkaset ms - dla procesora to cala epoka nawet przy jakichs
dlugich procedurach przeliczeniowych. Poza tym powstaja problemy
dodatkowe :
- wspomniane drgania wygeneruja jedno po drugim znaczna liczbe
przerwan / mozna to zablokowac ale to dodatkowa robota,

No wlasnie. Co sie stanie jesli podczas trwania obslugi przerwania
zostanie zgloszone znowu to samo przerwanie?
Mozna wylaczyc zezwolenie na przerwanie zaraz na poczatku jego obslugi
i wlaczyc z powrotem pod koniec?

- proponowany uklad AND nie zglosi przerwania po puszczeniu
klawisza ani po wcisnieciu drugiego itd.
W sumie wydaje sie, ze przerwanie pozostanie niezle dla
wspolpracy z oddzielnym kontrolerem klawiatury ktory zajmie sie
szczegolami i zglosi obecnosc kodu klawisza do odczytania,
natomiast dla wlasnych kilku klawiszy wygodniejszy bedzie polling.

Ad 2. Filtr klawisza mozna zrealizowac na przyklad jako licznik
programowy dekrementowany do zera przy klawiszu zwolnionym
i inkrementowany do potrzebnej wartosci przy wcisnietym.
Osiagniecie zera oznacza zwolnienie klawisza ( mozesz np.
ustawic wtedy flage KeyUp ) natomiast osiagniecie gornej
wartosci - nacisniecie ( flaga KeyDown ). Jak widac taki filtr
dziala w obie strony. Gorna wartosc licznika bedzie zalezec od
czestotliwosci sprawdzania - mozna to wykonywac w glownej
petli programu jednak wtedy trudno przewidziec rzeczywiste
ostateczne opoznienia. Proponuje testowanie przyciskow
realizowac w obsludze przerwania T0 - np. przy przerwaniu 10 ms
wartosc filtru 15 da czas filtracji 150 ms ( na ogol i tak uzywamy
przerwania T0 dla realizacji timerow systemowych )
Przy wiekszej ilosci klawiszy moze byc szkoda zasobow na
wlasny filtr dla kazdego klawisza - mozna uzyc wspolnego
badajacego zmiane stanu klawiatury i ustawiajacego jakas
flage ( KeybChanged ) do poinformowania petli glownej.

Ad 3. Na ogol wykonujemy w petli glownej. Nalezy tylko zwrocic
uwage czy chcemy akcji jednorazowej, czy powtarzalnej ( zazwyczaj
beda potrzebne dodatkowe flagi ew. timery )
Np dla jednorazowej :
KLAWISZ1_DOWN:
JNB K1DOWN,END_K1DOWN
JB K1DOWN_DONE, END_K1DOWN ;juz wykonane

CLR K1UP_DONE ;przywrocenie funkcjonalnosci w przeciwna strone
.....
AKCJA
.....

SETB K1DOWN_DONE ;zrobione

END_K1DOWN:
RET

( w tym przykladzie nie kasuje bezposrednio flagi K1DOWN
- pozostaje ona jako status klawisza do ew. wykorzystania
w innych procedurach ).

Jeszcze na marginesie dwie ogolne sprawy.
a) proponuje program assemblerowy pisac jako szereg
procedur ( jak w powyzszym przykladzie ). Jest to do
dyskusji bo zabiera czas procesora ale jak dla mnie
znacznie ulatwia pisanie i uruchamianie - wtedy petla
glowna ma praktycznie forme :
LOOP:
CALL PROC1
CALL PROC2
...
JMP LOOP

a wszelkie zaleznosci warunkowe sa zamkniete w procedurach
( sa oparte na flagach ustawianych jako rezultat obslugi przerwan
lub dzialania innych procedur ).
Wydaje sie to sporo latwiejsze do opanowania niz rozbudowane
drzewo skokow warunkowych dla calego programu.
b) sprawa peryferiow ( wspomniales np. o ukladzie AND dla
przerwan ). Sa rozne szkoly. Jedna to maly procesor obstawiony
roznymi rejestrami przesuwnymi , dekoderami itd do obslugi
klawiatur ,wyswietlaczy etc. Druga - dedykowana jednoukladowka
przystosowana do danego zadania ( ilosc linii, A/C, PWM itd ).
Zalezy co robisz : w serii zadecyduje cena, w egzemplarzach
amatorskich czesto prostota wykonania plytki itp.

To tyle na razie

Powodzenia
Jurek Szczesiul
Jerzy.Szczesiul_at_nospam_ep.com.pl

PS. Na stronie EP jest kilka plikow 'kurs programowania 51'.



Co do drgan zestykow, to w DSM51 proponuja po wykryciu
zmiany stanu klawisza odczekanie np 10ms i ponowne sprawdzenie.
Przez ten czas drgania powinny ustac.

Pozdrawiam
MIC
sumator_at_nospam_friko5.onet.pl


P.S.
Sorry za wielokrotna wiadomosc.







Poprzedni Następny
Wiadomoœć
spis treści
From: "Jerzy Szczesiul" <Jerzy.Szczesiul_at_nospam_ep.com.pl>
Subject: Re: :-)))
Date: Mon, 19 Apr 1999 23:45:16 +0300


Hi

Michał napisał(a) w wiadomości: <9YHS2.9206$Lj.133673_at_nospam_news.tpnet.pl>...
...
- wspomniane drgania wygeneruja jedno po drugim znaczna liczbe
przerwan / mozna to zablokowac ale to dodatkowa robota,

No wlasnie. Co sie stanie jesli podczas trwania obslugi przerwania
zostanie zgloszone znowu to samo przerwanie?
Mozna wylaczyc zezwolenie na przerwanie zaraz na poczatku jego obslugi
i wlaczyc z powrotem pod koniec?


Nic - 51 nie przyjmuje przerwan o tym samym priorytecie w trakcie
trwania obslugi. Bardziej niz o zgubienie przerwania chodzilo mi tu
o jego zbedna wielokrotna obsluge ( bo procesor moze nadazyc )
nie wnoszaca zadnej nowej informacji ( nie sprawdzalem takich
niuansow - to tylko moje wrazenie ale oparte na generalnej
zasadzie aby raczej nie dopuszczac do powstawania
w urzadzeniu stanow nie do konca przewidywalnych ).

Co do drgan zestykow, to w DSM51 proponuja po wykryciu
zmiany stanu klawisza odczekanie np 10ms i ponowne sprawdzenie.
Przez ten czas drgania powinny ustac.


To inna odmiana omawianej filtracji - te 10 ms i tak trzeba jakos
odmierzyc. Jesli jest duzo czasu to mozna i w petli opoznienia,
ale jesli masz wiele rownoleglych operacji do wykonania
( np. pomiary, transmisje itd. ) to szkoda i 10 ms na mielenie
w kolko.

Pozdrowienia
Jurek Szczesiul
Jerzy.Szczesiul_at_nospam_ep.com.pl