[gelöst] Eingangs-Interrupt mit MCP23017 Platine "IO Plus" abfragen

Begonnen von ThomasRamm, 17 Februar 2015, 10:32:06

Vorheriges Thema - Nächstes Thema

ThomasRamm

Hallo,
ich versuche mit der Platine IO-Pi-Plus bei änderung eines Eingang einen Interrupt auszulösen.
Ich habe die Beschreibung so verstanden das dies Möglich ist, bekomme es aber in FHEM nicht hin.
ZitatConfigurable interrupt source  - Interrupt-on-change from configured register defaults  or pin changes

Im Forum habe ich bereits diverse Diskussionen zum Chip MCP23017 diesbezüglich gelesen.
Eine Aussage war das man für jede Bank vom IntA eine Brücke auf einen GPIO Pin legen muss und dessen interrupt dann abfragen kann.
Ist das evlt. für die Platine auch notwendig? Dachte das wäre schon auf der Platine selbst so verdrahtet und muss nur aktiviert/korrekt abgefragt werden.
Wenn nicht, was genau muss ich bei dieser Platine tun? Bus 1 IA+IB + Bus 2 IA+IB verbinden und mit GPIO4 verbinden?

Schematische Zeichnung
Board Layout

Anbei noch ein Auszug aus deren Python Hilfsbibliothek, ich habe nur interne Definitionen kopiert die etwas mit interrupt zu tun haben:

# The GPINTEN register controls the interrupt-onchange feature for each pin on port A.
GPINTENA = 0x04
# Default value for port A - These bits set the compare value for pins configured for interrupt-on-change. If the associated pin level is the opposite from the register bit, an interrupt occurs.
DEFVALA = 0x06
# Interrupt control register for port A.  If 1 interrupt is fired when the pin matches the default value, if 0 the interrupt is fired on state change
INTCONA = 0x08
# The INTF register reflects the interrupt condition on the port A pins of any pin that is enabled for interrupts. A set bit indicates that the associated pin caused the interrupt.
INTFA = 0x0E
# The INTCAP register captures the GPIO port A value at the time the interrupt occurred.
INTCAPA = 0x10

intA = 0x00  # interrupt control for port a

Mario67

Hallo,

schaue Dir mal das Modul I2C_MCP23017 an (siehe dazu auch: http://forum.fhem.de/index.php/topic,23164.0.html). Damit hast Du eine sehr gute Unterstützung des MCP23017. Ich nutze es zusammen mit dem Modul RPII2C mit dem IO Pi 32 (ohne Plus). Die INTx-Pins würde ich niemals direkt elektrisch zusammen legen. INTA und INTB für Bank A und B eines MCP23017 kannst Du jeweils über das Attribut InterruptOut intern zusammenführen.
Um die Interrupt-Pins beider IC mit der "normalen" GPIO (z.B. mit dem Modul RPI_GPIO) zu erfassen, musst Du entweder 2 GPIO-Leitungen verwenden oder eine logische Verknüpfung davor schalten.


Gruß,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

ThomasRamm

Und wie wertest du sich ändernde Eingänge aus? Auch über gpio?

Mario67

Nein, die GPIO (bei mir 4 und 17 mit jeweils INTA|INTB) lösen nur jeweils ein notify aus. Gelesen werden dann alle in Betracht kommenden Eingänge (Chip 1 oder 2) mit Hilfe des Moduls I2C_MCP23017. Die Werte liegen beim entspr. Device ja schon als Reading vor.
Ungefähr wie im genannten Thread: Antwort #1 http://forum.fhem.de/index.php/topic,23164.msg164846.html#msg164846.

Gruß,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

ThomasRamm

ja das meinte ich, wie du den notify mitbekommst. das der Status der einzelnen Eingänge nach dem notify noch gelesen werden muss ist klar.

Gibt es einen technischen Grund warum du die IA von Bus1+Bus2 nicht zusammen auf einen GPIO legen würdest?
Oder gilt das einfach nicht als schick so etwas zu machen?

Ich überlege meine SPS durch Rpi und I2C Ein-/Ausgänge zu ersetzen und müsste zwei Karten verwenden, also 4 Chips und damit auch 4 GPIO für die Interrupts verbrauchen. Alle auf einen zu legen erscheint mir deshalb im Moment noch eine gute Idee zu sein.

PS: Danke schon mal für deine Rückmeldung, werde aufgrund deiner Antwort nicht mehr weiter nach interner Interrupt-Auswertung suchen, hatte das wohl auf der Seite missverstanden. Das spart Zeit und ich kann mich jetzt erstmal mit der nächsten Hürde (Programmieren einer Rolladenschaltung in FHEM) auseinandersetzen.

Gruß
Thomas

Mario67

Der Grund ist eher ein elektrischer als ein ästhetischer ;)
Stell Dir einfach vor, von den 4 zusammen geschalteten INTx-Pins haben 3 Low-Pegel und einer High-Pegel. Was liegt dann am GPIO-Pin an? Und was passiert mit den Treibern im MPC23017? Die 3 nicht aktiven Pins sind ja in dem Moment nicht hochohmig, sondern nehmen das jeweils als nicht-aktiv definierte Potential an.
Wenn man GPIO-Pins sparen muss, wäre es besser eine einfache ODER-Verknüpfung der 4 Signale durchzuführen (als CMOS z.B. mit dem 4072; da gibt es heute sicher noch mehr Optionen, bin da nicht ganz aktuell mit meinem Wissen..).
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

klausw

Zitat von: ThomasRamm am 17 Februar 2015, 17:12:35
Gibt es einen technischen Grund warum du die IA von Bus1+Bus2 nicht zusammen auf einen GPIO legen würdest?
Oder gilt das einfach nicht als schick so etwas zu machen?

Die Interruptausgänge sind beim Rest auf ActiveDriverOutput geschaltet. Was bedeutet, das sie dann im Fall eines Interrupts einen Kurzschluss gegeneinander machen können.
INTA und B zusammenzuschalten macht wie Mario bereits geschrieben hat sowieso keinen Sinn (die kannst du intern über das Attribut verknüpfen und somit musst du nur einen der beiden Pins nutzen).
Das zusammenschalten der Interruptausgänge mehrerer IC's wäre beispielsweise möglich, indem du sie mit Dioden entkoppelst. Allerdings solltest du beachten, das in diesem Fall bei jedem Interrupt alle IC's abgefragt werden müssen, was das System belasten kann. Wenn du genug GPIOs freihast dann nutze die Interruptausgänge am besten einzeln. Und bündle die Eingänge auf möglichst wenige IC's. Auch dadurch wird FHEM entlastet.

Zitat von: ThomasRamm am 17 Februar 2015, 17:12:35
PS: Danke schon mal für deine Rückmeldung, werde aufgrund deiner Antwort nicht mehr weiter nach interner Interrupt-Auswertung suchen, hatte das wohl auf der Seite missverstanden. Das spart Zeit und ich kann mich jetzt erstmal mit der nächsten Hürde (Programmieren einer Rolladenschaltung in FHEM) auseinandersetzen.
Der I2C ist nicht Interruptfähig daher gibt es keine modulinterne Lösung. Ohne GPIOs könnte man nur pollen, was aber auch keinen Sinn macht.

RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

ThomasRamm