MCP23008 Interrupt Flags nicht wie im Datenblatt?

[Hilfe (Gast)]

Hat jemand erfahrung mit einem MCP23008?

Ich nutze den Chip ausschließlich mit Pullups um Taster per interrupt ab 
zu fragen.

Sobald der Chip einen Interrupt meldet und der µController Zeit hat 
werden die Register INTF und INTCAP abgefragt .. dies funktioniert und 
zeigt mir in INTF immer den auslösenden Pin an... so lange nur ein 
Interrupt in der Zwischenzeit aufgetreten ist.

Laut Datenblatt sollte es gehen, dass mehrere Interrupts ausgelöst und 
in INTF festgehalten werden bevor diese gelesen werden.

Ich habe das Problem, dass INTF immer nur das Bit für den ersten 
Interrupt hat und keine weiteren.
Übersehe ich etwas im Datenblatt?
https://ww1.microchip.com/downloads/en/DeviceDoc/21919e.pdf

Was könnte ich falsch machen?

[c-hater (Gast)]

Hilfe schrieb:

> Was könnte ich falsch machen?

Du benutzt beim Empfänger einen falschen Interrupttyp. Um potentiell 
kaskadierende Interruptanforderungen eines externen Device bearbeiten zu 
können, braucht man einen Level-Interrupt (denn das externe Device wird 
eben diese Art der Signalisierung notgedrungen verwenden müssen). Und 
einen Interrupthandler (AKA: ISR), der damit korrekt umgehen kann.

Sprich: ein gut Teil der StateMachine muss in der ISR implementiert 
werden.

[Hilfe (Gast)]

Beim Empfänger polle ich den Interrupt pin des MCP per digital Eingang 
um nicht dauernt den I2C zu belegen.

Eine direkte Abfrage des MCP in einer ISR geht nicht, da der I2C in dem 
moment gerade belegt sein könnte.

Das aufzeichnen der verschiedenen Interrupts sollte der mcp eigentlich 
machen können. Es ist mir nicht wichtig, in welcher Reihenfolge die 
interrupts kommen (das lässt sich aus den Pegel des ersten Interrupts 
rekostruieren). Es ist mir wichtig zu sehen, welche interrupts statt 
gefunden haben.

[Christian S. (roehrenvorheizer)]

Hallo,

in INTF sollen alle Pins angezeigt werden, die einen IRQ auslösen 
können.

In INTCAP bleibt bei jedem auftretenden IRQ der Inhalt so lange 
erhalten, bis der IRQ gelöscht wird. Bei mehreren ändert sich da 
anscheinend nichts.
Also sollte man auf jeden IRQ sofort reagieren und nicht warten, bis 
mehrere Änderungen aufgetreten sind.

> Laut Datenblatt sollte es gehen, dass mehrere Interrupts ausgelöst und in INTF 
>festgehalten werden bevor diese gelesen werden.

Laut DaBla ja. Aber ob der Chip das gelesen hat?

"The first interrupt event will cause the port contents to be copied 
into the INTCAP register. Subsequent interrupt conditions on the port 
will not cause an interrupt to occur as long as the interrupt is not 
cleared by a read of INTCAP or GPIO."

MfG

[Hilfe (Gast)]

Eigentlich sollten in INTF alle Pins angezeigt werden, welche einen 
interrupt state hatten (bis gelöscht durch lesen von INTCAP oder GPIO).

"Note:INTF  will  always  reflect  the  pin(s)  thathave an interrupt 
condition. For example,one pin causes an interrupt to occur and 
iscaptured  in  INTCAP  and  INF.  If  beforeclearing the interrupt 
another pin changes,which would normally cause an interrupt, itwill be 
reflected in INTF, but not INTCAP."

[Christian S. (roehrenvorheizer)]

Genau, es soll anscheinend kein zweiter IRQ ausgelöst werden, wenn sich 
mehrfach Pins ändern.

MfG

[Hilfe (Gast)]

Korregiere mich wenn ich falsch liege:

Es soll kein zweiter Interrupt ausgeführt werden, da der erste noch 
anliegt.
Es soll das entsprechende Bit in INTF gesetzt werden
Es soll INTCAP nicht erneut aktualisiert werden

Mein Problem:
Wenn ich in eienr Dauerschleife INTF auslese (ohne den Interrupt zu 
löschen) ändert sich INTF nicht durch das anliegen (nicht auslösen) 
weiterer Interruptzustände.

[Hilfe (Gast)]

Ich habe jetzt eine Stellungnahme von Microchip erhalten:

"Your inquiry regarding the MCP23008 only storing the first interrupt in 
the INTF register has been asked in our support que by several different 
customers in the past. This is the response provided from the business 
unit in charge of this device:
The behavior you are seeing is actually the correct behavior, i.e. the 
expander does not accumulate interrupts if not cleared. The note you are 
referring to is actually an error in the data sheet our apps team found 
just recently. The data sheet has been marked for correction and this 
note will be removed. We apologize for the confusion."