ATNEL tech-forum

Re: Impulsator enkoder - kolejna odsłona

2017-05-01T20:24:37+01:00

Zealota napisał(a):

Jeśli wskaźnik do funkcji jest różny od zera to funkcja się wykona, w przeciwnym wypadku się nie wykona.
Można by to wykorzystać do "wyrejestrowania" funkcji, ale nie mam pewności czy tu nie ma jakichś zagrożeń..

Tak sobie myślę, może się mylę, ale myślę ... ... że wyrejestrowanie nie miałoby tu hmmm jakby sensu - dlaczego?

no bo skoro zero to właśnie callback jest wyrejestrowany - nie ma innej możliwości - tak tylko podpowiadam może to pozwoli nieco poszerzyć obraz tych callbacków

Warunek jest po to, że nawet jeśli ktoś użyje tej funkcji nazywanej zdarzeniem w pętli while, a nieopatrznie np przez zapomnienie nie zarejestruje callbacka - to właśnie ma się to zachować bezpiecznie czyli nic ma się nie wykonać. A jak już zarejestruje to funkcja prawidłowo się wykona

------------------------ [ Dodano po: 5 minutach ]

Zealota napisał(a):

Nie widzę natomiast problemu w zdefiniowaniu kilku funkcji reagujących na enkoder i w zależności od kontekstu rejestrowanie tej właściwej.
Do tego pewnie należałoby znowu skorzystać z mechanizmu zdarzeń, który by właściwe funkcje rejestrował lub wyrejestrowywał.

Dokładnie to jest fajną zaletą callbacków, że można rejestrować różne funkcje w różnych miejscach programu. To nie tylko ma sens ale jest wręcz chyba najbardziej miodną możliwością że aż tak to określę.

Ale czy myśleć o mechanizmie to rejestracji/wyrejestrowania ? hmmm oczywiście może czegoś nie rozumiem w tym stwierdzeniu - ale prosta funkcja rejestracji wystarcza w zupełności.

Zwykle pierwszy raz rejestrujesz przed pętlą główną w main ... prawda?

Później skoczysz np do jakiegoś MENU - tam pewnie też będzie jakaś pętla główna, wystarczy zarejestrować nowego callbacka (nie trzeba nic wyrejestrowywać przecież bo podmieniasz wskaźnik na nowy i już)

Po wyjściu z pętli funkcji MENU rejestrujesz to co było wcześniej ...

a jeśli masz jeszcze więcej, dużo więcej takich sytuacji w sofcie i trzeba często rejestrować callbacka i przywracać różne poprzednie jego wartości to warto wtedy np pomyśleć o tablicy wskaźników do funkcji callbackowych, zapamiętywać je przed zmianą - zaś po wyjściu z jakiejś pętli przywracać poprzednio zapamiętaną

no możliwości jest sporo

Statystyki: Napisane przez mirekk36 — 1 maja 2017, o 20:24

Re: Impulsator enkoder - kolejna odsłona

2017-05-01T14:34:12+01:00

quartus napisał(a):

Do rozważenia:
1. Jest register. Czy jest (powinien być) unregister?

Wszystko pewnie zależy od aplikacji. W obsłudze zdarzenia jest warunek:
[syntax=c]if( enc_event_callback )
enc_event_callback();[/syntax]
Jeśli wskaźnik do funkcji jest różny od zera to funkcja się wykona, w przeciwnym wypadku się nie wykona.
Można by to wykorzystać do "wyrejestrowania" funkcji, ale nie mam pewności czy tu nie ma jakichś zagrożeń..
Czy to byłoby potrzebne? Ciężko powiedzieć

quartus napisał(a):

2. Ile razy zamierzasz rejestrować/wyrejestrowywać zdarzenie dla enkodera?

Domyślnie, jak w przykładzie, rejestracja nastąpiła przed funkcją main, więc w tym przypadku raz.
Nie widzę natomiast problemu w zdefiniowaniu kilku funkcji reagujących na enkoder i w zależności od kontekstu rejestrowanie tej właściwej.
Do tego pewnie należałoby znowu skorzystać z mechanizmu zdarzeń, który by właściwe funkcje rejestrował lub wyrejestrowywał.

quartus napisał(a):

3. Czy tylko 1 rodzaj zdarzenia? Np. inc/dec o "1 działkę" czy może także przeskok w jednostce czasu o kilka działek?

Tutaj już można pewnie ostro zamieszać jeśli będzie potrzeba.

quartus napisał(a):

4. Czy do funkcji callback nie powinien trafiać argument? Np. inc/dec, może wartość licznika?

Można tak zrobić, ale w tym wypadku nie był potrzebny, bo funkcja bazuje na funkcji enc_get().

Jak pisałem, póki co, zdarzenia i callbacki są dla mnie tajemnicą więc ciężko powiedzieć czy trafiłem z odpowiedziami
Mam nadzieje, że jakiś bardziej obeznany programista uściśli moje wypowiedzi.

Statystyki: Napisane przez Zealota — 1 maja 2017, o 14:34

Re: Impulsator enkoder - kolejna odsłona

2017-04-30T22:26:53+01:00

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.

[syntax=c]/******************* USTAWIENIA UŻYTKOWNIKA ***************************************/
#define USE_TIMER0// 0 jeśli tryb polling, 1 używamy dla timer2
#define ENC_TYPE 0// typ enkodera: 0-pełnokrokowy, 1-półkrokowy, 2-czterokrokowy

#define ENCA_PORTPORTA
#define ENCA_PIN0

#define ENCB_PORTPORTA
#define ENCB_PIN2
/*********************************************************************************/[/syntax]

[syntax=c]/********** Kod dotyczący funkcji zwrotnych ****************/
static void ( *enc_event_callback )(void);
void register_enc_event_callback(void (*callback)(void)) {
enc_event_callback = callback;
}
/***********************************************************/[/syntax]

Na zakończenie jeszcze uproszczony plik main.c:

[syntax=c]/*
* Immpulsator obrotowy
*
* SylwekK
* 15-04-2017
*
* ATMEGA32 16Mhz kwarc
*/

#include
#include
#include "libs/LCD/lcd44780.h"
#include "libs/encoder_SK/encoder_SK.h"

//*******************************************************************************
uint8_t p0[] = { 16, 16, 16, 16, 16, 16, 16, 16 };
uint8_t p1[] = { 24, 24, 24, 24, 24, 24, 24, 24 };
uint8_t p2[] = { 28, 28, 28, 28, 28, 28, 28, 28 };
uint8_t p3[] = { 30, 30, 30, 30, 30, 30, 30, 30 };

uint8_t p[] = {0x20, 0x80, 0x81, 0x82, 0x83};

uint16_t odczyt = 0;

void plus_minus(void);
void pasek (uint8_t poz_y, uint8_t poz_x, uint8_t k);
//*******************************************************************************

int main(void) {
//definicje znaków dla paska
lcd_init();
lcd_locate(0,0); lcd_str("0");
lcd_defchar(0x80, p0);
lcd_defchar(0x81, p1);
lcd_defchar(0x82, p2);
lcd_defchar(0x83, p3);
//-------------------------------------------------------------------------------
encoder_init(); //ustawienie wejść enkodera
encoder_reset();

/********* Rejestrujemy funkcje zwrotną *************/
register_enc_event_callback( plus_minus );
/****************************************************/

sei();
while(1) {
SW_ENCODER_EVENT();
}//END while
}// END main

/****************************** Ciała funkcji ***********************************/
void pasek (uint8_t poz_y, uint8_t poz_x, uint8_t k) {
uint8_t xp1, xp2;

xp1=k/5; xp2=k%5;//wyliczenie podziału
lcd_locate(poz_y, poz_x);
uint8_t a=0; while(a++lcd_char(p[xp2]);//przypisanie pionowego paska

while(xp1++<20) lcd_str(" ");//dla LCD buforowanego można pominąć tą linię
}
/******************** Funkcja reagująca na zmiany enkodera **********************/
void plus_minus(void) {
odczyt += enc_get();
lcd_locate(0,0); lcd_int(odczyt); lcd_str(" ");
pasek(1, 0, (odczyt&255)/3); //dopasowanie wartości na całą skalę (16x5=80 punktów, 255/80=3.1)
}
/********************************************************************************/[/syntax]

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

Statystyki: Napisane przez Zealota — 30 kwi 2017, o 22:26

Re: Impulsator enkoder - kolejna odsłona

2017-05-06T11:28:19+01:00

Ż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

Statystyki: Napisane przez SylwekK — 28 kwi 2017, o 01:58

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T11:39:56+01:00

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

Statystyki: Napisane przez Zealota — 27 kwi 2017, o 11:39

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T10:42:11+01:00

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

Sent from my Mi-4c using Tapatalk

Statystyki: Napisane przez micky — 27 kwi 2017, o 10:42

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T09:57:16+01:00

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

Statystyki: Napisane przez mirekk36 — 27 kwi 2017, o 09:57

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T09:49:48+01:00

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

Statystyki: Napisane przez Zealota — 27 kwi 2017, o 09:49

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T09:15:12+01:00

Zealota napisał(a):

druga będzie nieco wolniejsza, bo oprócz przypisania jest też przesunięcie

to:

[syntax=c]temp |= (1<<1);[/syntax]

będzie wolniejsze niż to?

[syntax=c]temp |=0x02;[/syntax]

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

Code:

0x02
(1<<1)

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

Code:

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

Statystyki: Napisane przez mirekk36 — 27 kwi 2017, o 09:15

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T09:03:58+01:00

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:
[syntax=c]uint8_t static inline enc_in( void ) {
uint8_t temp=0;
if ( PINN(ENC_PORTA)&(1< temp = 0x01;
if ( PINN(ENC_PORTB)&(1< temp |=0x02;
return temp;
}[/syntax]

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

Statystyki: Napisane przez Zealota — 27 kwi 2017, o 09:03

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T08:06:13+01:00

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.

Statystyki: Napisane przez mirekk36 — 27 kwi 2017, o 08:06

Re: Impulsator enkoder - kolejna odsłona

2017-04-27T07:58:09+01:00

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

Statystyki: Napisane przez riddik — 27 kwi 2017, o 07:58

Re: Impulsator enkoder - kolejna odsłona

2017-04-26T13:54:16+01:00

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 ?

[syntax=c]temp |= (1<<6)|(1<<3)|(1<<1);

tem |= 0x4A;[/syntax]

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

Statystyki: Napisane przez mirekk36 — 26 kwi 2017, o 13:54

Re: Impulsator enkoder - kolejna odsłona

2017-04-26T13:47:01+01:00

Ok ale dlaczego w takim razie nie
[syntax=c]temp |= 0x02;[/syntax]

Statystyki: Napisane przez riddik — 26 kwi 2017, o 13:47

Re: Impulsator enkoder - kolejna odsłona

2017-04-26T12:32:12+01:00

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

[syntax=c]uint8_t static inline enc_in( void ) {
uint8_t temp=0;
if ( PINN(ENC_PORTA)&(1<temp = 0x01;
if ( PINN(ENC_PORTB)&(1<temp |= (1<<1);
return temp;
}[/syntax]

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.

Statystyki: Napisane przez Zealota — 26 kwi 2017, o 12:32

Re: Impulsator enkoder - kolejna odsłona

2017-04-26T07:47:32+01:00

Statystyki: Napisane przez SylwekK — 26 kwi 2017, o 07:47

Re: Impulsator enkoder - kolejna odsłona

2017-04-26T07:23:25+01:00

Taka moja drobna poprawka zupełnie kosmetyczna. Wydaje mi się, że lepszy dla szybkiej identyfikacji znaczenia będzie zapis zamiast
[syntax=c]#define ENC_PORTA PORTA
#define ENC_PORTB PORTA

#define ENC_PINA 0
#define ENC_PINB 2[/syntax]
np. taki
[syntax=c]#define ENCA_PORT PORTA
#define ENCB_PORT PORTA

#define ENCA_PIN 0
#define ENCB_PIN 2[/syntax]

I jeszcze pytanko

Zealota napisał(a):

[syntax=c]uint8_t static inline enc_in( void ) {
uint8_t temp=0;
if ( PINN(ENC_PORTA)&(1<temp = 0x01;
if ( PINN(ENC_PORTB)&(1<temp |= (1<<1);
return temp;
}[/syntax]

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.

Statystyki: Napisane przez riddik — 26 kwi 2017, o 07:23

Re: Impulsator enkoder - kolejna odsłona

2017-04-25T23:36:26+01:00

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:
[syntax=c]#define DDRR(x)(*(&x-1))
#define PINN(x)(*(&x-2))

#define ENC_PORTAPORTA
#define ENC_PORTBPORTA

#define ENC_PINA0
#defineENC_PINB2[/syntax]

Żeby całość działało tak jak w oryginale, należy zmodyfikować funkcję "encoder_port":
[syntax=c]void encoder_port(void)//ustawienie wejść enkodera
{
DDRR(ENC_PORTA) &= ~(1<ENC_PORTA |= (1<DDRR(ENC_PORTB) &= ~(1<ENC_PORTB |= (1<}[/syntax]

Do tego stworzymy funkcję dodatkową:
[syntax=c]uint8_t static inline enc_in( void ) {
uint8_t temp=0;
if ( PINN(ENC_PORTA)&(1<temp = 0x01;
if ( PINN(ENC_PORTB)&(1<temp |= (1<<1);
return temp;
}[/syntax]

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

Statystyki: Napisane przez Zealota — 25 kwi 2017, o 23:36

Re: Impulsator enkoder - kolejna odsłona

2017-04-25T22:12:34+01:00

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

Statystyki: Napisane przez Zealota — 25 kwi 2017, o 22:12

Re: Impulsator enkoder - kolejna odsłona

2017-04-23T09:50:04+01:00

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

Statystyki: Napisane przez tungu — 23 kwi 2017, o 09:50

Re: Impulsator enkoder - kolejna odsłona

2017-04-23T17:35:17+01:00

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:
[syntax=c]while(1)
{
encoder();
odczyt += enc_get();
lcd_locate(0,0); lcd_int(odczyt); lcd_str(" ");
//
// coś tam dalej byle nie blokowało pętli
//
}[/syntax]

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.

Statystyki: Napisane przez SylwekK — 22 kwi 2017, o 19:41

Re: Impulsator enkoder - kolejna odsłona

2017-04-22T19:34:17+01:00

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.

Statystyki: Napisane przez Daro69 — 22 kwi 2017, o 19:34

Re: Impulsator enkoder - kolejna odsłona

2017-05-06T11:05:54+01:00

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

[syntax=c]/*
* Immpulsator obrotowy
*
* SylwekK
* 15-04-2017
*
* ATMEGA32 16Mhz kwarc
*/

#include
#include
#include "LCD/lcd44780.h"
#include "encoder_SK/encoder_SK.h"

//*******************************************************************************
//*******************************************************************************

uint8_t p0[] = { 16, 16, 16, 16, 16, 16, 16, 16 };
uint8_t p1[] = { 24, 24, 24, 24, 24, 24, 24, 24 };
uint8_t p2[] = { 28, 28, 28, 28, 28, 28, 28, 28 };
uint8_t p3[] = { 30, 30, 30, 30, 30, 30, 30, 30 };

uint8_t p[] = {0x20, 0x80, 0x81, 0x82, 0x83};

void pasek (uint8_t poz_y, uint8_t poz_x, uint8_t k)
{
uint8_t xp1, xp2;

xp1=k/5; xp2=k%5; //wyliczenie podziału
lcd_locate(poz_y, poz_x);
uint8_t a=0; while(a++ lcd_char(p[xp2]); //przypisanie pionowego paska

while(xp1++<16) lcd_str(" "); //dla LCD buforowanego można pominąć tą linię
}
//*******************************************************************************
//*******************************************************************************

int main(void)
{
//taktowanie 16Mhz ATMEGA32
//------------------------------------------
//ustawienie TIMER2 w tryb CTC
TCCR2 |= (1< TCCR2 |= (1< OCR2 = 24; // przerwanie porównania co 100us (10kHz) (24=25-1)
TIMSK |= (1< //-------------------------------------------------------------------------------
//-------------------------------------------------------------------------------
//definicje znaków dla paska
lcd_init();
lcd_defchar(0x80, p0);
lcd_defchar(0x81, p1);
lcd_defchar(0x82, p2);
lcd_defchar(0x83, p3);
//-------------------------------------------------------------------------------

encoder_port();//ustawienie wejść enkodera
uint16_t odczyt=0;
encoder_reset();

sei();
while(1)
{
odczyt += enc_get();

lcd_locate(0,0); lcd_int(odczyt); lcd_str(" ");
pasek(1, 0, (odczyt&255)/3); //dopasowanie wartości na całą skalę (16x5=80 punktów, 255/80=3.1)

}//END while
}// END main
//*******************************************************************************

ISR(TIMER2_COMP_vect)
{
encoder();

}

//*******************************************************************************
//*******************************************************************************[/syntax]

@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

Statystyki: Napisane przez SylwekK — 22 kwi 2017, o 19:10

Re: Impulsator enkoder - kolejna odsłona

2017-04-22T18:34:31+01:00

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

Statystyki: Napisane przez Daro69 — 22 kwi 2017, o 18:34

Re: Impulsator enkoder - kolejna odsłona

2017-04-22T18:15:31+01:00

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

Statystyki: Napisane przez SylwekK — 22 kwi 2017, o 18:15