Antystatyczny napisał(a):
Sam sie dziwię, że to działa, bo na logike nie powinno.
Powinno powinno
Antystatyczny napisał(a):
Tzn. powinno działać poprawnie w jedną stronę.
Nie nie - na pewno w dwie strony.
Antystatyczny napisał(a):
Mirku, Może po prostu przetestuj to u siebie w wolnej chwili na dowolnym encoderze i z proponowaną przeze mnie aplikacją.
Właśnie przetestowałem
Antystatyczny napisał(a):
Czy mechanizm flag zastosowany jest słusznie?
pewnie, że tak - korzystanie z callbacków jest proste jak drut a takie przykłady pomagają ludziom to zrozumieć - potem nikt nie będzie się ich bał jak jeża. Pewnie że można bez nich .... ale co z tego ?
.... można i w ogóle bez mikrokontrolera jak się uprzeć gdyby iść tym tropem
a teraz wyjaśnienie - bo bo moja uwaga oczywiście była niesłuszna a wniosek wyciągnięty tylko po rzuceniu okiem :
mirekk36 napisał(a):
Tutaj o ile się nie mylę wszystko zależy od:
mirekk36 napisał(a):
czyli od jednego wyjścia ??? ... albo coś za szybko rzuciłem okiem albo to może okazać się zawodne w wielu sytuacjach
oczywiście, że nie zależy od jednego wyjścia enkodera
bez DWÓCH się nie obędzie i nie mogłoby to działać. Po prostu jedno zgłasza przerwanie a w przerwaniu badamy stan drugiego i jeśli jest 1 to kerunek X a jeśli jest 0 to kierunek Y
najprostsza z możliwych implementacji i sam choć zapomniałem - to jak zaczynałem walkę z enkoderem też ją przeszedłem no ale przeskakiwały wartości okrutnie
... tylko że wtedy zapomniałem kondensatorów dać
.....
Tymczasem ta metoda którą kiedyś jako pierwszy podał nasz Sun a ja potem jeszcze troszkę ją pozmieniałem i zaprezentowałem jako że uwzględnia kodowanie greya to może się obejść nawet bez kondków i działa precyzyjnie - choć jest coś za coś - tracimy jeden timer niestety.
Reasumując po dodaniu kondków rzeczywiście tą metodę można spokojnie wykorzystywać - tylko skoro już jesteśmy przy zdarzeniach , callbackach itp to warto zwrócić uwagę na fakt że jeśli w przerwaniu mielibyśmy TYLKO ustawiać jakąś jedną flagę i nic innego nie robić albo tak jak w przerwaniu INT2 tylko badać stan jednego pinu to jednak kod można ZNACZNIE uprościć tak aby był bez przerwań tzn tfuuu bez procedur obsługi przerwań no bo przecież można korzystać ze sprzętowych flag przerwania. Tak więc np to co jest w INT2 przenieść wprost do ENCODER_EVENT()
.... zrezygnować z flag opatrzonych volatile
... zresztą proszę jak niżej ... ta uproszczona wersja kodu choć nadal zawiera pełną funkcjonalność callbacków to jednak zabiera mniej i RAM i FLASH
.... warto to podejrzeć ... i dokładnie na takiej samej zasadzie zmodyfikować sobie twój LCD_EVENT() ... identycznie:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
specjalnie zakomentowałem to co zostało uproszczone i wywalone z kodu.
REASUMUJĄC - w zależności od potrzeb projektu i potrzebnej precyzji a tym bardziej gdy mamy leżące odłogiem timery można korzystać z tej metody z kodem greya i timerem
http://mirekk36.blogspot.com/2013/04/en ... y-cz2.htmla w innych przypadkach - chyba nawet w większości przypadków, można korzystać z tej metody - opisanej w tym wątku
Myślę że tym sposobem wyjaśniliśmy na naszym forum chyba WSZYSTKIE ważne aspekty obsługi popularnych enkoderków.