Hej,

Pytanie zrodziło się w trakcie kodowania akurat tego procka, ale dotyczy ono de facto współczesnych procków Microchipa. W niniejszym przypadku sytuacja była następująca:

• zasilanie 5V
• wewnętrzny poziom odniesienia Vref = 2.5V
• histereza 50mV
• przerwania na oba zbocza

Zrobiłem czujnik fotoelektryczny (fotokomórkę) reagującą na przesłonięcie szczeliny. Test praktyczny polegał na tym, że w przerwaniu sprawdzałem stan wyjścia komparatora i na tej podstawie zapalałem lub gasiłem LED. Sprawdzenie stanu było pierwszym poleceniem w przerwaniu:



Generalnie to zadziała kilkanaście razy, ale w jakimś momencie potrafi się pogubić. Chodzi o to, że stan wyjścia komparatora potrafi się zmienić zanim nastąpi przerwanie sprawdzające tenże stan. Niby tylko kilka cykli zegara opóźnienia mamy, ale jednak to wystarczy, by pogrzebać ideę.

To samo dotyczy GPIO ustawionych na generowanie przerwań na oba zbocza. Sprawdzanie stanu pinu w przerwaniu, by określić jaka zmiana jego stanu spowodowała to przerwanie, jest niecelowe.

Mam pytania:
1. Czy jest jakiś programowy trik, który pozwoli niezawodnie ustalić przyczynę przerwania?
2. Czy w innych prockach firmy, w tym SAM'ach mamy coś w rodzaju buforowania przyczyny przerwania etc?

ja akurat na tych prockach nic nie robiłem - ale nawet trudno sobie wyobrazić żeby nie było możliwości ustalenia przerwania zawsze jest jakiś rejestr albo rejestry z flagami przerwań ... inaczej czyli gdyby tego nie było to procki byłyby głupie jak beton Na 100% nie dotarłeś do tej informacji w nocie PDF. Jeśli ktoś używał tego procka to może szybciej podpowie coś konkretnego

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wiesz... może być tak, że coś w nocie źle zinterpretowałem.

Z drugiej zaś strony prosty eksperyment, który opisałem jasno dowodzi, że badanie stanu pinu, czy wyjścia komparatora, nie pozwoli na określenie jaka zmiana sygnału H/L czy L/H spowodowała przerwanie. Oczywiście zaczekam na "ochotnika", który objaśni mi problem

W międzyczasie, powiedz mi - czy w tych starszych prockach typu ATTiny85, albo pośrednich jak ATMega328, można było bazować na stanie pinu, by określić zbocze, które spowodowało przerwanie? Patrząc na noty, mamy tu podobną sytuację.

Po to są komparatory stworzone w prockach i jednym z podstawowych ich zadań jest możliwość generowania przerwania w zależności od ustawionego progu napięcia - są różne konfiguracje zresztą, a twój eksperyment wcale nie dowodzi że procek na to nie pozwala - dowodzi tylko na to, że nie wiesz jak to zrobić i jak się do tego zabrać kompletnie.... A już na bazie tego twojego eksperymentu wystarczyłoby zbadać od razu w przerwaniu stan napięcia na wejściu aby zorientować się czy doszło do zmiany z H/L czy L/H ...

a jakbyś pokusił się i zajrzał do byle noty zwykłego starego avr'a - nawet tego attiny85 o którym wspominasz to znalazłbyś takie coś:



i dalej byś mówił że to niemożliwe? i dalej będziesz twierdził że w nowszych prockach jest to niemożliwe ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jeśli to taki szybki sygnał, to może przyspiesz taktowanie?

Zawsze jadę na maksymalnym taktowaniu.
Wiesz, nie ma takiego taktowania, które nie załapie się na zmianę sygnału na jakimś pinie w trakcie kolejnych taktów.
Wydaje mi się, że jedynie buforowanie sygnału, który powoduje przerwanie (czyli zamrożenie stanu sygnału do czasu zakończenia obsługi przerwania) dałoby taką gwarancję.

------------------------ [ Dodano po: 50 minutach ]



Gdybym wiedział, to bym nie pisał przecież.



Hmmm... musisz mi jaśniej opisać co należy zrobić, bo nie nadążam. Powiedzmy, że mam ustawione ACIS0 = ACIS1 = 0, bo analogicznie mam w nowym procku i tak ma być. Chcę reagować na przesłonięcie i odsłonięcie fotokomórki. Czyli przerwanie następuje na zmianę stanu.

Zgodzisz się ze mną, że gdy na wejściu komparatora mam fotokomórkę, to w momencie przesłonięcia jej, na tym komparatorze może zostać wygenerowana seria kilku przerwań (bo przesłona nie jest idealna)? Jeśli nie, to mogę przygotować screenshot z oscyloskopu (sygnał analogowy na wejściu komparatora + zmiany stanu na pinie testowym przy każdym przerwaniu + kolejnym pinie testowym, kopia stanu komparatora odczytana z rejestru). Mam w zasobach ATTiny85 również, więc mogę napisać procedurę testową na niego, choć tu spodziewam się totalnej zadymy, bo komparator nie ma histerezy usuwającej większość zakłóceń sygnału.

Jeśli jednak ufasz powyższemu, to wyjaśnij krok po kroku - jak dokonujesz sprawdzenia stanu komparatora, który spowodował to przerwanie: czy był wysoki, czy niski?

Od razu powiem, że odczyt rejestru stanu komparatora nie jest celowy. Czytanie bitu 5 jak niżej:

jest zawodne, jak pisałem: pokazuje on bieżący stan komparatora (pomijam opóźnienie 2 cykli), a nie stan, który spowodował przerwanie. Często jest on zgony z rzeczywistością, ale nie zawsze.