Mam być może banalny problem.
Steruję via I2C expanderem MCP-23017.
Podłączyłem go do mega 2560. Generalnie komunikację nawiązałem i układ działa, ale jest jedno ale.
Kiedy ustawię w rejestrach INTCONn aby przerwanie było generowane na stan pinu przeciwny (w/g dokumentacji wtedy przerwanie jest generowane na oba zbocza czyli naciśnięcie i puszczenie przycisku) to wszystko jest OK. Przerwanie podłączone do procka jest wymuszane i da się je obsłużyć i wyczyścić aby potem odebrać kolejne. Licznik klikania doszedł do setki więc uznałem że jest OK.

Inaczej jest kiedy zmienię INTCONn aby przerwanie generowało się kiedy pin portu wejściowego przybiera stan przeciwny niż ten określony w rejestrze DEFVALn .
Wtedy przerwanie wykonuje się tylko raz, pin INTA czy INTB ustawia się na "0" i niestety trwa tak w nieskończoność, mimo że zgodnie z dokumentacją Odczytuje rejestr GPIOn i/lub INTCAPn co powinno w jednym i drugim przypadku wyzerować przerwanie i przygotować je do następnego użycia. Sprawę rozwiązuje dopiero zapis do rej. OLATn wartości 1 na odpowiednim bicie.

Próbuję już drugą noc i nic. Może ktoś ma doświadczenie z tym Expanderem.

Oba porty A i B ustawiam na wejścia na które podłączony jest transoptor shmidta z pullup-em.
SDA i SCL mają pullup 4,7k reset 1k a INTA i INTB także po 1k.

Steruje Mirkową wersją magistrali I2C, a wartości odczytywane z rejestrów są prawidłowe.

Proszę o pomoc

_________________
... Ardua prima via est ... Errare humanum est ...

Problem rozwiązałem (a właściwie mój kolega Michał - dzięki Michał)

Cały układ MCP23017 działa poprawnie z tym przerwaniem przy porównywaniu z rejestrem DEFVAL. Proszę spojrzeć do noty rozdział 1.7.5 rysunek 1.7 strona 25.

Cały problem polega na tym, iż konstruktorzy tego układu go tak zaprojektowali, że po wywołaniu przerwania ono "trwa" dopóki trwa stan który je wywołał. Dlatego odczyt GPIO czy INTCAP (zaznaczone na rysunku przerywaną linią) w pierwszym i trzecim przypadku kasuje przerwanie. Inaczej jest w drugim przypadku, gdzie odczyt tych rejestrów przypada na stan niski portu GP2, które to przerwanie wywołało. W takim przypadku przerwanie nie będzie wyzerowane.

Ja obsługuję akurat klawisze, więc po ich naciśnięciu nie mam szans odczekać na ich zwolnienie gdy pojawi się przerwanie.
Ot cała przyczyna.
Pracuję nad rozwiązaniem, ale kiedy już znam przyczynę będzie łatwiej.

_________________
... Ardua prima via est ... Errare humanum est ...