ATNEL tech-forum
https://forum.atnel.pl/

Impulsator enkoder - kolejna odsłona
https://forum.atnel.pl/topic18208.html
Strona 1 z 2

Autor:  SylwekK [ 20 kwi 2017, o 20:11 ]
Tytuł:  Impulsator enkoder - kolejna odsłona

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:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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 :lol: ) 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ć ;)
Załącznik:
impulsator.zip

Autor:  Zealota [ 21 kwi 2017, o 10:15 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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... :)

Autor:  SylwekK [ 21 kwi 2017, o 10:40 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Autor:  Zealota [ 21 kwi 2017, o 10:50 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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.

Autor:  SylwekK [ 21 kwi 2017, o 14:07 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Zealota napisał(a):
Mam w domu enkoder optyczny 360 impulsów na obrót (pogróżka :) ), będę zatem bezlitosny :)


Świetnie. Na to liczę :mrgreen:

Autor:  SylwekK [ 22 kwi 2017, o 15:43 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Autor:  tungu [ 22 kwi 2017, o 16:23 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Autor:  SylwekK [ 22 kwi 2017, o 18:15 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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 :)

Autor:  Daro69 [ 22 kwi 2017, o 18:34 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Witaj SylwekK,
SylwekK napisał(a):
Widzę, że wsad parę razy pobrany... Naprawdę nikt jeszcze nie przetestował tej próbki? :(

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) :lol:
sprawdziłem też w powolnym tempie,
zauważyłem że pojawia się sporadycznie kierunek przeciwny(czyli zakłócenia z mojego enkodera), :P
kurcze, pomimo tego oszukaństwa licznik nie zgubił się. :D
i o wyskalowaniu graficznym widzę pomyślałeś. :) działa fajnie ! ;)
pozdrawiam Darek P.

Autor:  SylwekK [ 22 kwi 2017, o 19:10 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


@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 :)

Autor:  Daro69 [ 22 kwi 2017, o 19:34 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Autor:  SylwekK [ 22 kwi 2017, o 19:41 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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.

Autor:  tungu [ 23 kwi 2017, o 09:50 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Autor:  Zealota [ 25 kwi 2017, o 22:12 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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ą.

Autor:  Zealota [ 25 kwi 2017, o 23:36 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


Żeby całość działało tak jak w oryginale, należy zmodyfikować funkcję "encoder_port":
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


Do tego stworzymy funkcję dodatkową:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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

Autor:  riddik [ 26 kwi 2017, o 07:23 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Taka moja drobna poprawka zupełnie kosmetyczna. Wydaje mi się, że lepszy dla szybkiej identyfikacji znaczenia będzie zapis zamiast
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

np. taki
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


I jeszcze pytanko
Zealota napisał(a):
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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.

Autor:  SylwekK [ 26 kwi 2017, o 07:47 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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 :-)

Autor:  Zealota [ 26 kwi 2017, o 12:32 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

SylwekK napisał(a):
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 :-)


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.
riddik napisał(a):
Taka moja drobna poprawka zupełnie kosmetyczna. Wydaje mi się, że lepszy dla szybkiej identyfikacji znaczenia będzie zapis zamiast

Podoba mi się :)

riddik napisał(a):
Zealota napisał(a):
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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.


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.

Autor:  riddik [ 26 kwi 2017, o 13:47 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Ok ale dlaczego w takim razie nie
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

Autor:  mirekk36 [ 26 kwi 2017, o 13:54 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

riddik napisał(a):
temp |= 0x02;

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 ?

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


? 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.

Autor:  riddik [ 27 kwi 2017, o 07:58 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Autor:  mirekk36 [ 27 kwi 2017, o 08:06 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

riddik napisał(a):
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.

Autor:  Zealota [ 27 kwi 2017, o 09:03 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

riddik napisał(a):
To dlaczego dwie linijki wyżej jest temp = 0x01 zamiast temp = (1 << 0)?

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:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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

Autor:  mirekk36 [ 27 kwi 2017, o 09:15 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Zealota napisał(a):
druga będzie nieco wolniejsza, bo oprócz przypisania jest też przesunięcie


to:

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


będzie wolniejsze niż to?

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


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

Kod:
0x02
(1<<1)


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

Kod:
0b00000010
2
0x02
1<<1


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

Autor:  Zealota [ 27 kwi 2017, o 09:49 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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 :)

Autor:  mirekk36 [ 27 kwi 2017, o 09:57 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Zealota napisał(a):
ale po to ciągnie się wątki, żeby sobie ją uporządkować

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

Autor:  micky [ 27 kwi 2017, o 10:42 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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

Sent from my Mi-4c using Tapatalk

Autor:  Zealota [ 27 kwi 2017, o 11:39 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

micky napisał(a):
Przesunięcia bitowe doszły by wtedy gdyby zostały zastosowane jakieś zmienne a nie stałe :)


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

Autor:  SylwekK [ 28 kwi 2017, o 01:58 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

Ż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 8-)

Autor:  Zealota [ 30 kwi 2017, o 22:26 ]
Tytuł:  Re: Impulsator enkoder - kolejna odsłona

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.


Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


Na zakończenie jeszcze uproszczony plik main.c:

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.



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 :)

Strona 1 z 2 Strefa czasowa: UTC + 1
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/