Witam Robię tester enkoderów inkrementalnych. Te, które będę sprawdzał dają 4096 impulsów na obrót. Na stole będę je kręcił około 25 obrotów na sekundę. Daje to 102400 impulsów na sekundę. Zrobiłem, układ, który mi to wyświetla na atmedze 32 i lcd2x16. Układ pokazuje poprawnie zmianę(przyrost) impulsów gdy ręcznie powoli kręcę enkoderem natomiast gdy już próbuję trochę szybciej kręcić to tester nie widzi przerwań. Mam podobny układ zrobiony na ESP32 w "androino", też na przerwaniach i ten układ działa poprawnie tzn widzi ponad 100000 przerwań.
Zastanawiam się czy przerwania INT0 i INT1 dadzą radę to zobaczyć.
Jeśli nie zależy Ci na informacji o kierunku obrotu enkodera, do zliczania impulsów możesz wykorzystać wejście T1 timera 1. Prescaler timera 1 ustwiasz tak żeby źródłem zegara było źródło zewnętrzne na pinie T1, wtedy impulsy enkodera będą zliczne sprzętowo w rejestrze TCNT1. Dodatokowo musisz skonfigurować timer 0 lub timer 2 tak żeby wywowyłać przerwanie co np 1s i zapisywać rejestr TNCT1 do zmiennej i kasować rejster TNCT1 żeby zaczął zliczać od nowa. Tylko przy przerwaniu co 1s, maksymalna liczba impulsów to 65535 imp/s (timer 16 bitowy). Możesz tą liczbę zwiększyć na dwa sposoby: 1) Dodać przerwanie od przepełenienia TCNT1 i zliczać ilość przerwań a potem wyliczyć całkowitą liczbę impulsów: 65535 * enc_ovf_counter + TNCT1, 2) Zmniejszyć czas próbkowania z 1s do np: 100ms, a potem przeliczać wynik na sekundy. Atemga32 ma tylko jedno wejście T1 więc będziesz mógł mierzyć tylko jeden kanał w danym momencie ale za to będzie sie to odbywać praktycznie tylko sprzętowo.
Wykorzystując przerwania INT0, INT1 dla częstotliwości taktowania 16Mhz i 102400 imp/s, będzie tylko 156 cykli zegara na obsługę przerwania i wyświetlenie wyników na LCD, co nie będzie działać.
[quote="Mario17"]Jeśli nie zależy Ci na informacji o kierunku obrotu enkodera, do zliczania impulsów możesz wykorzystać wejście T1 timera 1. Prescaler timera 1 ustwiasz tak żeby źródłem zegara było źródło zewnętrzne na pinie T1, wtedy impulsy enkodera będą zliczne sprzętowo ..
"Brawo Ty". Zapomniałem, że kwarc nie zawsze musi na tej budowie nadawać wszystkim tępo, .. a raczej nie wpadłem na to że tak można to zorganizować. 0,00000006 x 156 = 10mikrosekund max . Faktycznie mało czasu doliczając obsługę wyświetlacza. Info o kierunku nie jest ważne.
Rozumiem, że chodzi o takie wyłączenie żeby bez obsługi LCD odczytać wartość z enkodera, a potem włączyć LCD by wyświetlić wynik. Czy np. co 5s wysyłać wynik na LCD, a potem z powrotem przejść do odczytu (zapisu np. do bufora) danych z enkodera. Nie próbowałem. Spróbuję.
No nie mów, że próbowałeś do tej pory wyświetlać cokolwiek na LCD bezpośrednio z przerwania jakiegokolwiek, bo jeśli tak - to pamiętaj, że to daje mniej więcej taki efekt, jak włożenie kija w szprychy, podczas gdy jedziesz rowerem. Więc na przyszłość pamiętaj, żeby nigdy tego nie robić. LCD się obsługuje tylko w pętli głównej.
ISR (INT0_vect) //+ ISR INT1 do drugiego kanału enkodera { encoder_licznik ++; } */ do tego mam timer0, który w przerwaniu co 100 ms pobiera mi stan encoder_licznik do LCD i zaraz potem go kasuje. Obsługa LCD jest w odrębnej funkcji w odrębnym pliku .c
------------------------ [ Dodano po: kilkunastu sekundach ]
DarkMajster napisał(a):
A próbowałeś po prostu wywalić obsługę lcd z przerwania?
ISR (INT0_vect) //+ ISR INT1 do drugiego kanału enkodera { encoder_licznik ++; }
A to ok - to sprawdź teraz z ciekawości w pliku *.lss po kompilacji ile komend ASM użytych jest w tym przerwaniu a dalej to już będzie łatwo policzyć ile taktów zegara schodzi na przerwanie. Musisz tylko sprawdzić ile każda z komend ASM zajmuje taktów.
Przy okazji, daj sobie kwarc 20MHz zamiast 16MHz żeby na maxa wykorzystać możliwości procka w przerwaniu
Nie mam na razie kwarcu 20 MHz to będę działał na 16 MHz. Rozumiem, że w trakcie jednej pętli procesor ma mieć możliwość przynajmniej raz skoczyć do wektora/adresu przerwania czyli do funkcji, która inkrementuje mi zmienną i ją jeszcze wykonać. Jedna pętla to w tym przypadku 16000000 / 102400 = 156. W tej chwili cały kod z obsługą przerwania, lcd zajmuje mi 1200 linijek. Gdy wywalę wszystko oprócz timera i przerwań to kod zajmuje 160 linijek tylko, że wtedy nic nigdzie nie zobaczę. Gdyby tak "podnieść" kwarc, podzielić wynik na 3 bajty i wysłać go od razu na cały port, a innym prockiem go wyświetlić?? chyba słaby pomysł. Nie wiem czy to o ten kawałek kodu chodzi?:
Masz jakikolwiek analizator logiczny? W bardzo łatwy sposób zmierzysz sobie ile czasu co zajmuje w programie
Przymierzam się do zrobienia ale póki co zbieram informacje na ten temat. Mam oscyloskop. Jak przyjdzie obudowa za kilka dni i poskładam to wszystko to zaczną się eksperymenty.
Masz jakikolwiek analizator logiczny? W bardzo łatwy sposób zmierzysz sobie ile czasu co zajmuje w programie
Analizator świetna rzecz zanim się zorientowałem że MK_AVR_Calculator posiada tą funkcjonalność to wcześniej ogarnąłem dla Magic Ledów nop-y analizatorkiem dla wybranych rezonatorków.
Rozumiem, że w trakcie jednej pętli procesor ma mieć możliwość przynajmniej raz skoczyć do wektora/adresu przerwania czyli do funkcji,
Oj oj - joj - to kolega jeszcze widzę nie rozumie w ogóle jak działają przerwania, ... ale ok mega krótka podpowiedź. Absolutnie nie jest tak, że procek ma możliwość sobie skakania przynajmniej raz do wektora ...
Program główny wykonuje się w pętli i nie patrz na czas jego wykonania bo to dla ciebie nie jest tu istotne za bardzo. Natomiast gdy na pinie INTx wystąpi (W DOWOLNYM MOMENCIE) np zbobcze opadające (bo tak jest skonfigurowany INTx) to wtedy NIEZLAEŻNIE od wszystkiego - program główny jest przerywany, i następuje skok do procedury obsługi przerwania, a po jego zakończeniu, wznawiane jest wykonywania kodu programu głównego od momentu gdzie został on przerwany. Więc to nie ma nic wspólnego z jakąś możliwością o której napisałeś.
LukMeks napisał(a):
Jedna pętla to w tym przypadku 16000000 / 102400 = 156.
Więc to - jest jakimś kompletnym nieporozumieniem i nie za bardzo nawet rozumiem co tu próbujesz obliczać.
LukMeks napisał(a):
Gdy wywalę wszystko oprócz timera i przerwań to kod zajmuje 160 linijek tylko, że wtedy nic nigdzie nie zobaczę.
W ogóle zostaw te rozważania i wywalania po co ? o co chodzi ? W programie możesz mieć co chcesz - toż program główny nie ma wpływu na czas wykonywania przerwań, wręcz odwrotnie to PRZERWANIA mają wpływ na jego czas - ale ciebie czas wykonania programu w ogóle tu nie interesuje.
LukMeks napisał(a):
Gdyby tak "podnieść" kwarc, podzielić wynik na 3 bajty i wysłać go od razu na cały port, a innym prockiem go wyświetlić?? chyba słaby pomysł.
Większy kwarc to tak ale TYLKO po to żeby ci się ew szybciej przerwanie INTx wykonywało a nie program główny tutaj.
LukMeks napisał(a):
Nie wiem czy to o ten kawałek kodu chodzi?:
dokładnie o ten i zobacz teraz:
Więc ? jak widzisz na czerwono zaznaczyłem ci ile cykli zegara zajmuje każdy z rozkazów ASM tak na szybko bez zaglądania do dokumentacji, i podsumowanie, czyli łącznie przerwanie zajmuje 32 cykle ... a to oznacza, że jeśli jeden cykl trwa: 1/16000000Hz = 62,5 ns ! Więc teraz 62,5ns * 32cykle = czas wykonania przerwania = 2 us.
2 us to 500 kHz
więc gdybyś przerwanie wyowływał z częstotliwością 500 kHz - to by się program główny troszkę "dławił" że tak powiem bo osiągnąłbyś - można powiedzieć 100% zajętości procka - zakładając do tego, że nie występują inne przerwania. Więc to górna i graniczna częstotliwość dla taktowania 16 Mhz
A dla 20 MHz ? 1 cykl - 50ns, więc 32 cykle zajmą 1,6us zatem zwiększa się panie maksymalna częstotliwość to już ok 625 kHz
-------------------------------
krótko mówiąc przy kwarcu 16 MHz możesz sobie przy takim kodzie przerwania pozwolić bezpiecznie na ok - powiedzmy 450 kHz zaś przy kwarcu 20 Mhz na ok 570 kHz
To przy założeniu, że albo nie używasz innych przerwań, np od timera albo jeśli z nich korzystasz to z argumentem NO_ISR, żeby mogły być przerywane przez INTx
albo w ogóle zamiast przerwań timera - tylko odczytujesz sobie jego rejestr żeby zliczyć czas 1s. Oczywiście w tym wypadku ta sekunda z uwagi na konieczność też zastosowania jakiejś zmiennej - licznika, być może się troszkę rozjedzie i nie będzie to równo 1.00000000000000000000000 sekundy ale np 1.00002 sekundy.
Ale w tym wypadku można to sobie też skorygować programowo - a szczególnie jak już zrozumiesz jak działają przerwania i weźmiesz w rękę analizator stanów logicznych jak pisze wyżej kolega i sobie w mega prosty sposób określisz ile tak w rzeczywistości trwa u ciebie przerwanie.
Obejrzyj sobie koniecznie np ten poradnik:
dopiero wtedy zobaczysz co to daje i JAK BARDZO takie narzędzie jest potrzebne gdy bawimy się prockami a szczególnie że można jego najprostszą wersję kupić na allegro za ok 30-40zł
A w międzyczasie optymalizacji wersji na przerwaniach, wersja z odczytem pinu T1, taktowanie 16Mhz. Pomiar sygnału o częstotliwości 1MHz i więcej, a proc w tym czasie będzie się nudził .
Masz jakikolwiek analizator logiczny? W bardzo łatwy sposób zmierzysz sobie ile czasu co zajmuje w programie
Analizator świetna rzecz zanim się zorientowałem że MK_AVR_Calculator posiada tą funkcjonalność to wcześniej ogarnąłem dla Magic Ledów nop-y analizatorkiem dla wybranych rezonatorków.
Też miałem z tym tym trochę zabawy. Nie byłem w stanie ustawić na oko tych czasów. Dopiero jak pożyczyłem oscyloskop to udało się ustawić nopami 800/400 ns i diody zaczęły się słuchać.
Rozumiem, że w trakcie jednej pętli procesor ma mieć możliwość przynajmniej raz skoczyć do wektora/adresu przerwania czyli do funkcji,
Oj oj - joj - to kolega jeszcze widzę nie rozumie w ogóle jak działają przerwania, ... ale ok mega krótka podpowiedź. Absolutnie nie jest tak, że procek ma możliwość sobie skakania przynajmniej raz do wektora ...
Program główny wykonuje się w pętli i nie patrz na czas jego wykonania bo to dla ciebie nie jest tu istotne za bardzo. Natomiast gdy na pinie INTx wystąpi (W DOWOLNYM MOMENCIE) np zbobcze opadające (bo tak jest skonfigurowany INTx) to wtedy NIEZLAEŻNIE od wszystkiego - program główny jest przerywany, i następuje skok do procedury obsługi przerwania, a po jego zakończeniu, wznawiane jest wykonywania kodu programu głównego od momentu gdzie został on przerwany. Więc to nie ma nic wspólnego z jakąś możliwością o której napisałeś.
LukMeks napisał(a):
Jedna pętla to w tym przypadku 16000000 / 102400 = 156.
Więc to - jest jakimś kompletnym nieporozumieniem i nie za bardzo nawet rozumiem co tu próbujesz obliczać.
LukMeks napisał(a):
Gdy wywalę wszystko oprócz timera i przerwań to kod zajmuje 160 linijek tylko, że wtedy nic nigdzie nie zobaczę.
W ogóle zostaw te rozważania i wywalania po co ? o co chodzi ? W programie możesz mieć co chcesz - toż program główny nie ma wpływu na czas wykonywania przerwań, wręcz odwrotnie to PRZERWANIA mają wpływ na jego czas - ale ciebie czas wykonania programu w ogóle tu nie interesuje.
LukMeks napisał(a):
Gdyby tak "podnieść" kwarc, podzielić wynik na 3 bajty i wysłać go od razu na cały port, a innym prockiem go wyświetlić?? chyba słaby pomysł.
Większy kwarc to tak ale TYLKO po to żeby ci się ew szybciej przerwanie INTx wykonywało a nie program główny tutaj.
LukMeks napisał(a):
Nie wiem czy to o ten kawałek kodu chodzi?:
dokładnie o ten i zobacz teraz:
Więc ? jak widzisz na czerwono zaznaczyłem ci ile cykli zegara zajmuje każdy z rozkazów ASM tak na szybko bez zaglądania do dokumentacji, i podsumowanie, czyli łącznie przerwanie zajmuje 32 cykle ... a to oznacza, że jeśli jeden cykl trwa: 1/16000000Hz = 62,5 ns ! Więc teraz 62,5ns * 32cykle = czas wykonania przerwania = 2 us.
więc gdybyś przerwanie wyowływał z częstotliwością 500 kHz - to by się program główny troszkę "dławił" że tak powiem bo osiągnąłbyś - można powiedzieć 100% zajętości procka - zakładając do tego, że nie występują inne przerwania. Więc to górna i graniczna częstotliwość dla taktowania 16 Mhz
Rozumiem, że przerwania to sprzętowy break dla programu i nie ma nic do tego ilość kodu, delaye itp. Rozumiem, 32 cykle to funkcja przerwania i że im krótsza tym lepiej bo wtedy wychodzi mniejsza zajętość procka. Rozumiem też skąd biorą się 62,5 ns na jeden cykl. Nie rozumiem dlaczego te 2 us czyli 500khz to 100% zajętości procka.
No przecież jeśli w ciągu 2us wykona się w całości przerwanie, od razu w kolejnych dwóch i też przez całe dwie us kolejne przerwanie i tak dalej - to gdzie reszta czasu dla pętli głównej ? rozumiesz? W przerwie między przerwanimi procek zdaży ledwie wykonać może po jednym rozkazie ASM z kodu głównego..
wiesz co? Obejrzyj ty sobie DOKŁADNIE te dwa poradniki i to koniecznie, to wtedy zrozumiesz już przerwania do końca i co to oznacza zajętość procka w przypadku 8-bitowców, bo tu to wyjaśniam
Mirek dzięki serdeczne za omówienie kodu przerwania z rozkazami asemblera, bardzo pomocne. Niejednokrotnie ktoś z Was odsyłał mnie do analizy właśnie kodu asemblera jaki tworzy kompilator, ale nic z tego nie mogłem zrozumieć. Po twoim krótkim opisie jest dużo łatwiej. Jeszcze tylko gdyby ktoś mógł dodać, skąd mam wiedzieć, że np. "lds" to 2 cykle, a "pop" to już 1 cykl itd?
Cytuj:
Analizator świetna rzecz zanim się zorientowałem że MK_AVR_Calculator posiada tą funkcjonalność to wcześniej ogarnąłem dla Magic Ledów nop-y analizatorkiem dla wybranych rezonatorków
akenes o czym Ty piszesz? O jaka funkcjonalność Ci chodzi?
Jeszcze tylko gdyby ktoś mógł dodać, skąd mam wiedzieć, że np. "lds" to 2 cykle, a "pop" to już 1 cykl itd?
Przyjrzyj się temu fragmentowi kodu przecież czy nie zauważasz czym się różnią (nie zawsze ale w 95%) te rozkazy zajmujące 1 cykl od tych zajmujących 2 cykle ?
Nie widzisz że po lewej te jednocyklowe zajmują DWA bajty czyli jedno słowo w pamięci FLASH ? A te dwu-cyklowe zajmują DWA SŁOWA ! czyli aż 4 bajty we Flash ?
To oczywiście jest spore uproszczenie ale z grubsza tak można przyjąć ... bez zaglądania do noty - no bo pytasz skąd masz wiedzieć Panie kochany a zaglądałeś chociażby do byle pierwszej noty PDF dowolnego, podkreślam dowolnego procka AVR ? Toż zawsze pod jej koniec masz opisane kody ASM i ile cykli co zajmuje zawsze masz na końcu
"Instruction Set Summary" i tam masz jak na patelni podane ile który rozkaz zajmuje cykli czyli czasu procka
Panie kochany a zaglądałeś chociażby do byle pierwszej noty PDF dowolnego,
No pewnie, że zaglądałem, ale nie tak gdzie wskazujesz, tam to były zawsze jakieś znaczki, dziwne słowa,rzeczy których nie rozumiałem, więc nie zaglądałem tam bo to straszyło i jakieś takie dziwne
"Panie kochany...", że tak Cię zacytuję, gdybym ja to wszystko wiedział o czym wielokrotnie mówisz i piszesz to bym Ciebie nie potrzebował, a tak jesteś mi niezbędny
Dziękuje serdecznie za wyjaśnienie, już wiem trochę więcej
Przyszedł czas żeby zamknąć temat. Doczytałem, pooglądałem i poeksperymentowałem.
W końcu zrobiłem sterownik, który oprócz tego, że jest generatorem CTC, sterownikiem rejestrów to ma jeszcze funkcję testu enkodera. Test można robić zboczem opadającym lub zmianą zbocza.
Jeżeli chodzi o osiągi to:
Procesor jest taktowany 20 Mhz. Funkcja przerwania zajmuje dokładnie 32 linie poleceń asm.
Czas wykonania jednego polecenia to: 1 / 20000000 = 0,00000005 czyli 50 ns.
Czas wykonania funkcji przerwania to: 50 ns * 32 linie = 1600 ns = 1,6 mikrosekundy
Maksymalna ilość obsłużonych przerwań (zajętość procesora w tym przypadku = 100%) to: 1 / 0,0000016 = 625000 / sekundę.
Enkodery, które testuję dają 2048 impulsów na jeden obrót, a podczas normalnej pracy kręcą się 1500 ob/min.
Tester pokazuje stan wejścia INT0, liczy impulsy oraz pokazuje ilość impulsów na sekundę. Samo dzielenie licznika przerwań robi TIMER1, który ustawiony jest na przerwanie co sekundę.
Funkcje związane z LCD pracują w głównej pętli.
Tester działa poprawnie przy częstotliwości znamionowej pracy enkodera tzn przy 25 ob/sek. Robiłem testy zewnętrznym generatorem i dopiero przy 300-400 khz zaczyna "przymulać" LCD. Gdy dam mu ponad 0,5 mhz to przestaje działać menu.
Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 8 gości
Nie możesz rozpoczynać nowych wątków Nie możesz odpowiadać w wątkach Nie możesz edytować swoich postów Nie możesz usuwać swoich postów Nie możesz dodawać załączników
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
zanim się zorientowałem że MK_AVR_Calculator posiada tą funkcjonalność to wcześniej ogarnąłem dla Magic Ledów nop-y analizatorkiem dla wybranych rezonatorków.
