Przerwanie wywołane zboczem opadającym Atiny2313

To forum jest dla wszystkich pasjonatów mikrokontrolerów AVR Atmela. Wymiana doświadczeń i pomoc dla początkujących w pisaniu programów zarówno w C, Asemblerze jak i BASCOM. Zapraszam znawców tematu, aby pomogli wszystkim początkującym!
ODPOWIEDZ
Yacek_64
-
Posty: 3
Rejestracja: 17 cze 2010, 12:42
Lokalizacja: krosno

Przerwanie wywołane zboczem opadającym Atiny2313

Post autor: Yacek_64 » 17 cze 2010, 21:40

Witam!
Ponizej zamieścilem listing programu, zadanie trywialne, dioda swieci, wciskamy klawisz dioda gasnie , wciskamy ponownie swieci itd.
Przycisk NO jedna noga do masy druga do INT1 , dodatkowo podciągnięta zew. rezystorem do plusa . Symulacja pod AVRstudio dziala bezbłędnie. w fizycznej aplikacji - nie. jeśli zmieniam na wyzwalanie niskim poziomem a nie zboczem opadajacym to dziala poprawnie tyle ze trzymajac wcisniety przycisk caly czas wywolywane jest przerwanie . Tu wyjasnie , docelowo ma to byc licznik (enkoder z wykrywaniem kierunku ruchu )wiec przytrzymanie przycisku bedzie powodowalo ze wartość bedzie rosła , pomimo tego ze wielkosc liczona , przemieszczenie suportu nie ulega zmianie .
Prośba moze ktoś bardziej wprawny zerknie na kod . pisane bylo pod 902313 ale pod Atiny tez chodzi.

Kod: Zaznacz cały

.nolist
.include "2313def.inc"
.list
.cseg
.org 0
rjmp ResetProcessora
.org INT0addr
reti
.org INT1addr
rjmp Impuls_A
.org ICP1addr
reti
.org OC1addr
reti
.org OVF1addr
reti
.org OVF0addr
reti
.org URXCaddr
reti
.org UDREaddr
reti
.org UTXCaddr
reti
.org ACIaddr
reti
ResetProcessora:
cli
ldi r16,LOW(RAMEND)
out spl,r16

ldi r16,$08
out mcucr,r16
ldi r16,$80
out GIMSK,r16

ldi r16,0xFF
out DDRB,r16
out PORTB,r16

ldi R16,0x73
out DDRD,R16
ldi R16,0xFF
out PORTD,r16
Sei

start:
nop
rjmp start
Impuls_A:
in r16,portb
andi r16,0x01
cpi r16,0x00
breq LED_ON
cbi PORTB,0
rjmp koniec
LED_ON:
sbi PORTB,0
koniec:
reti
.exit
Przed założeniem kolejnego tematu proszę zapoznać się ze "wskazówkami dla piszących". marcing
Ostatnio zmieniony 18 cze 2010, 12:32 przez Yacek_64, łącznie zmieniany 1 raz.

keruseykaryu

Post autor: keruseykaryu » 18 cze 2010, 5:53

Gdzie są komentarze co jest co? I oczywiście zdajesz sobie sprawę z tego, że procesor działa realnie o wiele, wiele, wiele szybciej i każde drganie styków będzie analizowane...

Yacek_64
-
Posty: 3
Rejestracja: 17 cze 2010, 12:42
Lokalizacja: krosno

Post autor: Yacek_64 » 18 cze 2010, 7:53

Witam!
Juz wyjasniam - asembler. programik jest prosty i uznalem ze komentarze są zbyteczne .
Sądze ze istota problemu leży w deklaracji przerwań:
ldi r16,$08
out mcucr,r16
ldi r16,$80
out GIMSK,r16

Co do drgania styków- jeśli dobrze rozumie to przerwanie wywoływane zboczem opadającym w swojej istocie jest odporne na drgania styków tj. wciskam przycisk, mam zbocze opadajace procesor wywoluje przerwanie, blokuje zezwolenie na inne zgłoszenia przerwań , a styki niech sobie drgają . dla pewności tutaj tego nie ma, aby nie zaciemniać istoty, dodalem kilka pętli i tez kicha. kolejny wariant to na wejściu aby wyeliminowac dragania dodałem uklad schmita chyba UCY7414 , oczywiście kicha .(bo bym nie pisał posta)
Pozdrawiam

Awatar użytkownika
marcing
Użytkownik
Posty: 868
Rejestracja: 14 lut 2006, 14:13
Lokalizacja: z pociągu...
Kontakt:

Post autor: marcing » 18 cze 2010, 12:47

Yacek_64 pisze: Co do drgania styków- jeśli dobrze rozumie to przerwanie wywoływane zboczem opadającym w swojej istocie jest odporne na drgania styków tj. wciskam przycisk, mam zbocze opadajace procesor wywoluje przerwanie, blokuje zezwolenie na inne zgłoszenia przerwań , a styki niech sobie drgają
A czy zastanawiał się Kolega jaki będzie czas drgania styków w stosunku do czasu wykonywania procedury przerwania? Podpowiem: pierwsze trwa często wielokrotnie dłużej niż to drugie...
Yacek_64 pisze:kolejny wariant to na wejściu aby wyeliminowac dragania dodałem uklad schmita chyba UCY7414 , oczywiście kicha
Bez sensu jest stosować dodatkowo bramki, skoro wejścia uP już mają coś takiego.
Ale oczywiście o układzie gaszącym drgania Kolega zapomniał - a bardziej to jest potrzebne do poprawnego zadziałania układu. Cały układ to rezystor i kondensator, odpowiednio dobrana stała czasowa i gotowe...

Oczywiście można bardziej rozbudować program i utworzyć procedurę uwzględniającą drgania styków, ale wtedy lepiej korzystać z innego przerwania - od dowolnego z liczników, i cyklicznie co jakiś czas badać stan wejścia (50ms powinno wystarczyć).

atelszewski
Użytkownik
Posty: 143
Rejestracja: 12 sie 2005, 9:36
Lokalizacja: Banie

Post autor: atelszewski » 18 cze 2010, 20:54

Witam,
Bez sensu jest stosować dodatkowo bramki, skoro wejścia uP już mają coś takiego.
To, że piny pełniące funkcję zwykłych wejść mają Schmitt-a to wiem, bo wynika z dokumentacji. Ale czy ktoś z Was trafił na informację, żeby wejścia przerwań INTx posiadały lub nie Schmitt-a? Jeśli wiecie coś na ten temat, to proszę o informację.

Yacek_64
-
Posty: 3
Rejestracja: 17 cze 2010, 12:42
Lokalizacja: krosno

Post autor: Yacek_64 » 18 cze 2010, 20:59

Witam!
Początkowo przerwanie wywołane zboczem opadajacym miało zwiększać stan licznika, gdy to sie nie udalo do celów testowych napisałem powyzszy kod, jak mozna sie zorientować kazde kolejne naciśnięcie przycisku powoduje zmiane stanu na wyjściu co w konsekwencji prowadzi do gaszenie lub zapalania diody.
Gdzię popełniam błąd w rozumowaniu - Wciskam przycisk wywoluje przerwanie (zbocze opadające) uP wykonuje instrukcje zawarte w procedurze ( zwiększenie stanu licznika )a tam gdzieś w tle jak kolega sugeruje styki sobie drgają , w jednej z wersji programu bylyo kilka pętli opóźniajacych , powrót z procedury i co teraz ?drgające styki odłozyły na stos całą serje przewań ? jeśli tak to procesor wykonujący te przerwania powinien zwiększać stan licznika a tu nie obserwuje nic. W przyładzie z diodą dioda nie zmienia stanu , jeśli kolega ma racje to by oznaczalo ze drgania styku zawsze są liczbą prarzystą lub nie parzystą a to oczywiście bzdura.
Kwestia ukadu Schmita to wyjasniam ze jest tam jeszcze dwa rezystorki i kondziolki gaszące , tonący brzytwy się chwyta. Chciałem uniknąc przerwania od tajmerów z tego względu ze docelowo ma to być enkoder z badaniem kierunku ruchu i zbocze opadające wydaje mi się przerwaniem bardziej odpornym na błedy w tej aplikacji
Pozdrawiam

ODPOWIEDZ