Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPIO/Button events not working in PiFace implementation/sample #53

Closed
savageautomate opened this issue Oct 3, 2013 · 4 comments
Assignees
Labels
bug
Milestone

Comments

@morind79

This comment has been minimized.

Copy link

@morind79 morind79 commented Oct 3, 2013

Hi Robert,

Well it helped me, but not completely. Let me explain what I did.
I have a MCP23017 (I2C) on which GPIOB6 and GPIOB7 are set as input.
On these GPIOs, there is buttons.

At the beginning the state of these buttons is unknown, so I read them in my program.
To make test I set them like this B6=false and B7=true.

On my Java program, I just made a loop that read the status of these buttons every 2 seconds.

The result is always the same :

B6=false
B7=false

But if I leave my program runing and change state of one button (B6 for example) then everything is correct.

Really weird.

So using the information you gave me, I added this to my code before the loop :

I2CBus bus = I2CFactory.getinstance(I2CBus.BUS_1);
I2CDevice device = bus.getDevice(0x21);
device.write((byte)0x09, (byte)0xFF);

Then starting with the same state B6=false and B7=true, now on I have :

1st read (time = 0 second)
B6=false
B7=false
2nd read (time = 2 seconds)
B6=false
B7=true
and continue with the correct read

So it seems the issue is to read the initial state. Have also seen that ?
And I am pretty sure this is the reason why the event I get are "corrupted"...

Thank you

Best regards
Denis

@savageautomate

This comment has been minimized.

Copy link
Member Author

@savageautomate savageautomate commented Oct 3, 2013

Hi Denis,

I actually did not make the change to the MCP23S17 GPIO provider class yet. The PiFace provider uses a different class impl and thats where I made the change. We should probably look at making the PiFace provider class extend from the MCP23S17 impl to reduce duplication of code. I would need to compare the two implementations to see exactly what are the differences -- I can't recall now why they are two separate ones to begin with :-)

savageautomate pushed a commit that referenced this issue Oct 6, 2013
…ider; fix initial pin interrupt blocking
@JanJansen47

This comment has been minimized.

Copy link

@JanJansen47 JanJansen47 commented Oct 28, 2013

Am using the MCP23S17 GPIO provider class, attached a couple of MCP23S17's to the PI and observed the same. The first read is wrong. Second is okay. It is consequent; happily I could live with it.

savageautomate added a commit that referenced this issue Sep 15, 2014
MCP expander chips
 - removed conditional interrupt address per pin
 - added initial state value reads

removed RPi-CM pin 16 from example, not exporting properly
@savageautomate

This comment has been minimized.

Copy link
Member Author

@savageautomate savageautomate commented Sep 15, 2014

Added initial MCP SPI read operation to obtain initial pin state values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.