GPIO26 Interrupt on the Sixteen LV Digital Input hat with Python 3

morrisonj

New member
I'm having trouble using the interrupt feature on a new v3.0 Sixteen LV Digital Input hat (https://sequentmicrosystems.com/products/16-universal-inputs-card-for-raspberry-pi) with Python 3. Here's my code:

Python:
import RPi.GPIO as GPIO
import time


# Pin setup
GPIO.setmode(GPIO.BCM)  # Use BCM pin numbering
pin = 26 # GPIO26 according to docs.
GPIO.setup(pin, GPIO.IN, pull_up_down=GPIO.PUD_UP)  # Set pin as input with pull-up resistor


# Callback function to run on pin state change
def gpio_callback(channel):
    print(f"GPIO {channel} state changed!")


# Add event detection on the pin
GPIO.add_event_detect(pin, GPIO.BOTH, callback=gpio_callback, bouncetime=200)


try:
    print("Waiting for GPIO events...")
    while True:
        time.sleep(1)  # Keep the program running
except KeyboardInterrupt:
    print("Exiting...")
finally:
    GPIO.cleanup()  # Clean up GPIO settings

The interrupt triggers when I press the onboard button but not when one of the inputs change state. I have a few 24v powered switches connected to inputs 14,15 and 16 on the hat and they function as expected when I switch them and read the input with "16inpind 1 rd 14" etc... They'll output 0 when off and 1 when on.

If it makes any difference I have a sixteen relay hat (early version 1 perhaps) set to id 0 also connected to the Pi. the sixteen LV digital hat is set to id 1. I originally tried to get this working with a different v1.0 input hat and couldn't so I upgraded to the v3.0 board in case that was the issue.

Can anyone spot anything obvious I'm doing wrong or does anyone have any suggestions? Thanks in advance.
 

TonyD

Member
Giday Mate
Sequent cards are fantastic & at present are only setup to interrupt from the push button on the side of the card.
Your python script is OK
It would be a nice feature if the cards did issue an interrupt with change of state from selected cards & the end user system & could select which cards in there system will generate a change of state interrupt then you would only need to poll the cards to find which one generated an interrupt. But the only caveat there is if you had a lot of cards it could get very interrupt busy & possible get hung in interrupt loops.
I have found that i run timers for how often i poll the cards because my use is the inputs don't change very often

Sequent can chime in & confirm for U
Cheers Tony
 

alexburcea

Moderator
Staff member
Hi,

This feature will be present in the next firmware version which I hope we will release in a couple of days.
Thank you for using our cards.

Alex.
 

alexburcea

Moderator
Staff member
Hi,

A new firmware version has been released and a new 16inpind command is available.
Check the Readme for the firmware update. Update the repo and reinstall the command.

The command 16inpind has two new options "optintrd" and "optintwr" which can be used to enable/ disable interrupt generation for individual inputs, respectively to read the interrupt enable status.
When interrupt is enabled for specific inputs, will trigger (pull the GPIO26 low for 15ms) when the input state is changed.

Please give it a try and report any errors.

Alex.
 

TonyD

Member
Giday Alex
Thanks for the update to this card
Have done the update to the 16inpind card which was at address 1 before the update all went through no problems
After the update64 the cards now has an ID 7 . i was expecting the ID to stay at 1

Tony
 

TonyD

Member
Hi Alex
I just tried to do a fresh install & this is what happened

pi@Rpi-BatteryRm:~/16inpind-rpi $ sudo make install
[Compile] src/16in.c -> build/16in.o
[Compile] src/board.c -> build/board.o
[Compile] src/cli.c -> build/cli.o
[Compile] src/comm.c -> build/comm.o
[Compile] src/led.c -> build/led.o
[Compile] src/opto.c -> build/opto.o
src/opto.c: In function 'optoEdgeGet':
src/opto.c:97:9: warning: 'memcpy' reading 2 bytes from a region of size 0 [-Wstringop-overread]
97 | memcpy(&falling, &buf[2], 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/opto.c:89:17: note: at offset 2 into source object 'buf' of size 2
89 | uint8_t buf[2];
| ^~~
src/opto.c: In function 'optoEdgeSet':
src/opto.c:123:9: warning: 'memcpy' writing 2 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
123 | memcpy(&rising, buf, 2);
| ^~~~~~~~~~~~~~~~~~~~~~~
src/opto.c:121:17: note: destination object 'rising' of size 1
121 | uint8_t rising = 0; //buf[0];
| ^~~~~~
src/opto.c:124:9: warning: 'memcpy' writing 2 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
124 | memcpy(&falling, &buf[2], 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/opto.c:122:17: note: destination object 'falling' of size 1
122 | uint8_t falling = 0; //buf[1];
| ^~~~~~~
src/opto.c:144:9: warning: 'memcpy' reading 2 bytes from a region of size 1 [-Wstringop-overread]
144 | memcpy(buf, &rising, 2);
| ^~~~~~~~~~~~~~~~~~~~~~~
src/opto.c:121:17: note: source object 'rising' of size 1
121 | uint8_t rising = 0; //buf[0];
| ^~~~~~
src/opto.c:145:9: warning: 'memcpy' reading 2 bytes from a region of size 1 [-Wstringop-overread]
145 | memcpy(&buf[2], &falling, 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/opto.c:122:17: note: source object 'falling' of size 1
122 | uint8_t falling = 0; //buf[1];
| ^~~~~~~
[Compile] src/rs485.c -> build/rs485.o
[Compile] src/wdt.c -> build/wdt.o
[Link] build/*.o -> 16inpind
[Install] /usr/local/bin/16inpind
pi@Rpi-BatteryRm:~/16inpind-rpi $


Any thoughts

Tony
 

alexburcea

Moderator
Staff member
Please update the repo and try again to install it.
There was some bugs but I do not understand why I did not get the compiling errors.
I dive into the firmware issue and get back.
 

TonyD

Member
Hi Alex
The compile works now & copies to python area without any dramas
but the board shows at address 7 when it should be 0 because i have a SSR card configured at address 1 16relind-rpi
& the 2 clash if at the same address hence 0->16inpind & 1->16relind-rpi
Any query from the card using address 7 from cmd line returns garbage 0 when inputs are 1 or in python returns errors re address.

pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind -list
2 board(s) detected
Id: 7 0
pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind 0 ledrd
Fail to read!
pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind 7 ledrd
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
pi@Rpi-BatteryRm:~/16inpind-rpi $


TonyD
 

alexburcea

Moderator
Staff member
I think you updated the 16-relays card with the firmware of the 16-inputs.
Could you connect one card at the time and do the proper update?

Alex
 

TonyD

Member
Alex
I thought that as well so i looked at the commands that i had used & were to the 16input card.
That still doesn't explain why the address for the input card is now 7 instead of 0. & the input card returns all 0 when queried from cmd line using address 7 which is incorrect according to the dip switches

Just as a try i tried to update the 16 input card using the address of the 16output card & the update64 did not work because it could not find a input card at that address

This is the delima i am in at present i have a non functioning input card that i cannot address
see below what i have tried so far
bearing in mind the input card is dip switch 0 & the output card is dipswitch 1


pi@Rpi-BatteryRm:~/SBMS $ cd /home/pi/16inpind-rpi/update
pi@Rpi-BatteryRm:~/16inpind-rpi/update $ ./update64 0 "This is the proper dipsw address for the input card"
You are ready to update the firmware on your board.
Your Raspberry Pi must be connected to the internet.
We strongly recommend to disconnect all outputs from the board since they can change state unpredictably.
Type "yes" (without quotes) to continue or anything else to quit:
yes
Bootloader no answer!!!

pi@Rpi-BatteryRm:~/16inpind-rpi/update $ ./update64 7 "This is the address the cmd line returns when querying the input card"
You are ready to update the firmware on your board.
Your Raspberry Pi must be connected to the internet.
We strongly recommend to disconnect all outputs from the board since they can change state unpredictably.
Type "yes" (without quotes) to continue or anything else to quit:
yes
Bootloader no answer!!!

pi@Rpi-BatteryRm:~/16inpind-rpi/update $ ./update64 1 "This is the proper dipsw address for the output card"
You are ready to update the firmware on your board.
Your Raspberry Pi must be connected to the internet.
We strongly recommend to disconnect all outputs from the board since they can change state unpredictably.
Type "yes" (without quotes) to continue or anything else to quit:
yes
Bootloader no answer!!!

pi@Rpi-BatteryRm:~/16inpind-rpi/update $


if i inadvertently updated the output card with the input card i dont have a update64 for the output card to down load the firmware for the output card

I am unable to do any more today will have to remove from production & disassemble & try individually tomorrow.

What iam am going to try tomorrow is configure the dipswitches on the input card to address 7 & then try & down load the firmware to the input card & see if that works & then change back to address 0


Tony
 

alexburcea

Moderator
Staff member
It is exactly what I thot, you updated the 16relays card wich was at stack level 0 with the 16inputs firmware by running "update64 0" you should run "update64 1" but disconnect other cards from the raspberry and make sure no program uses the I2C port in the update period.
I know it might be hard to remove the cards because of your wiring but please use a single card connected to the raspberry while making update.

I will create update64 for the 16relays also. You must set the stack level to 7 from the dipswitches on the 16relays because the wrong firmware can not compute the stack level correctly but the bootloader does so these two must match.
 

alexburcea

Moderator
Staff member
The update64 for the 16relays is on the 16relind-rpi/ repository. Please update the 16relays card setting to stack level 7 and let me know the results.
Do the update with a single card connected to the Raspberry and make sure no script, program, node-red, etc, use the I2C port during the update
 

TonyD

Member
Hi alex
I have check all cards & confirmed there addresses. I have also checked the cards are working correctly one at a time with the RPi5 & all cards work correctly except for the 16opto isolatedtLV card. I have tried all addresses for the input card & i get the same result from all addresses configured on this card. What i am getting when accessing the input card from cmd line

pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind -list
1 board(s) detected
Id: 1

pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind 1 rd
65535

pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind -h ledrd
ledrd Display the state of general purpose LEDS on the card
Usage 1: 16inpind <id> ledrd <led[1..16]>
Usage 2: 16inpind <id> ledrd
Example: 16inpind 0 ledrd 2 Get the state of #2 on board #0
pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind 1 ledrd 1
Fail to write!

pi@Rpi-BatteryRm:~/16inpind-rpi $ 16inpind 1 ledrd
Fail to read!


Above is the extent of any success accessing the input board after updating the input card firmware yesterday
I have attempted to update the Card firmware using every address to no success. Below is the response when trying to update the firmware.

pi@Rpi-BatteryRm:~/16inpind-rpi/update $ 16inpind -list
1 board(s) detected
Id: 1

pi@Rpi-BatteryRm:~/16inpind-rpi/update $ ./update64 1
You are ready to update the firmware on your board.
Your Raspberry Pi must be connected to the internet.
We strongly recommend to disconnect all outputs from the board since they can change state unpredictably.
Type "yes" (without quotes) to continue or anything else to quit:
yes
Bootloader no answer!!!

My post yesterday showing the different address used was to show that if the wrong address was used your update64 program prevented trying to upload the firmware to an incorrect board. i.e. trying to load 16lvinput firmware to the 16lvrelay card. your update program will not let that happen. So as far as loading the wrong firmware to the wrong card that just did not happen.


Regardless i still have a non functioning 16lvopto isolated card that i cannot use. Any suggestions to fix my situation ???

I think i may have the reason why i am having difficulties my card is version 1.0 & i see on your web that you are now selling version 3.0 & i guess the new firmware is not back wood compatible. I have no idea how i ended up with a version 1.0 when i purchased March 11 2024 order SH5376 & a version 1.0 delivered & now you are selling V3.0 nine months later & i guess V2.0 had a very short life span

Anyway how do get access to the correct firmware for the V1.0 card i have.

Regards Tony
 

alexburcea

Moderator
Staff member
Hi Tony,
Are you sure that you have not updated the 16-relays with the firmware of the 16-inputs?
For the card that was not updated, things are clear, the v1.0 has an ioexpander, not the processor, and is not updatable.
A little history here: Both 16-relays and 16-inputs initially was made with the same IOExpander type, once we decided to use a microcontroller instead, we kept the I2C address scheme and the internal registers to be compatible with the older versions. This comes with some problems regarding the software not knowing (or is not efficient to query) which card is connected.
 

TonyD

Member
Alex
Positive i did not update the 16-relay with the 16-input because when i had the system apart i tested every card individually both from cmd & python.
The 16 LV-input card is the only one that is not functioning which is the one i tried to update both the cmd line build & the firmware on the card that's when al my problems started. How do i go about getting the card working correctly

Tony
 

alexburcea

Moderator
Staff member
Let's see what is wrong with the card, I see you send a led command which does not work for this card because the LED's are controlled directly from the inputs.
Stick with the "read" command because is the only one that work on the v1 card.
 

TonyD

Member
Giday Alex
Thanks for all your help I have ordered a Version 3 input card because i am interested in using the interrupt change of state & have decided to use the ver 1 card in another system.
Will the python docs be updated soon re the change of interrupt.
again thanks for all your help

Cheers Tony
 

alexburcea

Moderator
Staff member
Hi,

I have done nothing on the Python yet, but once the interrupt is enabled (with the command line), it remains enabled also after you cycle the power.
There are a few more functionalities to be implemented in the firmware, one of them is to read the input frequency, and another is to change the behavior of the LEDS which now copies the inputs.
Let me know the progress.

Alex.
 
Top