Witam.

Dziś biblioteka do obsługi enkodera obrotowego. Znów uniwersalna (inicjalizacja i odczyt sprzętu po stronie użytkownika). Możliwości biblioteki:

• Nieblokująca.
• Reakcja na zdarzenia z enkodera (użytkownik musi zdefiniować).
• Obsługa przycisku enkodera z rozróżnieniem długości wciśnięcia - 3 poziomy.

Poniżej kod.
encoder.h:
encoder.c:
Przykład znów dla Atmega2560.
main.h:

main.c:
Timer wywołuje przerwanie co 1 ms dla F_CPU 16000000UL. Dla innego zegara MCU trzeba policzyć na nowo.
Proszę o niekopiowanie kodu w innych miejscach bez mojej zgody. Kod udostępniam do użytku niekomercyjnego.
Jak ktoś ma uwagi z chęcią się zastosuję do nich.

EDYTA1:
Zmiany w kodzie:

• Dodałem możliwość wyłączenia obsługi przycisku przez bibliotekę.
• Dodałem obsługę podzielnika impulsów enkodera. Moje wszystkie enkodery pomiędzy stabilnymi pozycjami dają po 4 impulsy.
• Podzieliłem funkcję encPool na kilka aby poprawić czytelność kodu.

EDYTA2:
Kolejne zmiany w kodzie:

• Poprawiłem funkcje odczytu kierunku obrotu enkodera (działała odwrotnie, bo miałem odwrotnie podłączony enkoder).
• Dodano więcej komentarzy w kodzie.
• Trochę optymalizacji w celu zmniejszenia kodu wynikowego - każdy bajt w AVR się liczy
• Zmiana działania bardzo długiego wciśnięcia przycisku - teraz reaguje dopiero po puszczeniu.
• Bardziej restrykcyjne przekazywanie zmiennych do funkcji (również callback). Dodałem const wszędzie gdzie funkcja nie powinna zmieniać wartości ani wskaźnika.
• Małe zmiany w kodzie w main.c.

Przyznam że to jest to co odpycha mnie w jezyku C ,,, ta ilość kodu . No ale chce osobiście to sprawdzić , tzn. jezyk C a że często korzystam z enkoderów to fajnie że ktoś prezentuje biblioteke , być może za jakiś
czas skorzystam z niej ,przetestuje .
Małe pytanko do autora , ważne bo nie wyjaśnił tego .
Otóż klasyczny enkoder wiadomo jak działa , dwie fale impulsów przesuniete wzajemnie w fazie .
Sa inne typy enkoderów ale zakładam że tu mowa o takim "klasycznym" .
Pytanie brzmi : czy jest to biblioteka do obsługi typowego "cyfrowego potencjometru" ręcznie pokręcanego przez użytkownika ?
Czy też jest to biblioteka która "umie" bez błędów obsłużyć dość szybki enkoder przemysłowy dający
zmienne impulsy (szybkość oraz kierunek) z czestotliwościami na jednej fazie powiedzmy na przykład
250 kHz . Wiem ... mam świadomość że to jest zależne od Platwormy (mikroprocesora) ale chodzi mi o samo założenie autora oraz pewnie jakieś testy które musiał przeprowadzić przed prezentacją kodu na forum .
//
Jeśli to nie jest jakiś problem to prosiłbym o odpowiedż.

PS "Proszę o niekopiowanie kodu w innych miejscach bez mojej zgody. Kod udostępniam do użytku niekomercyjnego.
Jak ktoś ma uwagi z chęcią się zastosuję do nich."

Prosze sie nie obawiać uszanuje taką wole ,zaprezentowany kod będzie dla mnie jedynie przykładem .
Z innej strony to chyba ,tak mi sie wydaje . warto sie dobrze zastanowić przed publikacją czy oddajemy swoją myśl innym czy też zachowujemy dla siebie . Pośrednie rozwiązania słabo sie sprawdzają w praktyce .

Tak to jest biblioteka do obsługi enkoderów "ręcznych", na wyjściu których pojawia się dwu bitowy kod Graya. W przykładzie próbkowanie stanu wynosi 1kHz i jeśli zbyt szybko zakręcimy gałką to program się "gubi", tzn. będą chwilowe problemy z odczytem kierunku kręcenia (najczęściej jeden impuls nie w tą stronę, bo nie próbowałem zakładać gałki enkodera do wkrętarki). Można próbkować z większą częstotliwością (wydaje mi się, że przynajmniej 2, jak nie 4 razy większą niż częstotliwość impulsów) i kod powinien działać dla enkoderów dających na wyjściu taki sam przebieg. Problemem może być zapewnienie wywołania przerwania ze stałą częstotliwością i zmieszczenie się w cyklach procesora między przerwaniami (przy próbkowaniu 1MHz i zegarze 16MHz masz tylko 16 cykli co będzie stanowczo za mało dla biblioteki w tej formie - oczywiście można nanieść zmiany w tym kodzie w celu zwiększenia wydajności tracąc na uniwersalności, ale raczej nie zmieścisz się w 16 cyklach - kod wynikowy funkcji encPool ma 188 bajtów i 74 linie w assemblerze, nie licząc wywoływanych callbacków i kodu samego przerwania - cykli nie próbowałem liczyć).
Ilość kodu - pojęcie względne. Tu jest pełno komentarzy, system callbacków co pozwala na bardziej uniwersalną obsługę niezależną od platformy bez grzebania w kodzie biblioteki (można to zamienić na makra co zmniejszy nieznacznie kod wynikowy, ale nadal użytkownik musi definiować obsługę od strony sprzętowej - stany wejść, przerwania timera), no i starałem się by kod był czytelny. Jeśli porównujesz do BASIC (BASCOM) to tam masz gotowe biblioteki i korzystasz z tego co dostarcza, a jak czegoś nie ma to musisz pisać na piechotę i dochodzisz do tego co w C. Jak w C masz gotowe biblioteki to tego kodu wcale nie jest dużo.
Co do notki na dole po prostu jeśli skorzystasz z biblioteki w swoim projekcie hobbystycznym i będziesz chciał go opublikować to daj linka to tego tematu z kodem i sprawa załatwiona.

Dzieki za odpowiedz . co do Bascoma to owszem właśnie w nim od w sumie bedzie już od wersji na 51 pisze , z 16 lat ? tak jakoś , daje rade pod warunkiem że z daleka obchodzi sie właśnie wiele pułapek w postaci "złych" gotowych procedur . Kiedyś próbowałem gotowizny właśnie dla takiego "ręcznego nastawnika" w postaci enkodera ,masakra , napisałem swoje i nie było z tym problemów .Zawsze oscyloskop pod ręką i optymalizacja czasowa kodu .
Ale chce wejść w nowe procesory i tu jest język C .
OKI . Dziękuje ci za wyjaśnienia .