Witam wszystkich i bez zbędnego owijania mam prośbę abyście w boju przetestowali poniższy programik do obsługi enkodera-impulsatora. Podłączajcie pod procka przetarte ("iskrzące") stare enkodery (kurcze ja mam wszystkie nowe i sprawne) i katujcie ile się da. Moje próby wyprowadzenia programu z równowagi nie powiodły się. Konkretny impuls zawsze należał do konkretnego pyknięcia i nie udało mi się zarejestrować ani jednego błędu mimo prób bardzo wolnego (przyblokowanego) ruchu gałką.
Podaje dla ułatwienia testów dwie wersje: dla enc połówkowego czyli jeden krok to 00-01-11, następny krok 11-10-00, oraz takiego który przelatuje przez całą sekwencję od 00-01-11-10-00 i dopiero zatwierdza impuls (właściwie robi to w trakcie ).
Procesor Atmega32 taktowany kwarcem 16Mhz.
Konfiguracja LCD następująca:


Enkoder podłączamy bez żadnych dodatkowych elementów (broń boże jakieś kondensatory tam pchać) bezpośrednio pod dwa pierwsze piny czyli 0 i 1 portu A.

Chodzi o to, że uparłem się (tak już mam ) aby nie korzystać z gotowych rozwiązań, które nie do końca są po mojej myśli i zacząłem tworzyć własną obsługę enkodera. Warunkiem była oczywiście pewność działania przy stosunkowo małym rozmiarze kodu (136 bajtów dla wersji "half" i 80 bajtów dla wersji "full"), mała zasobożerność (kod jest błyskawiczny) i duża szybkość reakcji. Tu pracuje w przerwaniach 10kHz i obsługa 500 impulsowego enkodera (pracował jako half) jaki z największych miałem pod ręką była bezproblemowa. Jeśli dobrze liczę to powinienem przy tej częstotliwości taktowania odbierać impulsy z częstotliwością ponad 3300Hz (3 kroki na cykl liczenia). Jeszcze jedną rzeczą, której chciałem uniknąć to zatrzymywania przerwań (atomic block). W moich projektach sterowników są one dość rygorystycznie obsługiwane i mogłoby (choć nie koniecznie musiało) zakłócić pracę innych bloków programu.
Na razie testujcie. Kod będzie później jak się okaże, że wszystko jest ok i nie mam się czego wstydzić

_________________
http://www.sylwekkuna.com

Brzmi interesująco. Gratuluję ciekawego podejścia do prezentacji swojej pracy.
Na pewno wypróbuję kod, bo bardzo interesują mnie enkodery
Ciekaw jestem tych obietnic...

Dotrzymuję słowa Najpierw testy, później kod

_________________
http://www.sylwekkuna.com

Ach źle napisałem, chodziło mi o wypróbowanie wsadu (w domyśle kodu, w końcu bez kodu nie ma wsadu )
Mam w domu enkoder optyczny 360 impulsów na obrót (pogróżka ), będę zatem bezlitosny

Z drugiej strony tak sobie myślę, że goła obsługa enkodera nie jest tak dużym wyzwaniem jak choćby nieco bardziej skomplikowany, wielowątkowy, czasowy projekt.
W takich dopiero warunkach można oceniać kod obsługi enkodera, co mam nadzieję, że wypróbujemy w następnych iteracjach.

Świetnie. Na to liczę

_________________
http://www.sylwekkuna.com

Widzę, że wsad parę razy pobrany... Naprawdę nikt jeszcze nie przetestował tej próbki?

_________________
http://www.sylwekkuna.com

Idzie do mnie enkoder > 16kobr. Jak dojdzie - przetestuję i dam znać.

To chyba jakiś specjalistyczny? Przy wysokich obrotach nie ma szans, żeby AVR czegoś nie zgubił, chociaż jakby podnieść częstotliwość przerwań to coś tam zliczy
Jak będę przy kompie to wrzucę bibliotekę. Będzie wtedy można przetestować na czym kto może i na czym kto chce

_________________
http://www.sylwekkuna.com

Witaj SylwekK,

skusiłem się by sprawdzić ten wsad.
pobawiłem się na ATB 1.05 ,
kręcąc w obie strony jak szalony. (dobrze że enkodera nie urwałem)
sprawdziłem też w powolnym tempie,
zauważyłem że pojawia się sporadycznie kierunek przeciwny(czyli zakłócenia z mojego enkodera),
kurcze, pomimo tego oszukaństwa licznik nie zgubił się.
i o wyskalowaniu graficznym widzę pomyślałeś. działa fajnie !
pozdrawiam Darek P.

No dobra, to wrzucam jak obiecałem bibliotekę. Myślę, że wybaczycie mi dużo mniej elastyczny sposób jej konfiguracji w porównaniu z tym co robi Mirek, ale mimo wszystko z jej korzystaniem nie powinno być problemu. W załączniku libsik, a poniżej przykładowe użycie na M32 16Mhz.

Aktualna wersja biblioteki pod poniższym linkiem:
topic18208.html#p188030



@Daro69, z tym kierunkiem to po prostu odczyt zmiennej encoder_dir, a ta w trakcie drgania styków może się zmienić kilka razy Umieściłem w tamtym wsadzie tylko jako ciekawostkę. Jeśli to komuś potrzebne to można badać już sam wynik po zmianie i będzie bardziej wiarygodnie

_________________
http://www.sylwekkuna.com

aha ...nie napisałem że odpaliłem na 18,432 MHz, , bo nie miałem 16-ki.
dzięki za .c i .h , przeanalizuję w celu edukacyjnym.

Aha, a ja zapomniałem dopisać, że jeśli ktoś nie korzysta z przerwań to też można spokojnie działać z enkoderem. Warunek jest taki, że cały czas w pętli musi być odczytywany razem z aktualizowaną zmienną czyli coś w tym stylu:


EDIT:
Oczywiście w takim przypadku warto LCD odświeżać nieco rzadziej, bo to on będzie tu zakłócał odczyt (spora strata czasowa) i w życiu nie uzyska się takiej pewności zliczania jak w przerwaniach.

_________________
http://www.sylwekkuna.com

Projektuję i buduję gniazda produkcyjne. Takie enkodery to moja codzienność - muszę przecież jakość odmierzać pozycję.
m.

Widzę wątek się fajnie rozrósł, jest gotowa biblioteka.
W międzyczasie udało mi podłączyć zarówno enkoder optyczny jak i mechaniczny.
Niestety na testy optycznego nie miałem pomysłów, mam jedynie ogólne wrażenie: kręci się i to szybko:)
Wrzuciłem więc mechaniczny i nie udało mi się programu wyprowadzić z równowagi, przy standardowym kręceniu paranoika
Jest zasadne, że kod powinien nadać się do standardowych rozwiązań jako manipulator i powinienem spróbować go zaadoptować u siebie, ale nie wiadomo kiedy bo mirkowe kody w moich programach póki co działają.
Jeśli jednak podejmę się zadania to prawie na pewno obuduję i tę bibliotekę w callbacki i zdarzenia.
Dzięki jeszcze raz za podzielenie się biblioteką.

Jeśli można chciałbym zaprezentować drobną modyfikację (w ramach zabawy z kodem).
Modyfikacja ta pozwoli nam definiować dowolne, piny z różnych portów.
Sercem będzie makro i definicje portów oraz pinów:


Żeby całość działało tak jak w oryginale, należy zmodyfikować funkcję "encoder_port":


Do tego stworzymy funkcję dodatkową:


i podmieniamy za makro ENC_IN w pliku encoder_SK.c
No i cieszymy się zwiększoną funkcjonalnością.

Taka moja drobna poprawka zupełnie kosmetyczna. Wydaje mi się, że lepszy dla szybkiej identyfikacji znaczenia będzie zapis zamiast

np. taki


I jeszcze pytanko

Pomijając jak zostanie zoptymalizowany zapis temp |= (1<<1);
czemuś szczególnemu ma służyć? Linijkę wcześniej jest temp = 0x01; a dalej przesunięcie bitowe stałej o wartości 0x01 o jeden bit w lewo.
Pytam bo chciałbym wiedzieć o powodach zastosowania dwóch różnych zapisów.

Cieszę się, że jest zainteresowanie biblioteką, którą opublikowałem jako inspirację do dalsazych prób i modyfikacji. Mam jednak uwagę co do zamiany makra ENC_IN - właśnie to makro wskazane by było aby zajmowało jak najmniej czasu. Te kilka dodatkowych if'ów w przeróbce zajmuje sporo miejsca jak by nie patrzył. Fajnie by było jakby odpowiednimi definicjami już na etapie preprocesora udało się załatwić wygodniejszee przypisy do pinów wybranego portu oraz stałych STANx. To by było chyba najekonomiczniejsze rozwiązanie jeśli chodzi o szybkość wykonywania funkcji. Moje definicje może nie są jakieś wyszukane, ale w sumie można się połapać choć nie ukrywam, że właśnie liczyłem na kogoś kto to zmodyfikuje, bo moja wiedza na tym etapie jest nieco skromna

_________________
http://www.sylwekkuna.com

Moja wiedza też niestety skromna.
Widzę jedynie potencjał takiej modyfikacji przy pracy nad nowymi projektami, gdzie szukamy dopiero właściwej pinologii.
Ja często "żongluję" pinami jeśli pracuję koncepcyjnie, szczególnie wtedy, gdy szukam rozwiązań lub gdy przygotowuję bibliotekę np na kilka procków. Zaproponowane makra pozwalają na pewną swobodę, niestety kosztem szybkości, choć uważam, że w standardowych projektach nie będzie z tym problemu, a wygoda doboru pinów ma swoją wartość.
Wracając do szybkości, założyłem, że funkcja typu "static inline" dołoży trochę do szybkości.
Zmienną temp można wspomóc przedrostkiem "register", co powinno dać dodatkowy wzrost prędkości, ale te modyfikacje mogą zależeć silnie od opcji kompilacji.

Podoba mi się



Tu nie chodzi o przesunięcie bitowe, same w sobie, ale o wykrycie stanów wysokich na pinach.
Pierwszy zapis ustawi bit 0, a drugi bit 1.
Jest to standardowy sposób na ustawianie pojedynczych bitów, jak zauważył SylwekK może mieć wpływ na szybkość w wymagających zadaniach.

Ok ale dlaczego w takim razie nie

Dlatego, że na tym forum każdy docenia przejrzysty zapis z przesunięciami bitowymi, który jest po stokroć bardziej przejrzysty niż wpisywanie wartości HEX ...

dla ciebie nie ma różnicy pomiędzy np takimi dwoma zapisami ?



? jak nie widzisz różnicy to postaraj się zrozumieć co oznacza "dobry styl programowania" ponieważ te dwa zapisy NICZYM się nie różnią z punktu widzenia kompilatora a tym bardziej procesora. Za to ten drugi sposób JEST PASKUDNY jeśli chodzi o widoczność, które bity macamy.

_________________
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 ]

To dlaczego dwie linijki wyżej jest temp = 0x01 zamiast temp = (1 << 0)?

Pokazałem, który zapis jest czytelniejszy i napisałem dlaczego - a nie żeby się przyczepiać co jest dwie linijki wyżej a co niżej.

_________________
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 ]

No cóż, programowanie to taka sztuka, gdzie każde z zadań ma wiele rozwiązań.
Co zostanie wybrane to zależy od umiejętności programisty, jego predyspozycji, uzyskanej wiedzy a czasami, po prostu, pewnych preferencji zależnych od kontekstu, a zwykle po prostu jego "widzimusię"

Powyższe zadanie miało na celu ustawienie dwóch najmniej znaczących bitów w bajcie.
Założyłem, że zacznę od ustawiania bitu na pozycji 0 (jeśli będzie potrzeba - warunek "if").
Ten kto już liznął zapisu hexadecymalnego to łatwiej mu wpisać "temp = 0x01". Mając pewną wprawę w programowaniu taki zapis jest dość czytelny.
Drugi wpis miał zmanipulować bitem na pozycji 1, nie naruszając żadnego innego bitu.
W dwóch linijkach mamy dwie formy zapisu, pierwsza będzie szybsza, bo mamy tylko przypisanie, druga będzie nieco wolniejsza, bo oprócz przypisania jest też przesunięcie. Różnice w szybkości dla tego zadania nie są jakieś kolosalne, ale warto o nich pamiętać.
Nie ma żadnych przeciwwskazań żeby zapisać całość tak:


ale dla mnie czytelniej było to co wcześniej, choć na pewno nie powiem, że lepiej.

to:



będzie wolniejsze niż to?



Jeśli kolega tak sądzi to proponuję jednak zrobić proste ćwiczenie jak DRUT, czyli skompilować i zajrzeć do kodu ASM w pliku *.lss

No i zastanowić się dobrze ... bo tu nawet nie ma ŻADNEJ wątpliwości, że obydwa zapisy dla kompilatora są ABSOLUTNIE JEDNOZNACZNE, proponuję też przypomnieć sobie co to są tzw "stałe dosłowne"

NIGDY W ŻYCIU procesor nie będzie tu wykonywał ŻADNEGO przesunięcia bitowego panie kochany obydwa zapisy



to są STAŁE DOSŁOWNE czy ty tego nie widzisz ? powiem więcej, takie zapisy jak niżej



to też będzie TO SAMO - czyli ta sama stała dosłowna Toż kompilator zamieni to na bajt o wartości = 2 i taka wartość trafi do rejestru aby brać udział w operacji przypisania do zmiennej

no myślę, że takie PODSTAWY to jednak warto dobrze rozumieć.

To co piszę nie ma już nawet nic wspólnego czy używać przesunięć czy wartości HEX. Bo tak jak piszesz czasem w tak prostym przypadku gdzie mamy albo 0x01 albo 0x02 to nie stanowi dużego problemu

_________________
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 ]

No cóż biję się w pierś, to były braki w wiedzy, ale po to ciągnie się wątki, żeby sobie ją uporządkować
Sprawdziłem i faktycznie tak jest, także dzięki, lekcję o stałej dosłownej na pewno zapamiętam

Dokładnie o to chodzi ... dlatego czasem staram się włączyć do dyskusji ...

_________________
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 ]

Przesunięcia bitowe doszły by wtedy gdyby zostały zastosowane jakieś zmienne a nie stałe

Sent from my Mi-4c using Tapatalk

Ooo tego nie umiałem sformułować w komentarzu, choć podskórnie wiedziałem o tym

Żeby już postawić kropkę nad obsługą różnych typów enkoderów dodaję jeszcze ciut rozbudowaną wersję biblioteki obsługującą 4 impulsy czyli innymi słowy każdą zmianę stanu enkodera (nie tylko na "klik"). Gdzie to się może przydać? Przede wszystkim tam gdzie enkoder nie robi "kilik", tj. enkodery optyczne lub magnetyczne gdzie ich ruch jest płynny. Pozwala to znacznie zwiększyć ich rozdzielczość. Przykładowo moje enkodery magnetyczne RMS20-250, które z założenia mają 250 impulsów... ale pełnych czyli od 00 do 00 (lub 11 do 11 ) teraz uzyskują 1000 impulsów na obrót Oczywiście drgania styków nie straszne, bo akceptowane są tylko stany sąsiednie enkodera, a podczas drgań następuje i wzajemna kompensacja impulsów nadmiarowych.

Aha, i o ile przy przerwaniach 10kHz robiłem kołowrotek z enkodera to zdarzyło mu się coś zgubić, natomiast po zwiększeniu próbkowania do 50kHz mało palców nie połamałem przy kręceniu, a pozycja startowa za każdym razem była ta sama, z której zaczynałem

_________________
http://www.sylwekkuna.com

Wg mnie jeszcze nie można postawić kropki Już tłumaczę dlaczego.
Brakuje tutaj jeszcze, żeby dopełnić obsługę enkodera, technik zdarzeniowych i funkcji zwrotnych
Pewnie niektórzy złapią się za głowę, po co taką "kobyłę" stosować do "prościutkiej" biblioteki, ale wg mnie po to, żeby nieskomplikowany kod nie komplikował tych bardziej skomplikowanych. Oprócz tego Mirek wielokrotnie udowadniał w poradnikach, że zdarzenia i callbacki znacznie upraszczają kod i powoli ta myśl mnie ukierunkowuje.
Dodatkowo myślę, że należy iść tą drogą już nawet na początku programowania, bo na końcu to taki must have.

Sam jeszcze tego tematu całkowicie nie ogarniam, ale wszystko wskazuje na to, że udało mi się zastosować obsługę mirkowych rozwiązań do niniejszej biblioteki. Mam nadzieję też, że ten przykład ukierunkuje innych.
Załączam bibliotekę, a zmiany to:
- pozostaję przy modyfikacji definicji dowolnych pinów procesora (bo tak )

- włączenie techniki zdarzeniowej i calbacków, dzięki temu kod jest przejrzysty oraz dodatkowo wyświetlacz nie jest męczony w pętli głównej (efekt uboczny, ale pożądany )
Może tego nie widać na LCD, ale u mnie na VFD strasznie to migało. Oczywiście to tylko kod przykładowy był u Sylwka, ale warto zwrócić na to uwagę.

- włączenie/wyłączenie obsługi timera przez użytkownika i korzystanie bez dodatkowych zabiegów z pollingu.
Nie zawsze można skorzystać z timera, a w wielu projektach obsługa enkodera nie musi być krytyczna. Jeśli coś się zgubi to niewielka strata.

- przeniesienie inicjalizacji timera do funkcji inicjującej enkodera. Przy okazji zmieniłem na:
void encoder_init(void); To jeszcze bardziej uprościło funkcję main.






Na zakończenie jeszcze uproszczony plik main.c:




PS
"prościutkiej" biblioteka - to taki mój skrót myślowy.
Sam jestem pod wrażeniem kodu Sylwka, bo obsługa jest naprawdę przemyślana, a brak konieczności używania jakichkolwiek filtrów na piny enkodera to jest ta najważniejsza miodność tego rozwiązania