Hallo,
ich versuche mit der Platine IO-Pi-Plus (https://www.abelectronics.co.uk/products/17/Raspberry-Pi--Raspberry-Pi-2-Model-B/54/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 (https://www.abelectronics.co.uk/docs/stock/raspberrypi/iopiplus/IOPi-schematic.pdf)
Board Layout (https://www.abelectronics.co.uk/docs/mechanical-drawings/io-pi-plus-mechanical.png)
Anbei noch ein Auszug aus deren Python Hilfsbibliothek (https://github.com/abelectronicsuk/ABElectronics_Python_Libraries/blob/master/IOPi/ABE_IoPi.py), 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
Hallo,
schaue Dir mal das Modul I2C_MCP23017 an (siehe dazu auch: http://forum.fhem.de/index.php/topic,23164.0.html (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
Und wie wertest du sich ändernde Eingänge aus? Auch über gpio?
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 (http://forum.fhem.de/index.php/topic,23164.msg164846.html#msg164846).
Gruß,
Mario
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
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..).
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.
Danke für die Infos und eure Unterstützung.