To mój pierwszy post na tym zacnym forum zatem Witam Wszystkich!
Przygodę z avr zacząłem trzy miesiące temu od kilku kursików internetowych, później BB, jeszcze nie do końca ogarnięty oraz to forum (na razie w trybie Read only). Na prośbę znajomego napisałem programik, który na podstawie zliczanych impulsów z enkodera przyrostowego ma określać, w której ćwiartce okręgu znajduje się aktualnie ramię czegoś tam. Program działa, generuje poprawnie dwu bitowe słowo w kodzie Gray'a ale dodatkowo, w sposób całkowicie przypadkowy generowane są impulsy ok 5us na obu wyjściach. O ile częstotliwość występowania jest przypadkowa, to miejsce występowania jest zawsze to samo. Występują trzy przypadki, zazwyczaj pojedynczo:
a) szpilka na G1 w odległości 36 impulsów enkodera od zbocza narastającego G1;
b) szpilka na G2 w odległości 72 impulsy enkodera od zbocza narastającego G2;
c) szpilka na G1 w odległości 108 impulsów enkodera od zbocza opadającego G1.
Dodam jeszcze, że 36 to reszta z dzielenia 804/256, 72 to reszta z dzielenia 1602/256 a 108 to reszta z dzielenia 2412/256.
Zostało to pokazane na obrazkach:



Podaję kod źródłowy:


Liczę na Waszą pomoc, jakieś wskazówki, może inny pomysł na generację tych dwóch sygnałów. Układ zmontowany na płytce uruchomieniowej oraz na stykówce, procek zmieniany na Mega168 - efekt ten sam, niestety. Jeśli post umieściłem w niewłaściwym miejscu, to proszę o przeniesienie. Pozdrawiam, Arek

Witaj,


Patrząc na te oscylogramy, to mam wrażenie, że przy tej podstawie czasu masz przekłamania wprowadzane przez oscyloskop wynikające ze zbyt małej częstotliwości samplowania. Musiałbyś zmniejszyć podstawę czasu do milisekund, aby zobaczyć czy nie są to czasem drgania styków enkodera.
Coś jak tu:




Jeśli program działa prawidłowo, to nie powinno spędzać snu z powiek

_________________
Pozdrawiam
Grzegorz

Cześć!
No teraz to już raczej Append

Nie mam 100% pewności co jest nie tak, ale mam kilka pomysłów:
1. To jest enkoder mechaniczny? W programie nie ma żadnego zabezpieczenia przed drganiami styków (ach! przedmówca mnie ubiegł ;d).
2. Operacje na zmiennej licznik nie są atomowe. Spróbowałbym zrobić taki myk:

Dzięki @buz11 za odpowiedź. Niestety "dodatki" na wyjściach są jak najbardziej rzeczywiste i zgodne z tym co napisałem wcześniej. Tamte zrzuty zrobiłem tylko na potrzeby lepszego zobrazowania problemu. Oto lepszy (dokładniejszy) przykład, dotyczy przypadku a), czyli 36 impulsów zliczanych przed zboczem narastającym na G1. Szpila widoczna w punkcie wyzwalania ma 4.85 us.



Edit:
Dzięki @wwojtek za podpowiedź, spróbuję w ten sposób. Co do enkodera, to jest to enkoder optyczny o 3216 impulsach na obrót.

Edit2:
Niestety, atomic nic nie zmienił

Nie napisałem, że je sobie wymyśliłeś, ale przy podstawie czasu o trzy rzędy wielkości większej od czasu trwania impulsu mierzonego jest duże prawdopodobieństwo przekłamania pomiaru przez sam oscyloskop.


Długo szukałem szpili na oscylogramie

Czy możesz pokazać ten impuls przy podstawie czasu 1 us? Nie sądzę, aby enkoder optyczny wprowadzał to zakłócenie, w zasadzie to niemożliwe.

_________________
Pozdrawiam
Grzegorz

Te zakłócenia nie pochodzą od enkodera, te zakłócenia są na wyjściach. Zanim dostałem enkoder, na wejście P1 podawałem sygnał prostokątny z generatora, wejście P2 zwarte do masy. Efekt był dokładnie taki sam.

Edit:
oto szpilka przy podstawie czasu 1us:

Sygnał zerujący to trzeci kanał enkodera (1 impuls na obrót mechaniczny?) czy jakaś krańcówka/przycisk?

Tak, to trzeci sygnał z enkodera, jeden na pełny obrót.

na

Albo inną formę zachowania integralności danych przy programowaniu pseudo-współbieżnym (a do takiej można zaliczyć obsługę przerwań).

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.

@barney - było, nie pomogło

Ops, no fakt. Ale i tak to trzeba w ten sposób pisać, więc powinno zostać
To w takim razie zacznijmy ograniczać kod, zacznijmy od wywalenia tej konwersji na kod greya.

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.

Witam
Może to nie to ale w tym kodzie:

dla licznik= (np.) 1608 spełniony jest również licznik>= 804.
Może takie coś:

Zdecydowanie

@kicajek - tam są else if'y więc po "pierwszym spełnionym" reszta warunków nie będzie w ogóle sprawdzana.

Moja podpowiedź to coś w stylu "jak nie kijem to młotkiem". Można spróbować wykluczyć przerwania z tego zadania (i akurat w tym konkretnym przypadku powinno to działać wystarczająco dobrze... ) i kod będzie wyglądał mniej więcej tak (nie wprowadziłem przerwania resetującego ale można to zrobić prawie identycznie zdaje się).

W przypadku niezrozumienia tematu odsyłam do poradnika Mirka odnośnie DS3231 czas 1:10:40




Daj znać czy to rozwiązało problem.

@barney nic nie zmienia.
@rekon również bez zmian
@squeez sygnały podawane są do jakiegoś urządzenia cyfrowego razem z sygnałami z enkodera. Próbowałem z filtrem rc oraz z wolnymi transoptorami ale wtedy sygnały rozmywały się i coś kaszaniło się w urządzeniu.

...racja - sorry
Przynajmniej ja lepiej zapamiętam . "Sami się uczymy usiłując pamagać "

Pozdr.

No jest to jakiś pomysł i jak najbardziej jutro go przetestuję. Dzięki. Cały czas mam jednak nadzieję, że uda się to poprawić bardziej elegancko, czyli programowo.

WItam
Jakiego procka używasz ?
Bo zgłupiałem w Atmedze 168 np. bity ISC01 i 00 ustawia się w zupełnie inny rejestrze niż w twoim programie nie w MCUCR tylko w EICRA.

Procek to Attiny85, Mega168 użyłem testowo, bo pomyślałem, że może maluch uszkodzony. Na dużym było to samo.

OK prog masz na attiny85 ...ok
Sorki

------------------------ [ Dodano po: kilkunastu sekundach ]

z zasilanie jakie masz ....tak przy okazji

------------------------ [ Dodano po: 2 minutach ]

mając oscyla podłącz się jednym kanałem pod zasilanie a drugim pod sygnał i zobaczy czy ma to jakiś związek ze sobą , jest to szybki sposób i wyeliminujesz już jedno....

@kicajek - święte słowa

Osobiście zgłaszam protest jeśli chodzi o filtry, bufory i inne rozwiązania sprzętowe. To obejście problemu. Przecież to musi działać tylko gdzieś się jakiś haczyk przyhaczył

@avrek - a bez przerwania od zerowania też jest to samo? Rozdzielczość enkodera na pewno jest dobra?

@giciors Na płytce uruchomieniowej jest stabilizator a na stykówce płytka ze stabilizatorem. Jeśli sugerujesz zakłócenia spowodowane śmieciami w zasilaniu, to niestety to nie to. Jak pisałem, szpilki pojawiają się losowo, ale zawsze w tym samym miejscu. Miejsca te powiązane są (chyba) w jakiś sposób z funkcją porównywania licznika z progami.

@wwojtek Ja również widzę to jako obejście problemu i raczej ostateczność. Nie mniej jutro wypróbuję ten pomysł, tak w celach poznawczych.
Rozdzielczość enkodera jest ok. Generalnie walkę ze szpilkami toczę w oparciu o generator, który generuje impulsy przyrostu P1, P2 zwarte do masy czyli symulacja obrotu enkodera w prawo. Zerowanie podpięte pod switch, w trakcie testów w zasadzie nie używane. Podpięcie enkodera nic nie zmienia, ale trzeba wtedy kręcić ośką. Jest to niewygodne dlatego generator.

Co wyzwala INT0 ?

zgaduje że zegar pracuje na 8MHz?
na oko 1 pętla programu głównego (tego z pierwszego posta) to 40-50 cykli procesora a to oznacza że impuls ok. 5us to jest jeden przebieg tej pętli.
Można sprawdzić w co się dzieje ze zmienną licznik w tym czasie kiedy robi te przeskoki. To może dać jakąś tam odpowiedź na pytanie co się dzieje złego.

sprawdzać na końcu pętli co jest podawane na wyjściach G1 oraz G2 i przechowywać 2 ostatnie wartości.
Jeśli pojawi się taka sytuacja że mamy na dowolnym z wyjść 1 -> 0 -> 1 albo odwrotnie, to zapisać w pamięci eeprom obecną wartość licznika (albo wysłać ją za pomocą rs232 do komputera albo jakoś inaczej udostępnić to dla świata zewnętrznego). Odpowie to na pytanie czy licznik nie "skacze" oraz czy faktycznie generowane jest to przez procek "świadomie"

Lepszego pomysłu nie mam bo wydaje się że jest to prawie nie możliwe aby to nie działało...

@wwojtek jakby było wywołane przerwanie od zerowania to pewnie było by widoczne zerowanie sygnału na obu liniach - też tam upatrywałem swojego kandydata

Hehe widzę, że nie tylko ja już zacząłem liczyć ile rozkazów procesora się mieści w tej szpilce A może by tak dodać sprawdzenie MCUSR na początku programu - można by wykluczyć resety procka.

@giciors Na Int0 podawany jest sygnał przyrostu z enkodera / generatora.
@rekon Zegar to 8MHz. Częstotliwość przyrostów P1 na Int0 to max 400Hz.
Jeśli chdzi o "sprawdzanie", o którym piszesz, to przyznam się, że nie czuję się na siłach.
@wwojtek Wydaje mi się, że resety procka można wykluczyć ponieważ po resecie licznik zawsze jest zerowany, natomiast przebiegi oglądane na oscyloskopie wyglądają cały czas prawidłowo (nie licząc szpilek oczywiście).

Wstaw poniższą funkcję do pliku main.c


dodaj deklarację funkcji oraz zdefiniuj obszar pamięci

no i na końcu pętli głównej programu dodaj wywołanie funkcji
sprawdz()

możesz wstawić 2 ledy które pokazałem w komentarzach dzięki czemu dowiesz się czy cokolwiek już złapał oraz czy już wypełnił całą pamięć

mam nadzieję że nigdzie się nie walnąłem - pisane na szybko
po wykonaniu takiego obiegu bierzesz np. mkavrcalculator i robisz odczyt eeprom i wstawiasz na forum (wiedz że najpierw będzie młodszy bajt a później starszy czyli odwrotnie niż jesteśmy do tego przyzwyczajeni)

Dzięki rekon, zaraz dopiszę i skompiluję program, ale testy to dopiero jutro wieczorem niestety.
Edit:
Program skompilował się bez błędów i wciśnięty do procka. Testy jak pisałem dopiero jutro. Ledów nie mogę dać ponieważ brak mi już wyjść.
Pozdrawiam, Arek

ooo to może nawet ktoś zdąży sprawdzić moje wypociny bo to drugi mój program używający eeprom - pierwszy działał nie najlepiej że się tak wyrażę ale zdaje się, że sam zapis miałem zrealizowany dobrze

Witam
Może to głupie ale już sam zgłupiałem, a może spróbuj nie podciągać pinów do zasilania a daj do masy w PORTB na początku i zobacz co się stanie.
Pozdrawiam