ATNEL tech-forum

Re: Fałszywe przerwania zewnętrzne

2016-07-11T07:15:08+01:00

McSwirus napisał(a):

Świetna wiadomość, możesz podesłać jakiegoś linka gdzie jest opis jak tego używać
lub pod jakim hasłem szukać ?

Szczegóły jak zwykle w datasheet, strona 117, rozdział 21.6. Input Capture Unit. Wprawdzie ta jednostka służy nieco innym celom, ale przecież można zignorować zawartość ICR1 i po prtostu wykorzystać samo przerwanie (ustawiając bit TICIE1 w rejestrze TIMSK) z filtrowaniem sygnału na pinie (kluczowe jest tutaj ustawienie bitu ICNC1 w rejestrze TCCR1B).

McSwirus napisał(a):

andrews napisał(a):

PS. Zamiast wejścia ICP1 można też ewentualnie użyć wejścia komparatora analogowego.

Czy to wiąże się ze sprawdzaniem stanu w pętli głównej programu
czy nadal można to zrobić "sprzętowo" ?

Jak już wspomniał kolega Mirek, komparator analogowy ma swoje przerwanie. Obawiam się jednak, że komparator sam w sobie nie posiada funkcji redukcji szumów. Dopiero skonfigurowanie jego wyjścia jako źródła sygnału dla jednostki Input Capture timera 1 pozwala na skorzystanie z tej opcji. Czyli tak czy inaczej, niezależnie od użytego pinu i tak trzeba będzie skorzystać z przerwania Input Capture. Jeśli więc masz możliwość użycia pinu ICP1, będzie to prostsze rozwiązanie.

Wadą rozwiązania jest to, że wykorzystujemy funkcjonalność (przerwanie Input Capture), która jest czasami potrzebna do innych celów (w Atmega8A jest tylko jeden taki pin) i blokujemy rejestr ICR1, więc nie będzie możliwe skorzystanie ze wszystkich dostępnych trybów pracy timera 1 (np. tryb 14 fast PWM wykorzystuje rejestr ICR1 do przechowywania wartości TOP). Poza tymi ograniczeniami z timera 1 można korzystać.

Statystyki: Napisane przez andrews — 11 lip 2016, o 07:15

Re: Fałszywe przerwania zewnętrzne

2016-07-10T21:57:54+01:00

McSwirus napisał(a):

czy nadal można to zrobić "sprzętowo" ?

No a nie zaglądałeś do noty PDF ? Toż zawsze masz przerwanie od komparatora

Statystyki: Napisane przez mirekk36 — 10 lip 2016, o 21:57

Re: Fałszywe przerwania zewnętrzne

2016-07-10T21:10:43+01:00

andrews napisał(a):

Świetna wiadomość, możesz podesłać jakiegoś linka gdzie jest opis jak tego używać
lub pod jakim hasłem szukać ?
Muszę zorientować się jak mam to podłączyć i jak zmodyfikować program.

andrews napisał(a):

Rozwiązanie takie miałoby taką zaletę, że uniknąłbyś niepotrzebnych przerwań. Ich obsługa zajmuje czas mikrokontrolera, a przecież zaraz po szpilce może nastąpić prawidłowe zbocze. Obsługa przerwania od tego prawidłowego zbocza będzie musiała wtedy poczekać do zakończenia poprzedniego. Dodatkowo jeśli takich niechcianych przerwań będzie dużo, utrudni to mikrokontrolerowi wykonywanie innych funkcji.

Widzę, że kolega doskonale rozpoznał mój problem i wynalazł dobre rozwiązanie,
za to wielkie dzięki. Pozostaje do-edukować się

andrews napisał(a):

Oczywiście sprawdzenie stanu pinu można dla pewności wykonywać w procedurze obsługi przerwania, ale w zdecydowanej większości przypadków będzie to raczej formalność (no chyba, że tych zakłóceń masz bardzo dużo i ich czas trwania bywa większy od 271ns).

W takiej sytuacji pewnie można odpuścić sprawdzanie stanu INT0 (PD2 w Atmega8).
Zakłócenia pojawiają się pojedyncze na kilka ms przed zboczem narastającym,
tzn. przed każdym zboczem narastającym jest jedno silne zakłócenie ale jego wystąpienie
na osi czasu jest w różnych punktach przebiegu.

andrews napisał(a):

PS. Zamiast wejścia ICP1 można też ewentualnie użyć wejścia komparatora analogowego.

Czy to wiąże się ze sprawdzaniem stanu w pętli głównej programu
czy nadal można to zrobić "sprzętowo" ?

Wielkie dzięki za podpowiedzi.
McSwirus

Statystyki: Napisane przez McSwirus — 10 lip 2016, o 21:10

Re: Fałszywe przerwania zewnętrzne

2016-07-10T16:44:32+01:00

Jeśli masz wolne wejście ICP1 i nie wykorzystujesz w programie rejestru ICR1, można by spróbować wykorzystać sprzętowy "noise canceler" mikrokontrolera. Jeśli redukcja szumów na wejściu ICP1 jest włączona, stan stabilny na tym wejściu musi trwać przez 4 kolejne takty zegara (czyli ok. 271ns przy taktowaniu 14.7456MHz), aby przerwanie zostało wywołane (flaga ustawiona).

Rozwiązanie takie miałoby taką zaletę, że uniknąłbyś niepotrzebnych przerwań. Ich obsługa zajmuje czas mikrokontrolera, a przecież zaraz po szpilce może nastąpić prawidłowe zbocze. Obsługa przerwania od tego prawidłowego zbocza będzie musiała wtedy poczekać do zakończenia poprzedniego. Dodatkowo jeśli takich niechcianych przerwań będzie dużo, utrudni to mikrokontrolerowi wykonywanie innych funkcji.

Oczywiście sprawdzenie stanu pinu można dla pewności wykonywać w procedurze obsługi przerwania, ale w zdecydowanej większości przypadków będzie to raczej formalność (no chyba, że tych zakłóceń masz bardzo dużo i ich czas trwania bywa większy od 271ns).

PS.
Zamiast wejścia ICP1 można też ewentualnie użyć wejścia komparatora analogowego.

Statystyki: Napisane przez andrews — 10 lip 2016, o 16:44

Re: Fałszywe przerwania zewnętrzne

2016-07-10T16:24:33+01:00

McSwirus napisał(a):

P.S. Jeden programista zasugerował mi, żeby w pierwszej linii procedury obsługi przerwania
zablokować wszystkie przerwania

No wiesz początkujący programiści mają prawo takie rzeczy sugerować ... nie każdy bowiem początkujący doczyta w nocie PDF procka, że po uruchomieniu przerwania wszystkie inne są wyłączone na ten czas automatycznie więc powielanie tej procedury w kodzie jest po prostu najzwyklejszym nonsensem ...

A sytuacja ta nie dotyczy jak pytasz tylko ATmega8 ... to dotyczy KAŻDEGO procka AVR8 bez wyjątku

Statystyki: Napisane przez mirekk36 — 10 lip 2016, o 16:24

Re: Fałszywe przerwania zewnętrzne

2016-07-10T13:54:29+01:00

mirekk36 napisał(a):

Wskazówka jest taka, że no jak w ogóle można myśleć o delayach w przerwaniu, gdy ty i tak rozważasz czasy nanosekundowe Nie ma to nic wspólnego z tym czy uda się zrobić delaya nanosekundowego bo sama pojedyncza instrukcja asemblerowa NOP przy taktowaniu np 8MHz to już opóźnienie = 125 ns - więc w czym problem ? Ja mówię, że to już kompletny nonsens wstawiać jeszcze opóźnienia delay do przerwania w którym i tak przeszkadza ci opóźnienie samego asemblerowego prologu i epilogu przerwania ...

I wszystko jasne, już przepatrzyłem kod asm: 27 instrukcji push, 1 in, 1 eor, łącznie mi dało 56 taktów procka.
Przy 14.7456 MHz daje to czas 3.8 us (mikro sekundy) zatem o wiele dłuższy niż potrzebowałem,
myślę, że śmiało mogę w pierwszej linii procedury sprawdzić stan wejścia

Tak Panie Mirku, teraz wszystko rozumiem, po prostu wcześniej nie sprawdziłem
ile czasu trwa jeden takt procka, u mnie to 68ns, wystarczyły by 4 NOP'y ale są niepotrzebne.

P.S. Jeden programista zasugerował mi, żeby w pierwszej linii procedury obsługi przerwania
zablokować wszystkie przerwania, jednak na necie znalazłem, że procek wykonuje to sprzętowo,
czyli blokuje przerwania na wejściu w procedurę i odblokowuje na wyjściu.
Czy na 100% Atmega8A właśnie tak robi z INT0 ?
W kodzie asm nie ma żadnej instrukcji a testów nie mogę wykonać dzisiaj,
a chciał bym wiedzieć, skróciło by to moje testy

Pozdrawiam
McSwirus

Statystyki: Napisane przez McSwirus — 10 lip 2016, o 13:54

Re: Fałszywe przerwania zewnętrzne

2016-07-10T13:24:09+01:00

McSwirus napisał(a):

I tu chyba nie zrozumiałem
Czy sugerujesz, że nie dam rady napisać delaya 300ns ?
Być może w tej chwili jeszcze nie, ale zawsze można dać
jakąś pętelkę z inkrementacją zmiennej, a to może trwać kilka setek ns.
Ale być może źle coś zrozumiałem. Jak możesz to rozjaśnij mi w głowie.

McSwirus napisał(a):

Co do filtrowania zakłóceń na wejściu INT0 to filtr RC 100Ohm, 100nF nie daje rezultatów a jedynie wydłuża czas narastania i spadania sygnału.

No na tym polu to ja ci akurat nie pomogę bo nie czuję się w tym za dobrze - może ktoś inny jakieś cenne uwagi ew podpowie

Statystyki: Napisane przez mirekk36 — 10 lip 2016, o 13:24

Re: Fałszywe przerwania zewnętrzne

2016-07-10T13:15:48+01:00

mirekk36 napisał(a):

[...] Za to możesz sobie łatwo sprawdzić ile to trwa , wystarczy podejrzeć plik *.lss po kompilacji czyli źródło w asemblerze i podliczyć ile masz instrukcji ASM a później sprawdzić ile każda z nich zajmuje taktów procka i podliczyć to sobie ...

Dzięki za wskazówkę, na pewno przepatrzę ten plik.

McSwirus napisał(a):

2. zasady mówią, żeby nie dawać "delay'ów" w tych procedurach,
tyle, że nie mam pomysłu jak to wykonać bez oczekiwania np.: 300ns.

mirekk36 napisał(a):

No no nooo ... to z delayami rozumiem, że byś sobie co? poradził ? chyba żartujesz

mirekk36 napisał(a):

Odnośnie tych szpilek nanosekundowych to spróbuj może jakimś kondkiem powalczyć - ale to już pewnie trzeba dobierać doświadczalnie

Walczyłem filtrem LC na zasilaniu, muszę zastosować lepsze kondensatory (szybsze, więc pewnie kilka mniejszych równolegle).
Co do filtrowania zakłóceń na wejściu INT0 to filtr RC 100Ohm, 100nF nie daje rezultatów a jedynie wydłuża czas narastania i spadania sygnału. Użyję jeszcze dobrze skręconej parki w ekranie, może coś się zmieni.

P.S. Walkę ciągnę na 2 frontach: soft i hardware

Dzięki.
McSwirus

------------------------ [ Dodano po: 4 minutach ]

maverick_as napisał(a):

Wiem , to mało odkrywcze, ale być może lepiej zrezygnować z przerwania sprzętowego i w bardziej "wyszukany" sposób wyłapywać porgramowo przejście 0 -> 1.
Pozdr.

Nad tym się też zastanawiałem, jednak najważniejsza jest szybka reakcja na przerwanie.
W pętli głównej mam procedury transmisji danych do PC'ta, więc reakcja na zmianę stanu
mogła by być zdecydowanie za wolna. Na razie powalczę z przerwaniami.

Dzięki
McSwirus

Statystyki: Napisane przez McSwirus — 10 lip 2016, o 13:15

Re: Fałszywe przerwania zewnętrzne

2016-07-10T12:51:45+01:00

Wiem , to mało odkrywcze, ale być może lepiej zrezygnować z przerwania sprzętowego i w bardziej "wyszukany" sposób wyłapywać porgramowo przejście 0 -> 1.
Pozdr.

Statystyki: Napisane przez maverick_as — 10 lip 2016, o 12:51

Re: Fałszywe przerwania zewnętrzne

2016-07-10T12:31:41+01:00

McSwirus napisał(a):

tylko nie wiem ile ? Być może wystarczająco długo, dłużej niż 300ns

No może być spokojnie dużo dłużej niż 300 ns w zależności od taktowania procka ... Za to możesz sobie łatwo sprawdzić ile to trwa , wystarczy podejrzeć plik *.lss po kompilacji czyli źródło w asemblerze i podliczyć ile masz instrukcji ASM a później sprawdzić ile każda z nich zajmuje taktów procka i podliczyć to sobie ...

McSwirus napisał(a):

2. zasady mówią, żeby nie dawać "delay'ów" w tych procedurach,
tyle, że nie mam pomysłu jak to wykonać bez oczekiwania np.: 300ns.

No no nooo ... to z delayami rozumiem, że byś sobie co? poradził ? chyba żartujesz

McSwirus napisał(a):

3. Czy mogę potraktować nóżkę PD2 (INT0) jako wejście i bezkarnie
odczytać jej stan wewnątrz procedury obsługi przerwania ?

A co ma być w tym karnego albo bezkarnego ??? Kto ci zabroni odczytać stan tego pinu w przerwaniu ? toż to normalna procedura jak jedzenie chleba naszego powszedniego

------------------------ [ Dodano po: 1 minucie ]

Odnośnie tych szpilek nanosekundowych to spróbuj może jakimś kondkiem powalczyć - ale to już pewnie trzeba dobierać doświadczalnie

Statystyki: Napisane przez mirekk36 — 10 lip 2016, o 12:31

Fałszywe przerwania zewnętrzne

2016-07-10T11:23:45+01:00

Witam,

jestem nowy na forum, to moje początki programowania uC.

Stworzyłem pewien układ prototypowy oparty na Atmega8A z zegarkiem 14.7456 MHz.
Podaję zewnętrzny sygnał 0-5V na INT0 - reagujące na zbocze narastające.
Sygnał o częstotliwości od 16Hz do 200Hz z wypełnieniem około 80% czasu 5V i 20% czasu 0V.
Gdy mam stan niski w sygnale pojawiają się zakłócenia, takie szpilki 2-3V
o czasie trwania ok 250-350ns. Urządzenie będzie pracowało w bardzo
trudnych warunkach jeśli chodzi o zakłócenia, jestem na etapie
testów nowych filtrów LC na rdzeniach do filtrowania zakłóceń zasilania,
ale część zakłóceń pochodzi od fal elektromagnetycznych i z nimi
mam także wielki problem aby wyfiltrować.

Gdy pojawia się taka szpilka często generowane jest przerwanie INT0.

Aby zapobiec programowo temu zjawisku chciałem w procedurze obsługi przerwania
na początku dodać sprawdzenie czy na wejściu INT0 mam stan wysoki czy niski
aby podjąć decyzję czy to "fałszywe" wywołanie przerwania (szpilką),
czy może to właściwe stanem wysokim.

I tu mam problem gdyż nie mogę się dokopać w sieci do informacji:
1. ile taktów procesor potrzebuje na wywołanie tego przerwania (INT0),
na pewno odkłada na stos szereg rejestrów a to zajmuje czas,
tylko nie wiem ile ? Być może wystarczająco długo, dłużej niż 300ns
2. zasady mówią, żeby nie dawać "delay'ów" w tych procedurach,
tyle, że nie mam pomysłu jak to wykonać bez oczekiwania np.: 300ns.
3. Czy mogę potraktować nóżkę PD2 (INT0) jako wejście i bezkarnie
odczytać jej stan wewnątrz procedury obsługi przerwania ?

Za wszelkie uwagi z góry dziękuję, prośba moja dotyczy kodu,
z zakłóceniami na poziomie sprzętu walczę i powolutku idę do przodu.

McSwirus

Statystyki: Napisane przez McSwirus — 10 lip 2016, o 11:23