Attiny1606 - przerwanie załącza się bez względu na stan przycisku.

[ethanak]

To sprawdź co się dzieje na tym wejściu. Być może występują jakieś szpilki - debouncing odpowiednio oprogramowany też pomoze (np. minimalny czas wciśniecia klawisza to 100 msec)

Edytowano Czerwiec 4, 2023 przez ethanak

[JammyCrazy]

W normalnym funkcjonowaniu ten debouncing zlikwidowałem programowo. Tylko że przerwań nie da się opisać minimalnym czasem klawisza czy czymś podobnym. Wykrywa zmianę stanu na wejściu, uruchamia przerwanie i wybudza MCU, nie ważne czy to była 1ns czy 100ms. Próbowałem zmniejszyć częstotliwość zegara działającego w trybie Standby do minimum, żeby częstotliwość próbkowania była mniejsza. Też nic.... 

[ethanak]

Oj tam, się nie da to parasola w d... otworzyć.

Przewanie będzie wywołane, ale czy musisz na nie zareagować?

 

[JammyCrazy]

1 minutę temu, ethanak napisał:

Oj tam, się nie da to parasola w d... otworzyć.

Przewanie będzie wywołane, ale czy musisz na nie zareagować?

 

Cechą przerwania jest to, że od razu (nie licząc paru cykli zegarowych) wybudza MCU, czy tego chcę czy nie. Próbowałem robić pętlę typu "dopóki długość klawisza < x to uśpij()", ale pobór spadł o jakieś marne 50uA. 

Edytowano Czerwiec 4, 2023 przez JammyCrazy

[ethanak]

No to wybudzi, a kontroler sprawdzi co ma z tym zrobić. Przecież to nie durny przekaźnik, a procesor!

[JammyCrazy]

1 minutę temu, ethanak napisał:

No to wybudzi, a kontroler sprawdzi co ma z tym zrobić. Przecież to nie durny przekaźnik, a procesor!

Cholewka jasna. Chodzi o to, że MCU się wybudza od razu, BEZ WZGLĘDU na to, czy wcisnąłem guzik, czy też nie. Po prostu wykrywa jakieś sygnały z powietrza jako zmiany stanu na wejściu i uruchamia przerwanie, które z kolei wybudza MCU. Jak mam te sygnały zredukować?

[ethanak]

Tak jak pisałem - odrzucenie szpilek.

Poza tym coś masz spaprane w kabelkologii, masz tam jakiś układ rc na wejściu?

[JammyCrazy]

Nie da się odrzucić szpilek w tym przypadku, bo kontroler przerwań wykrywa wszystko i nieważne czy to szpilka, czy to zamierzony sygnał.

W wersji 2.0 planowałem wsadzić właśnie filtr RC na wejściu. Tylko nie wiem czy coś jeszcze... Wolałbym jednak nie musieć podchodzić do tego 3 raz przez jakąś pierdołkę.

Edytowano Czerwiec 4, 2023 przez JammyCrazy

[ethanak]

Coś wspominalem o parasolu?

Możesz odróżnić po czasie trwania szpilke od prawidłowego sygnału?

[JammyCrazy]

 

5 minut temu, ethanak napisał:

Możesz odróżnić po czasie trwania szpilke od prawidłowego sygnału?

Nie w przypadku przerwań. Dla kontrolera sygnał to sygnał. Najpier wybudza MCU, później mogę sprawdzić czy sygnał był prawidłowy.

[_LM_]

Wypróbuj może to https://alexandria.atmel.com/

[JammyCrazy]

Kod pisałem czytając co chwilę datasheet (atomic to wyjątek). I to po kilka razy dla pewności. Znam bity i rejestry konfiguracyjne, jak ustawić zegar główny, dzielniki itp. Problem jest taki, że przerwanie PORTA_PORT_vect powinno być uruchamiane wtedy i tylko wtedy, gdy przycisk jest wciśnięty, puszczony lub jedno i drugie, w zależności od rejestru PORTA_PIN1CTRL. TYMCZASEM u mnie przerwanie to jest aktywowane co (dosłownie) nanosekundę. Program pokazuje mi, że przerwanie zostało wykonane 10000 razy (wartość ta rośnie bardzo szybko), gdzie powinno wynosić 0, bo nie nacisnąłem przycisku ani razu. 

Edytowano Czerwiec 4, 2023 przez JammyCrazy

[ethanak]

Takie głupie pytanie: przerwanie od pinu możesz ustawić na pięć sposobów: zbocze (rosnące, malejące, dowolne) i stan (wysoki, niski). Na pewno masz przerwanie ustawione na zbocze a nie stan? Nic innego mi do głowy nie przychodzi, ale wygląda to na błędnie ustawione przerwanie.

[JammyCrazy]

Tak jak wspomniałem wcześniej: efekt jest taki sam dla ustawień na zbocze malejące, dowolne i na poziom. Dla zbocza rosnącego przycisk w ogóle nie reaguje.

[ethanak]

1 minutę temu, JammyCrazy napisał:

Dla zbocza rosnącego przycisk w ogóle nie reaguje.

Czyli gdzieś robisz błąd, bo powinno.