Support Forum

Share your projects and post your questions

Register   or   Sign In
The Forum

CLI reading

1398 Views - Created 25/01/2019

25/01/2019

Posted by:
moron

moron Avatar

Hello

I've got 2 x IOPI's which I've bought to test, with a view to using more of them (and probably the plus versions) in a smart home setup later down the line.

At this stage all I'm doing is taking some of the different input pins high/low and checking that I can deal with that at the software end. I've enabled the pull up resistors and I've got momentary pushbuttons which pull the IOPI inputs to ground. So I've also enabled the invert so I get a 1 for pushed button and 0 for unpushed.

When I use the example Python script to read each pin and display the output, everything is working absolutely fine (so I believe there's no hardware issues).

When I use the CLI iopi utility which I've compiled on the Raspberyy Pi, everything seems OK when I read each pin individually.

But it's not quite working as expected when I try and read the port and use '-b' to get the output in binary.

It struck me that it's probably my understanding of how it works that's wrong!

This is what I think: The IOPI has got two ports, each with 8 inputs. I can read ports 1-8 using 'iopi -a 0x20 -p 0 -r -b' and this will give me a binary output representing the state of the first 8 pins. If I repeat with '-p 1' this will give me the same for pins 9-16.

Have I understood that right? Please confirm either way and then I'll respond with my problem if I still think there is one!

Thanks

25/01/2019

Posted by:
andrew

andrew Avatar

Location:
United Kingdom

andrew Twitter  andrew Website  

Hello

The way you are using the iopi utility is correct. What is the problem you are having?

25/01/2019

Posted by:
moron

moron Avatar

OK thank you.

I've spent a bit more time on it so I've got a clear set of repeatable steps and here they are.

I've got the IOPI plugged into a Pi Zero and I have absolutely nothing connected to the IOPI.

I run the demo_ioread.py script from your examples and I can see that all the pins 1-16 are set high (because the pullups are enabled). I can move a jumper connected to ground along the pins, and I can see each switching to low as I do. This is behaving exactly as I expect it to do.

Moving onto the CLI utility, with absolutely nothing plugged into the IOPI this is the output I'm getting:


pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 0 -r -b
0b11111111
pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 1 -r -b
0b11111111


So, again, everything working as it should.

I then connect pin 1 to ground and:


pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 0 -r -b
0b11111110
pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 1 -r -b
0b11111111


So that's doing exactly what I expect as well. And if I disconnect pin 1 from ground, it reverts to the correct expected output of 0x11111111.

Here's where it goes funny (or where I've messed it up). I now run these two commands to enable the invert so I can ultimately get a 1 when the pin is grounded and a 0 when not:


pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 0 -i 1

pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 1 -i 1


I now read both ports with nothing connected:


pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 0 -r -b
0b11111110
pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 0 -r -b
0b11111111


For me both commands should be giving me 0x00000000 but they aren't.

After a bit of tinkering around I realised that if I connect pin 1 to ground and repeat:


pi@raspberrypi:~/iopi/cli/ABElectronics_CLI/iopi_c $ ./iopi -a 0x20 -p 0 -r -b
0b11111111


So to cut a long story short, it seems to me that when I'm asking the CLI to invert the port (ie invert all the pins on the port), it's only inverting the first pin.

Hope that makes sense, sorry for the long winded post.

Is it me that's using it wrong?

Thank you.

25/01/2019

Posted by:
andrew

andrew Avatar

Location:
United Kingdom

andrew Twitter  andrew Website  

When inverting a port you need to provide a value between 0 and 255 like you would with setting the direction. This allows you to invert some pins while leaving others non-inverted. At the moment where you are using 1 as a value that will only set the first pin on the port to be inverted.

What you will need to do is set a value of 255 or 0xFF to set all of the pins as inverted. Try running the following commands and see if it works correctly.


./iopi -a 0x20 -p 0 -i 0xFF
./iopi -a 0x20 -p 1 -i 0xFF

25/01/2019

Posted by:
moron

moron Avatar

AHA... That explains it, thank you very much.

25/01/2019

Posted by:
moron

moron Avatar

If I may ask one more question please... The goal here is to have a Pi monitoring a max of say 64 pins from IOPIs and to be able to react accordingly when one changes. They will be linked to momentary push buttons rather than latching.

What would be the "best" way to do that, should I be using interrupts or would it be perfectly fine to just continually read in the state of the pins in batches of 8 looking for a change?

Thanks

25/01/2019

Posted by:
andrew

andrew Avatar

Location:
United Kingdom

andrew Twitter  andrew Website  

Ideally, the best way to monitor for button presses would be to use the interrupts. That way you don't have to check the state of each IO Pi as often and it will record a press that occurs between checks.

If you want your program to be event-driven, reacting to button presses when they occur, you could connect the interrupt IA and IB pins on the IO Pi to the GPIO header via a voltage divider to drop the 5V down to 3.3 and then use the interrupt hardware built into the GPIO pins. That way an interrupt event on the IO Pi would trigger the interrupt on the GPIO header, calling a function to check each IO Pi and see what button was pressed.

25/01/2019

Posted by:
moron

moron Avatar

Thanks for the info, much appreciated.

Sign in to post your reply

Note: documents in Portable Document Format (PDF) require Adobe Acrobat Reader 5.0 or higher to view, download Adobe Acrobat Reader or other PDF reading software for your computer or mobile device.