AVR - Obsługa przerwań dla enkodera przy dużej prędkości obrotowej

Question

Witam; mam program, w którym używam kilku przerwań (timery, 4xUART). Niestety, muszę kontrolować encoder o bardzo dużej ilości impulsów. Wszystko działa prawidłowo, ale przy dużej prędkości obrotowej encodera, czasem procesor źle zinterpretuje dane i pojawi się bład w liczeniu impulsów. Jak...

dondu · Accepted Answer

Bez obawy

Wprawdzie nie znamy programu, ale spokojnie dasz radę - spróbuj.

Alternatywnie możesz oczywiście sam decydować o tym, dodając na początku każdego przerwania innego niż INT0 rozkazy blokujące wszystkie pozostałe z wyjątkiem INT0 i dodać sei() + na końcu dodać cli(), a po nim odblokować zablokowane przerwania.

Ale najpierw spróbuj ISR_BLOCK i możliwie najkrótszą funkcję obsługi przerwania INT0.

Dodano po 10 [minuty]:

Miałem na myśli oczywiście ISR_NOBLOCK

Promuję tematy:
20.02.2019 Droid R2D2 - Czekamy na Wasze uwagi do konstrukcji (cz. 1)

Konto nie istnieje · Accepted Answer

W AMEGA 2560 można to zrobić tylko programowo (podczas wchodzenia w przerwanie). Generalnie nie ma to sensu bo narzut na programowe ustalanie priorytetu będzie większy niż odpowiednio napisana funkcja obsługi enkodera na INT0.
Tzn. lepiej szybko obsłużyć INT0 niż się bawić w ustawianie priorytetów przerwań.

Andrzej__S · Accepted Answer

Chciałbym jeszcze coś dodać, bo moim zdaniem zapotrzebowanie na RAM to nie jedyny problem w przypadku zagnieżdżania przerwań.

Nie znamy programu, więc trudno przewidzieć, czy sprawa dotyczy tego konkretnego przypadku. W przypadku zagnieżdżania przerwań należy jednak pamiętać o pewnych zasadach. Procedury obsługi przerwań, które ustawiają globalną flagę zezwalającą na przerwania muszą np. zapewniać atomowy dostęp do współdzielonych wielobajtowych zmiennych czy też używać funkcji reentrant (w przypadku wywoływania tej samej funkcji również w procedurach obsługi innych przerwań). W niektórych przypadkach może i tak być konieczne zablokowanie przerwań np. w czasie modyfikacji zmiennej wielobajtowej lub wykonywania niektórych funkcji, co z kolei opóźni obsługę przerwania, którego priorytet chcemy podnieść. Normalnie flaga I w SREG jest wyzerowana w czasie obsługi przerwania, więc nie trzeba się o takie rzeczy martwić.

Piszę o tym, bo widzę 4xUART, więc jest duże prawdopodobieństwo, że procedury obsługi przerwań wywołują tę samą funkcję np. dodającą dane do bufora cyklicznego. Jeśli tak jest to należałoby sprawdzić, czy funkcje te spelniają wymogi reentrant.

Fredy · Accepted Answer

A czy czasem ten encoder nie ma wyjścia typu OC (otwarty kolektor)?
Jeśli tak, to przy takiej dużej częstoliwości impulsów, odległość pomiędzy może być tak mała, że na skutek tworzenia się układu całkującego możesz źle interpretować te impulsy.
Jeśli rzeczywiście jest to encoder o wyjściu OC to :
Jakie rezystory masz na kolektorach?
Spróbuj je zmniejszyć do najmniejszej dopuszczalnej wartości, lub zrób wzmacniacz niskoimpedancyjny np na dwóch tranzystorach NPN i PNP.

Możesz jeszcze spróbować, czy detekcja tylko na opadającym zboczu działa prawidłowo.
Mam wrażenie że tak będzie - jeśli tak, to masz rozwiazanie, bo zbocze opadające będzie bardzo ostre i szybkie.
Drugie zbocze będzie uzależnione od rezystora kolekterowego i pojemności kabla.

excray · Answer

Oczywiście że możesz. Konkretne rozwiązanie wymaga podania języka w jakim piszesz. Niemniej moim zdaniem powinieneś zupełnie inaczej podejść do tematu. Opisz szerzej swoja aplikację a dokładniej w jakim celu wykorzystujesz enkoder.

Marek_Gorecki · Answer

Encoder służy do pomiaru odległości.
Wiem , że mógłbym użyć innego , z mniejszą ilością impulsów, ale mam tylko taki.
Ten encoder jest optyczny i ma najprawdopodobniej 1000 imp/obrót.
Kółka pomiarowego nie mogę zwiększyć, bo nie ma miejsca.
Oprocz tego odbieram jeszcze dane po RS z kilku zródeł, a także pracuja 2 timery z przerwaniami.

Pisze w języku C.
Zatem, aby odblokować to jedno przerwanie w każdym innym przerwaniu to musze zablkować wszystkie inne przerwania, a następnie dać "sei" ?

dondu · Answer

Jaka jest maksymalna częstotliwość impulsów z enkodera?

excray · Answer

Czy kierunek jest Ci rzeczywiście potrzebny?

Marek_Gorecki · Answer

tak. Jeśli chodzi o częstotlwość impulsów to jest to max kilka KHz . Problem pojawia się jeśli szarpnę mocno mierzonym wężem. Wtedy pojawiają się błedy, i po wysunięciu a następnie zwinięciu węża nie mam zera na wyświetlaczu. Dodano po 2 [minuty]: Może częstotliwość nie jest porażająca, ale czas przesunięcia impuslów wzgledem siebie jest bardzo mały.

dondu · Answer

W takim przypadku możesz w pozostałych funkcjach przerwań użyć atrybut ISR_BLOCK co spowoduje, że kompilator doda na ich początku rozkaz sei() i każde inne przerwanie będzie mogło przerwać takie przerwanie.

Oczywiście wtedy ostrożnie musisz podchodzić do ilości wolnej pamięci RAM, bo w skrajnym przypadku stos może ją przepełnić.

Promuję tematy:
20.02.2019 Droid R2D2 - Czekamy na Wasze uwagi do konstrukcji (cz. 1)

Marek_Gorecki · Answer

ale ja bym chciał, aby tylko to jedno przerwanie od INT0 się mogło odbyć w trakcie trwania innych przerwań. Jeśli otworze inne, to boję się że może dojść do tragedii.

Marek_Gorecki · Answer

A czy można zmienić priorytet przerwań. Chodzi mi o to, aby jeśli w trakcie wykonywania jakiegoś przerwania, zgłosily się przykładowo 2 kolejne, to aby jedno z nich było zawsze wykonywane w pierwszej koilejności?

Marek_Gorecki · Answer

No widze że jednak to chyba jest niebezpieczny kierunek.
Zastanawiam się , czy można te impulsy podzielić , aby nie dręczyły tak obficie procesora. Tylko, że chodzi mi o to, aby po podziale zwiększył się dystans pomiędzy impulsami, bo to właśnie ten dystans dla mnie jest najważniejszy.
Jeśli podzielę oba impulsy przez np 16 na przerzutnikach , to nic mi to nie da, odległość się nie zmieni.
Macie może jakieś pomysły ?
Czy tylko dodatkowy mały procesor?

dondu · Answer

Ponowię: Zrób w końcu test, a przekonasz się, czy Twoje obawy są słuszne. Ja sądzę (nie znając programu), że jeżeli pozostałe przerwania nie są napisane w jakiś kosmicznie blokujący mikrokontroler sposób, to bez problemu je obsłużysz.

Konto nie istnieje · Answer

Ja bym po prostu mocno pooptymalizował wszystkie przerwania.
Jeżeli impulsy masz co max kilka kHz, przyjmijmy najgorszy wariant 10kHz, to masz aż 14740 cykli na obsługę. Może Ci chodziło o cały cykl a nie impulsy, a więc to będą 4 zbocza (enkoder odczytywany kwadraturowo). No to wtedy masz 4 razy więcej zbocz, czyli 4 razy mniej czasu na obsługę. To i tak aż 3685 cykli.
To aż nadto wystarczy na obsługę buforów UARTów nawet jak by to zrobić niezbyt optymalnie na zwykłych buforach (nie cyklicznych).
Coś tam jest nie tak w kodzie że się to nie wyrabia.
Może te dane lecą tekstowo i trzeba w locie przeliczać z ASCII na int. Albo co gorsza na float. No to wtedy nic dziwnego że się czasami przyblokuje (jeżeli to przeliczanie jest w przerwaniu).

Andrzej__S · Answer

Skąd ten pesymizm. Nikt nie napisał, że się nie da (włącznie ze mną), tylko uświadamiamy Ci, na co zwrócić uwagę. Priorytetu nie da się w AVR zmienić (jedynie pozornie poprzez zagnieżdżanie), ale akurat INT0 ma priorytet najwyższy (zaraz po RESET). W przypadku, kiedy w czasie trwania wykonywania jednej procedury obsługi przerwania pojawią się dwa przerwania (lub więcej), to przerwanie INT0 będzie obsłużone w pierwszej kolejności. Jeśli łączny czas najdłuższej z procedur obsługi przerwań i tej od INT0 nie jest dłuższy od najkrótszego odstępu między zboczami impulsów z enkodera, to na pewno nie zgubisz impulsu, nawet jeśli nie będziesz zagnieżdżał przerwań. Kolega się chyba pomylił o jedno miejsce dziesiętne No ale może się uda wyrobić w 368 taktach, może wystarczy jedno przerwanie na cały cykl (zamiast 4 na każdym zboczu) i wtedy mamy do dyspozycji 1474 takty, może enkoder nie osiąga aż 600 obrotów na minutę. Dobrze byłoby mieć jakieś dokładniejsze dane. Zwykły dzielnik częstotliwości na przerzutnikach tu nic nie da i nie chodzi tu tylko o odległość między zboczami. Aby podzielić dobrze częstotliwość impulsów z enkodera na obu kanałach z zachowaniem przesunięcia fazowego między nimi potrzebowałbyś jeszcze sporo innych elementów. Tak bym nie kombinował.

Konto nie istnieje · Answer

Heh, faktycznie No ale kilkaset taktów i tak powinno wystarczyć jak się to dość dobrze napisze.

bootrecord · Answer

Proponuje rozważyć zmianę procesora na jeden z rodziny PIC18F. One w standardzie obsługują dwa priorytety przerwań ... i za to je lubię. Wtedy taki problem można bardzo łatwo rozwiązać. Encoder robi się na obsłudze normalnego przerwania a wszystkie pozostałe na przerwaniu z niskim priorytetem.

Oczywiście jeśli chcesz przejść na innego producenta - przyzwyczajenie robi swoje.

Mam na sprzedaż:
05.01.2018 PT2222-001
18.10.2005 TDA2653A
18.10.2005 TDA4601
18.10.2005 MAA502

Marek_Gorecki · Answer

Zmiana procesora, raczej nie możliwa.
Jeśli już to zmieniłbym na Xmega co ma sprzetową obsługę encodera.
Ale na razie bede probował na ATMEGA2560.

Jeśli chodzi o przerwania to wyglądają one tak (kompilator Codevision):

1) Procedura odczytu encodera (przerwanie na obu zboczach):

Zaloguj się, aby zobaczyć kod

Procedury odbioru danych z UARTA sa 4 i wszystkie identyczne:

Zaloguj się, aby zobaczyć kod

Jest też jedna przerwanie od Timera:

Zaloguj się, aby zobaczyć kod

Wydaje mi się, że wszystkie te procedury nie są zbyt obciążające.
Co o tym sądzicie?

Konto nie istnieje · Answer

No wydają się dość proste. Nie ma w nich pętli ani delayów. Powinny się wyrabiać w mniej jak 100 cyklach.
Musiał byś sprawdzić oscyloskopem albo analizatorem stanów logicznych jak to wygląda.
Tzn. zmieniać stan jakiegoś pinu na powiedzmy H podczas wchodzenia do przerwania INT0, a podczas wychodzenia z powrotem na L. I byś widział czy przerwanie faktycznie nie nadąża za prawdziwymi impulsami na pinie od INT0.
No ale przede wszystkim to zrób w końcu ten test z ISR_NOBLOCK.

Andrzej__S · Answer

@Marek_Gorecki Jeden cykl enkodera składa się z czterech zboczy (po 2 na każdy kanał). Sądząc po tym co piszesz nie potrzebujesz dużej precyzji i zliczasz tylko jedno z nich, więc częstotliwość przerwań INT0 wyniesie: Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka     f = n*N/60 gdzie:     n - prędkość obrotowa enkodera [1/min]     N - ilość cykli ekodera na obrót Ilość taktów procesora pomiędzy przerwaniami będzie równa F_CPU/f. Ilość taktów od wystąpienia przerwania INT0 do zmiany stanu drugiego z kanałów będzie czterokrotnie mniejsza (w tym czasie należy odczytać stan drugiego pinu). Przy założeniu F_CPU = 14,74MHz i prędkości obrotowej 600obr./min będzie to około 380-390 taktów, a więc całkiem sporo. W procedurze obsługi INT0 interesuje nas głównie czas na prolog i odczytanie stanu drugiego pinu, co nie powinno zająć więcej niż ok. 30-40 taktów. Jeśli jesteś w stanie zrobić tak, by reszta (około 350 taktów) wystarczyła na wykonanie dowolnej z pozostałych procedur obsługi przerwań, jakich używasz, to obędzie się bez zagnieżdżania przerwań. Można oczywiście użyć zagnieżdżania, jest to jak najbardziej wykonalne, ale należy pamiętać o tym, o czym napisałem w poście #12. Trzeba też pamiętać, że samo ISR_NOBLOCK włączy wszystkie aktywne przerwania, więc w najgorszym przypadku zagnieżdżanie osiągnie poziom równy ilości aktywnych przerwań, konsumując RAM (stos) i powodując, że obsługa przerwania, które wystąpiło pierwsze, zakończy się jako ostatnia. Osobiście zamiast ISR_NOBLOCK (które zdaje się włącza globalną flagę przerwań zaraz na początku przed prologiem procedury) użyłbym sei() na początku obsługi po prologu i wcześniejszym wyłączeniu wszystkich przerwań oprócz INT0, a na końcu procedury włączyłbym wszystkie przerwania ponownie. Myślę, że można sprawdzić w symulatorze, ile taktów potrzebują na wykonanie - należy rozpatrzyć najgorszy przypadek. EDIT: Jak pisałem post, to nie widziałem jeszcze Twojego kodu. Widzę, że przerwania masz na obu zboczach, więc będą dwa razy częściej, ale limit (ok. 350 taktów) pozostaje bez zmian.

dondu · Answer

W poście #9 sugerowałem autorowi, ale nie sprawdził tego jeszcze: to:

Andrzej__S · Answer

@dondu No chyba faktycznie nie doczytałem i powieliłem radę. Jeśli Cię tym uraziłem to przepraszam. Wreszcie autor tematu uchylił rąbka tajemnicy i sypnął fragmentami kodu Odnoszę wrażenie, że te procedury powinny się wyrobić bez konieczności zagnieżdżania przerwań, chyba, że nie mamy prawidłowych danych odnośnie prędkości obrotowej enkodera i/lub ilości impulsów na obrót. Nawet jeśli prędkości transferu przez UART'y są duże i przerwania występują często, to i tak prędzej spodziewałbym się gubienia znaków przez UART niż impulsów z enkodera, bo przecież procedury obsługi przerwań zewnętrznych mają wyższy priorytet. @Marek_Gorecki Mógłbyś może dokładniej opisać relację wąż-enkoder?

Konto nie istnieje · Answer

Może po prostu dane z enkodera są zakłócone i występuje więcej impulsów niż wynikało by z prędkości obrotowej enkodera. Przy kwadraturowym jest jeszcze o tyle dobrze że zakłócenia się same niwelują. Tzn. licznik będzie zliczał do przodu i do tyłu na przemian. Tyle że ten licznik musi po prostu nadążać z tym zliczaniem. A tutaj liczy procek i go może po prostu zamulają te zakłócenia.

dondu · Answer

Nie, nie Chodziło mi tylko o to, by autor tematu zaczął wreszcie wykonywać próby, bo już sporo napisaliśmy i odpowiedzi zaczynają się powtarzać.

Andrzej__S · Answer

Zastanawia mnie jeszcze rodzaj sprzężenia między enkoderem a obiektem mierzonym. Jeśli jest to sprzężenie cierne, jak się domyślam, to być może po prostu występuje poślizg przy szarpnięciu węża i z tego wynika błąd. Jak widać wina niekoniecznie musi leżeć po stronie mikrokontrolera. W celu rozgraniczenia problemu zbudowałbym prosty symulator enkodera na innym mikrokontrolerze, który po wciśnięciu przycisku wygeneruje np. 50000 impulsów w prawo z maksymalną oczekiwaną częstotliwością i później 50000 impulsów w lewo z częstotliwością np. o połowę mniejszą, aby mieć pewność, że wracając żadnego impulsu nie zgubi. Wystarczy prosty programik oparty o funkcję delay() i pętlę for(), nie potrzeba jakiejś super dokładności. Wtedy byłoby wiadomo, czy mikrokontroler się nie wyrabia, czy przyczyna leży gdzie indziej. Przy okazji, zmieniając wartości opóźnień, można ustalić częstotliwość graniczną, przy której mikrokontroler zaczyna gubić impulsy.

jnk0le · Answer

Zakładając że rx0_index jest typu 'volatile' można zrobić coś takiego : Kod: C / C++Zaloguj się, aby zobaczyć kod Zaoszczędzi to parę cykli potrzebnych na dostęp do pamięci. No i jestem bardzo ciekaw jak wygląda odbiór danych w pętli głównej bo na bufor cykliczny mi to nie wygląda

Marek_Gorecki · Answer

To dodawanie na końcu znaku null rzeczywiscie nie jest potrzebne. Moge je przeciez dodać wtedy gdy potrzebuję. A jeśli chodzi o Twój program - to czemu miałby on zajmowac mniejszą ilosc danych? Do kolegów co podpowiadają mi użycie makr, tak jak pisałem wczesniej, uzywam Codevision a w nim nie ma czegoś takiego - chyba.

jnk0le · Answer

Bo zmiennych 'volatile' kompilator nie optymalizuje gdyż zakłada iż są modyfikowane przez jakieś zewnętrzne peryferia i w każdym cyklu moga mieć inną wartość. Co oznacza że każde użycie będzie się wiązało z ładowaniem zmiennej z pamięci do rejestrów i dopiero wykonanie koniecznych zadań. I tak przy każdym kolejnym użyciu, a dostęp do pamięci to co najmniej 2 cykle zamiast jednego.

AVR - Obsługa przerwań dla enkodera przy dużej prędkości obrotowej

Czy mogę pozwolić, aby przerwanie od enkodera INT0 mogło przerywać inne procedury obsługi przerwań, i czy jest to bezpieczne?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Podsumowanie tematu