Working on an application that will use the IO40 and the driver doesn’t support (natively at least) the use of Events. Is it possible to add something like a ButtonDown event or…would it be better to just spin off a class on a seperate thread that simply polls the IO40 on a constant basis? The app needs to do some other things, so, I don’t want the primary thread just sitting in an endless loop waiting for a putton press from he IO40. Any thoughts?
I added events to the LCD Shield buttons by starting a thread that polls them and raises an event on state changes (and it does debouncing too). The project is on the Wiki and the download to grab the code from CodePLex is there too. Take a look it might give you some ideas.
The IO40 board uses I2C which doesn’t have interrupt/event. You can handle what you need by running a thread to check periodically.
Thanks Gus and Jeff, appreciate the advice…will look at the example on CodePlex…looks like a seperate thread will be my best tact, figured that was but wanted to check first.
With the IO40 you might want to do port wide reads (I think you can do that) then mask off any output pins and finally XOR with the last state. That should tell you which inputs have changed and this can be the argument that the event sends to the registered handlers. The handlers would then need to just filter the argument to see if it was a pin they should care about.
Thanks for all the advice…Another quick question…I know it is recommended that you use a 1K resistor for normal buttons…would the same be recommended for buttons on the IO40?
1K to 10K should be fine
In looking at the PDF for IO40 (PCA9505), it looks as though I should be able to wire up the interupt from that chip and thereby enable an event and then use I2C to read which IO pin was set. Am I missing something here? Is this disabled on the IO40 board? Thanks
/INT is brought out to solder pads for a 5 pin header on the right side of the board. If you wire it to an interrupt capable pin on the FEZ I don’t see why it would not work. If the interrupt rate is low it would save a lot of polling, but with 40 potential inputs you could spend a whole lot of time servicing interrupts.
With polling you may waste a bit of time polling each port when it is not needed but the amount of time is deterministic (should always take about the same amount of time to read all five ports.) It also looks like although the /INT line goes low you don’t know which input triggered the interrupt. you have to read each port until the /INT goes high again (or just read them all.)