[title]PCF8575 Management Class with cool addins[/title]
http://code.tinyclr.com/project/457/pcf8575-management-class-with-cool-addins/
[line]
There are 2 classes in my driver. One is for I2CManagement, that you’ll be able to reuse for any other device, and one for the PCF8575. The second class embed all the plumbing to manage IO, using a DeviceIO class tha enable to predefine your IO structure, and manage triggers on changed inputs.
the I2CManager is implemented using singleton pattern, that manage locked accesses from several processus so that you can normally use it in a multithread perspective.
Enjoy trying these, and if you have any idea on methods to add, reply !
Nice one ! 
I have one remark, though : you don’t seem to use the INTerrupt feature of the chip and I think this may lead to problems when you raise the “IOStateChanged”.
I think at this because you raise the event in a for-loop (foreach, to be precise). If another input changes its state while you are still in the event handler, the state-change could be missed. You see what I mean ?
If you use the INT pin, then you could run a new thread at each interrupt and in the thread you raise the IOStateChanged event. This way, you won’t miss any change.
But of course, this may need some adjustments in lockings since many threads could be running at the same time, depending on the different state changes.
Please note however that I don’t have that chip, so I can’t test or check what I say. So I may be wrong 
thanks for your feedback Bec à Fuel 
Using the PCF INT\ adds an interesting stuff to the read step, avoiding to use a timer loop over the entries. I effectively use an interrupt line for all the chip on my I2C bus and this is why you do not see it there. It is implmented one stage up in the code when i initiate the several chips, and when I catch this interrupt, I launch the read process for all of them.
The foreach in the Refresh() method is only here to read in ‘bulk mode’ all the inputs, because the interrupt says that something change, but not on which input of course.
Another more powerful solution would be effectively to have 1 interrupt per chip on the bus, but then, it depends on how many inputs are available to do so…
Also, I encountered some problems with I2C multi access, and that is why i use the lock system…
