Io60p16 usage problem

Polling is less reliable. I will have to do some tests to see how long it takes to poll all of them, and if the polling works while another thread is serving an XML result over Ethernet. If I go polling I would probably need to go with 50ms intervals to make sure I capture everything in case one of the cycles runs slow.

The system will also have a thread monitoring some environmentals such as temp/humidity, current, water presence, and one more that I haven’t figured out yet (distance, reflectivity, or water sensor). These sensors could have a lower polling rate, say once ever 5 seconds even, but my concern is if all 3 are going at once I might miss something on the “interrupt” lines if they are being checked on a poll rather than using true interrupts which should just stack up events. Them happening is more important than exactly when they happened.

@ taylorza - 29 is enough, I actually need only 27, 30 was just an approximation.

I did some tests tonight with the IO60P16. I found one bug in my driver but that was causing the interrupts to always get set on port 0 instead of the intended port but that didn’t fix the problem. I stepped through the code that enables the interrupts and it all looks good. I’m not sure yet why the interrupts aren’t firing. They used to work perfectly. I tried with both an X and an I socket. I’ll try a little more tomorrow night.

@ ianlee74 - I wired everything in last night, and using the GHI driver I am only getting things on port 0, unless I’m doing something wrong. I am trying to read ports 0 through 3 but I get the values of port 0 on all the read commands.

I have tried 2 read versions and always get the values for port 0. Port 0 does work great though.

Debug.Print(DateTime.Now.Ticks.ToString() + " " + io60p16.Read((byte)0).ToString() + " " + io60p16.Read((byte)1).ToString() + " " + io60p16.Read((byte)2).ToString() + " " + io60p16.Read((byte)3).ToString());

Debug.Print(io60p16.Read(IOPin.Port2_Pin0).ToString() + " " + io60p16.Read(IOPin.Port2_Pin1).ToString() + " " + io60p16.Read(IOPin.Port2_Pin2).ToString() + " " + io60p16.Read(IOPin.Port2_Pin3).ToString());

I have checked with a logic probe and the electrical values are changing on the expected physical pins, just not in code.
Perhaps something has changed elsewhere causing problems?

the GHI team commented on another thread, I’m pretty sure, that there was a fault like that in their driver. Looking…

Edit: didn’t find the exact post I was thinking about but there was a comment on http://www.tinyclr.com/forum/topic?id=10075&page=2 that says there’s a problem due to be fixed, just no details…

@ PintSize.Me - we will double check.

@ PintSize.Me - This may be caused by a restart in the software i2c. I don’t know anything about GHI driver, but I face many time this issue.
For my specific porpouse I used directly a modified ReadRegister/WriteRegister function, reading back 8 port at time and not single port, making a single 8 byte i2c transaction.
I’ve no code in my hand in this moment, but I can show how to do that later.

The chip let you read adjacent port values. For example you can read pin status of all 8 ports simply starting at port 0 and reading 8 bytes.
Same can be done for interrupt ports read&clear. This is the most reliable way I found to work with this chip, quick&dirty. The same works also for write to regs.

Edit: I use a modified Ian driver.

I really cheer for you. I buy IO60P16 because i need some IO interupts (classic switches), but now they don’t work.

Just to clarify the INT problem, remeber that this chip has no front selection, so it reacts on low-to-high and high-to-low transitions. This is a big mess, becouse your signal, e.g., goes low-to-high, so you get int and clear status reg. In the meantime your sig may reset to low, raising int again. So you have to read again the relative status reg very quickly. This stuff need to be taken in account.
An other stuff to be carefull. Remember to set pulldown mode on the port, if you need int on low-to-high and viceversa use pullup if you need to go high-to-low.

I think I have interrupts working now. I had left some code commented out during my last test I was working on months ago… :shame:

I’ve also moved all of my source from CodePlex to my GitHub account and given IO60P16 it’s own repo at:

Also, I changed the module’s namespace to avoid confusion with the GHI driver. See the test app in the repo for examples.

Note, you will still see the double interrupts that dobova mentioned. I’ll work on fixing that later. I’ve had the flu the past few days and haven’t been able to work but for short periods at a time. This should get you going, though, if you always ignore the second interrupt until I get that filtered out.

@ ianlee74 - i confirm that your driver is working although I’m using a few month ago version

Yea, all the problems were caused by some of my last changes I was working on. GHI had asked me to give them what I had a few months back and in a rush I apparently didn’t clean up well before checking in. Sorry for the confusion, Makla.

Hey, no problem. I am very glad that works. :)))
Thanks.
Now I can go to my father and tell him that I din’t convince him for nothing to buy GHI products. He really needs 10 interrupt ports.

Uhhh I’m curious about the project you are doing…!

Some automatic lights and sun blinds with remote control and switches. I am not sure. My father has some ideas. I just point him to MicroFramework and GHI products.

@ Makla - Thank you for info Makla … I hope you’ll enjoy the project.

@ Ian - I’m pretty surprised that with last fw cerberus seems more reliable than before with software i2c and your driver … I will check on Hydra too later !

Don’t worry he will.

Hopefully, that means all the bugs have been worked out of the fw :slight_smile:

I am still not seeing interrupts, but it is asking me for source for Gadgeteer’s Program.cs so I think I have some problem on the project or deployment I need to work through first.

Yea, that sounds like a problem with your project startup settings. You may try my test project that’s on Github. If you run it and touch port #6 pin #1 to ground then you should get a interrupt and text in your debug output.