Witam
Wyłączenie podwieszenia nic nie zmienia. Program z dopisaną funkcją sprawdz() rekona działał prawie godzinę i nie zawiesił się (a chyba powinien), więc może to nie ten trop? Zawartość eepromu:

eeprom z tego co widzę pusty - czyli albo ja się pomyliłem w pisaniu tego kodu sprawdzającego (co jest bardzo prawdopodobne) albo to co widzisz na wyjściu robione jest pomimo procesora (co byłoby bardzo ciekawe bo kiedy na wyjściu powinno być 0 a na oscyloskopie widzisz 1 to oznacza zwarcie ... i nie tak łatwo to zrobić bo procesor będzie z tym walczył pewnie do ok. 40 mA).
Wprowadziłeś do układu leda nr 1 (z komentarzy programu)? jeśli tak to czy się zaświecił w ogóle?

ale powiedziałeś że jak podłączysz generator 400 Hz do procka to też pojawiają się te szpilki- tak?
czy po wyjęciu całkowicie z układu i podłączeniu jedynie zasilania oraz generatora również widzisz te szpilki??

jeśli tak to można jeszcze spróbować jeszcze wywoływania programowo tego przerwania (timerem uruchamiać INT0 albo po prostu z timera zrobić sobie ok. 400 Hz) i testować tylko i wyłącznie sam procesor wraz z jego programem - sprawdziłbym to sam ale nie mam oscyloskopu
A tak w ogóle co masz w swoim układzie oprócz procka, jakiegoś zasilania, doprowadzeń od enkodera (sztuk 3? ) oraz wyjść (sztuk 2)??

kod do tego przerwania programowego (wywalasz przerwanie na int0 i zamieniasz je na poniższe) i wtedy procesor zostawiasz jedynie z oscyloskopem oraz zasilaniem nic innego


natomiast w mainie musisz to jeszcze skonfigurować zdaje się że tak (piszę pod Mega168 bo widzę że i tak jej używasz)



Bardzo bym prosił kogoś o sprawdzenie tego kodu - nie pisałem na ten procesor i aż wstyd się przyznać ale zapomniałem jak poprawnie zrobić CTC (ale wydaje mi sie że powinno działać tylko nie jestem pewien czy rejestr timera się wyzeruje po dojściu do OCR0A bo z tego co pamiętam należy ustawić do tego jakąś flagę, ale mogłem też wszystko pokręcić)

osobiście jeśli zadziała zacząłbym dodawać kolejne elementy i testować za każdym razem (możesz spróbować bisekcji )
jeśli okaże się że problem jest całkowicie niezależny od sprzętu czyli nie zadziała sam procesor z tym programem podłączony jedynie do zasilania oraz oscyloskopu to złożę własny układ na 2 procesorach testujący owo zjawisko

Aktualnie program testuję na płytce uruchomieniowej, w podstawkę włożony attiny85, taktowanie wewnętrzne 8MHz. Zamiast enkodera mam teraz podłączony generator (400Hz prostokąt symetryczny) na wejście P1, P2 zwarte do masy (czyli procek widzi enkoder z obrotami w prawo), wejście Z podłączone do switcha ale nie używane. Na podłączonym enkoderze jest dokładnie to samo tylko trzeba ośką kręcić. Procek włożony do stykówki - efekt identyczny.
Po odłączeniu generatora lub zatrzymaniu enkodera stan wyjść nie zmienia się i nie ma szpilek. Diody led nie mogłem podłączyć bo nie mam do czego.

Edit:
Przy podłączonym generatorze i zakomentowanej pętli głównej wyjścia są w stanie początkowym bez szpilek.

Edit 2:
Odnośnie przerwania Int0, to zastąpiłem je flagą sprzętową w/g Twojego pomysłu. Czy ten fragment zastąpić nowym?

ogólnie pomysł z przerwaniem programowym był taki żeby w programie zostało tylko pętla główna tak jak na początku była (z uwzględnieniem rad odnośnie "atomowych" operacji na liczniku lub wyłączaniem przerwań na ten krótki moment)
i jedynie co to przerwanie które napisałem wyżej (ale popraw je dla Twojego procka) wstaw zamiast zewnętrznego generatora

leda możesz podłączyć np. zamiast P2 lub zamiast Z skoro i tak ich nie używasz

edit. co do przycisku Z to jest on podciągnięty do VCC ? dobrze go podłączyłeś? ja się ostatnio na tym przejechałem - to nie powinno być przyczyną ale w tym problemie chyba już wszystko zostało sprawdzone przez dziesiątki oczu ...

Wejście Z jest podciągnięte do zasilania. Pomysł z wykorzystaniem P2 jako led zaraz zastosuję. Jeśli dobrze zrozumiałem, to (fajny) pomysł z flagą sprzętową wywalić a przywrócić przerwanie i atom?

Wydaje mi się, że w kodzie "sprawdzającym" autorstwa kolegi rekon jest mały błąd (ta wersja z epromem) - raz jest maskowanie PB, raz go nie ma:


Jeśli mogę zasugerować jeszcze jedną "ścieżkę" testową to byłoby to uruchomienie pierwotnego programu (tzn. z dodaną atomowością) i wykomentowanie wszystkich operacji na wyjściach (G1/2_H/L...). Potem stopniowe od-wykomentowywanie makr i obserwacja czy dzieje się coś ciekawego. Może wyjdzie jakaś nowa zależność.

Ok, zaraz to "przećwiczę"

I jeszcze coś mi przyszło do głowy - nie kompilujesz tego z jakimiś egzotycznymi opcjami gcc ?

------------------------ [ Dodano po: 6 minutach ]

Typ licznika dla świętego spokoju zmieniłbym na uint16_t.

Typ licznika zmieniłem a z opcji gcc to zmieniałem tylko typ optymalizacji ale to nic nie pomagało.

Nie chcę zapeszać ale wygląda na to, że problem został rozwiązany Rozwiązaniem okazało się wprowadzenie przez kolegę wwojtek operacji atomowej. Prawdopodobnie pomysł kolegi barney też przyniósłby sukces.Pomysł podany przedwczoraj, dlaczego sukces dopiero dzisiaj? Wyjaśniam:
Niestety, z mojej winy żadna z propozycji nie została sprawdzona. Otóż na potrzeby wprowadzania proponowanych zmian stworzyłem w oryginalnym projekcie kopię pliku .c z nową nazwą i tam wprowadzałem zmiany. Okazało się, że kompilator cały czas korzystał z pliku oryginalnego (nie zmienianego) - dlatego cały czas pisałem, że nic się nie zmieniło. Pomyłkę tą odkryłem przypadkowo, przy pośrednim współudziale wwojtka, który zaproponował zakomentowanie makr generujących przebiegi wyjściowe. Zdziwiłem się, że po zakomentowaniu pierwszego makra nadal mam na wyjściu oryginalne sygnały no i zacząłem szukać.
Bardzo Wszystkich przepraszam za zamieszanie i wprowadzanie w błąd. Chcę też bardzo serdecznie podziękować Wszystkim uczestnikom tej dyskusji za okazaną bezinteresowną pomoc i wyrozumiałość. Jestem pod wrażeniem Waszej wiedzy i widzę, że przede mną jeszcze bardzo dużo nauki, ale mam nadzieję, że też kiedyś będę potrafił pomóc. Pozdrawiam, Arek

No i jest happy end A już przyniosłem sobie stykówkę z piwnicy żeby zrobić podobny układ

Ze swojej strony chciałem jeszcze zwrócić uwagę, że kolega avrek... jakby to powiedzieć... przyłożył się do opisania problemu i poszukiwań rozwiązania. Przypuszczam że liczenie zboczy, znalezienie zależności z "resztami" to nie był taki hop siup. Do tego opisane oscylogramy. Bomba! Miło się szuka rozwiązania kiedy wszystkim zależy na znalezieniu problemu.

Dziękuję za miłe słowa. Program ostatecznie przetestowany i wszystko jest OK! Jeszcze raz dziękuję wszystkim za pomoc. Myślę,że temat do zamknięcia.
Pozdrawiam, Arek