DRO DIY

[upanie]

W tym systemie można użyć max dwóch kanałów bo tyle przerwań zewnętrznych obsługuje NANO I UNO.

Rzuciłem bardzo pobieżnie okiem na ten kod i wygląda na to, że koleś też nie korzysta z przerwań zewnętrznych a korzysta z przerwań timera, na którego to handlerze odczytuje stan wejść. Słabe to ale i tak lepsze niż strikexp-a. Jeśli faktycznie tak to działa to może więcej wejść obsłużyć. No ale to to tylko szybki rzut okiem i może źle piszę.

[logopeda]

Kol.Yogi napisał:
"W tym systemie można użyć max dwóch kanałów bo tyle przerwań zewnętrznych obsługuje NANO I UNO."
Pewnie durne pytanie za co z góry przepraszam - ale rozumiem, że w takim układzie "tacho" czyli sygnał z indexu enkodera jako trzeci (który notabene też fajnie działa) nie musi korzystać już z przerwań ze względu na "niską częstotliwość"?

Kol.upanie napisał
"Słabe to ale i tak lepsze niż strikexp-a."
no to się nacieszyłem HEIDENHAIN-em dla ubogich

[piotr56]

Witam
Tak się zastanawiam nad podobno niskimi prędkościami...
Procesor jest najtańszym elementem całości, można spokojnie użyć osobnego procesora dla każdej z osi, a o ile mi wiadomo na Atmedze z zegarem 16MHz spokojnie można liczyć do kilku MHz, na jaką szybkość się to przełoży?
Jak komuś mało to są inne tanie płytki ( ESP07 dla przykladu ) napędzane zegarami 26-52 MHz i z arytmetyką 32 bitową.
Wyświetlacz wcale nie musi zżerać mocy procesora, widziałem kiedyś autonomiczne wyświetlacze na Attiny15 ( 85 ) którym wrzuca się dane do wyświetlania po serialu w formacie tekstowym bez obróbki, a Attiny zajmuje się nad rozdzieleniem tego na segmenty.
Koszty całości elektroniki i tak będą pomijalnie małe w stosunku do enkoderów.
Pozdrawiam

[strikexp]

Kiedyś robiłem test, jak szybko Arduino potrafi zliczać 2 bitowy kod graya. Miałem generator wzorcowy i Arduino które tylko liczyło i wysyłało poprzez sprzętowy UART.
Nie pamiętam wyniku ale było to około 70k lub 150k kroków na sekundę. Jak wspominałem impulsy enkodera należy mnożyć przez 4 aby uzyskać kroki/rozdzielczość.

Ale to był najprostrzy układ zliczający, w DRO jest jeszcze kontrola luzu nakrętki i zamiana liczby dwójkowej na wartości dziesiętne wyświetlacza.
Nie wiem na ile ten sterownik wyświetlacza będzie automatyczny, ale na pewno zmniejszy nieporównywalnie obciążenie.

[upanie]

strikexp dlaczego boisz się przerwań.
Zrób użytek z przerwania od pinu. Możesz sobie ustawić zbocze, na które chcesz mieć wygenerowane przerwanie. W przerwaniu NIE RÓB NICZEGO POZA ZLICZANIEM impulsów. Funkcja obsługująca przerwanie ma się wykonywać tak krótko jak to tylko możliwe.
Całą resztę rób sobie jak chcesz. Resztę czyli przeliczanie zliczonych impulsów na milimetry, wyświetlenie ich na wyświetlaczu itp.
Obsługę przycisków również zrób na przerwaniu bo po co inaczej?
Jeśli tak zrobisz to każde tyknięcie enkodera zostanie obsłużone. No oczywiście do granic możliwości sprzętu i softu. Ale będzie duuuuużo lepiej niż masz teraz. A wszystko dzięki temu, że przerwanie przerwie Ci np. wyświetlanie, które jest mniej ważne od zliczenia impulsów. Po obsłużeniu przerwania wrócisz do obsługi wyświetlacza i dokończysz wyświetlanie.
Dzięki temu bez względu na to jaki wyświetlacz masz podłączony to nigdy nie zgubisz impulsów od enkodera.

[strikexp]

strikexp dlaczego boisz się przerwań.
(...)
Dzięki temu bez względu na to jaki wyświetlacz masz podłączony to nigdy nie zgubisz impulsów od enkodera.

Przerwania są genialne, ale to nie jest rozwiązanie każdego problemu. Do przycisku mógłbym je użyć (a może tak zrobiłem?), ale nie ma potrzeby gdy stan pinu może być sprawdzany kilka razy na sekundę.

Natomiast Ty nie rozumiesz że każde przerwanie ma priorytet, a do określania pozycji enkodera musi być zachowana kolejność. Z tego co pamiętam z 8051 to przerwania powodują umieszczanie adresów powrotów na odpowiedniej liście w pamięci RAM. Jak przegniesz z niezakończonymi przerwaniami to zaliczysz kolizję danych itp krzaczki.

[wedlock]

Trafiają na stos. Zapacha się on tylko wtedy gdy nie obsłużysz przerwania. Nie jesteś w stanie zapchac stosu podczas normalnego działania programu. Musiał byś się o to postarać. Po obsłudze przerwania adres jest zdejmowany ze stosu FIFO. First in first out

[upanie]

Gościu proszę Cię nie mów mi czego nie rozumiem bo nijak się z tym nie zdradziłem.
I uwierz mi, że rozumiem co to są priorytety przerwań bo od 17-tu lat zarabiam na życie programując m.in. mikrokontrolery.

Przycisk możesz sobie sprawdzać co jakiś czas bo człowiek to jest bardzo powolne stworzenie dla mikrokontrolera. Tylko uzasadnij po co masz zwiększać obciążenie procka pollingiem skoro po to producent procka wsadził tam przerwania.
A co do enkodera to sprawdzanie pollingiem stanu jego "nóg" to już jakiś żart a konkretnie idiotyzm połączony z amatorką.

Natomiast Ty nie rozumiesz że każde przerwanie ma priorytet, a do określania pozycji enkodera musi być zachowana kolejność. Z tego co pamiętam z 8051 to przerwania powodują umieszczanie adresów powrotów na odpowiedniej liście w pamięci RAM. Jak przegniesz z niezakończonymi przerwaniami to zaliczysz kolizję danych itp krzaczki.

Sęk w tym, że Ty na prawdę nie masz o tym pojęcia. Widzę, że nie chcesz ich użyć bo po prostu nie umiesz. Jeszcze raz: przeczytaj tę książkę co polecałeś pioterkowi albo jakąkolwiek inną traktującą o programowaniu mikrokontrolerów a poznasz siłę przerwań.


A tak nawiasem mówiąc to właśnie piszę program na ATMega48, który na podstawie GPS-a generuje impulsy drogi. I wiesz co, korzystam z przerwań od UART-a, timera i pinów zewnętrznych. I wiesz co? Działa

[wedlock]

Są przecież nawet do tego biblioteki do obsługi enkodera na przerwaniach. Sam takie używam do sterownika mojej kotłowni.

[pioterek]

Nie wiem natomiast dlaczego Tobie akurat staje zliczanie po pełnym obrocie..

Nie staje i liczy bez końca - źle mnie zrozumiałeś, ja tylko zwracałem uwagę na to, że istotna jest wartość jaka się wyświetli po wykonaniu jednego pełnego obrotu, gdyż to stanowi podstawę dopasowania urządzenia do zastanych w maszynie warunków mechanicznych. Chodzi o prawidłową współpracę programu z dowolną maszyną.
Witam. Pobrałem ten program i faktycznie zaczął liczyć "po ludzku". W czasie wpisywania wartości do wyświetlacza już jest sygnalizowana właściwa cyfra która jest w trakcie edycji. Niestety pozostałe wady programu o których napisano w tym wątku, zostały niestety pozostawione ( jako nie istotne, są jednak upierdliwe, ) i zdecydowanie oddalają decyzję o zastosowaniu programu przez potencjalnego użytkownika. Ilość pobrań powinna coś mówić. Nie wiem czy koledze na tym zależy, ale gdyby znalazł czas i chęci to pozostaje trochę do poprawiania. Szybkość liczenia nie jest rewelacyjna i przy jej wzroście gubi kroki, jednak ten problem uznał bym za najmniej istotny, bo można kręcić wolniej gdy dokładny pomiar ma priorytetowe znaczenie. Wyświetlają się nadal cztery minusy a wystarczył by jeden po lewej stronie. Klawisze potrafią wygenerować kilka zdarzeń w wyniku jednego wciśnięcia. Wyjście z wpisywania wartości jest realizowane nadal za pośrednictwem przycisku reset i często bywa, że kończy się zresetowaniem wpisanego wyniku, możliwe, że to z powodu wcześniej opisanej niedogodności. Poprawa wychodzenia z menu - może innym przyciskiem np. "next" po tym jak zmieni się ostatnią edytowaną cyfrę, albo "menu", bo resetem to loteria. Był bym jeszcze za tym, by zmianie uległ sposób działania menu w taki sposób jaki ja opisałem z ograniczeniem do maksymalnie czterech przycisków w taki sposób, że zadziałanie jednej funkcji zmienia działanie pozostałych przycisków. Opisywałem to na środku strony:
https://www.cnc.info.pl/topics14/dro-di ... 61,240.htm
Wszystko pozostaje jednak w Twoich rękach, nie znam się na tym i tyle.