I am planning to use a triplet of RPi GPIO pins as an additional bit-banged I2C bus on my RPi. This will be run at a lower than typical rate (and level-shifted via a 3.3 to 5.0 V I2C shifter unit) so that it can work over the distance necessary to be the back-bone for a Home Automation control bus that will be populated with the (popular) PCF8574 and 8574A (Philips data-sheet) 8-Bit I/O expanders. These have the nice addition of an Open-drain (FET equivalent to an Open-collector) active-low line that can be connected as a Wired-OR between devices so that the controller (the RPi) gets a low-going interrupt any time any pin on any of the 8574* devices changes to be not the level that it was set to (input pins are to be written to/default to high output level i.e. ~5V).

I am aware of, and plan to use, @joan 's pigpio library with it's support of bit-banged I2C interfaces on arbitrary GPIO pins - and I will be coding in 'C', but can I use this interrupt to replace the (library's) need to constantly poll all the GPIO pins when all that is needed to do is: wait for a change on that interrupt pin?

To a certain extent this is a bit of a place-holder question that I will expand upon as I flesh out this idea in practice!


I have a very similar scenario as you: A distributed domotic system all over the house with a central device (Raspberry PI) and a few satellite boards with I2C (PCF8574/PCF8591) and 1-Wire (DS18B20).

Everything is connected via ethernet cat5e cables. To allow long range I2C communications I'm using the P82B96 I2C bus expander. For 1-wire communication is just a matter of reducing the pull-up resistor. The cables also power the remote satellites, so in the event of power outage, everything continues working because the central device (from where all cables come) is UPS backed up.

Initially I had to pool all devices and ports but then realized it was too much, so decided to go for interrupts.

My investigation led to the fact that its not possible to integrate PCF's interrupts into "raspberry pi's interrupt scheme".

My only alternative (still working on it) is to use one of the conductors of the ethernet cat5e cables to connect the INT pin of all PCF's to one of the RPI's GPIO's. Then, I'll be using the "raspberry pi's interrupt scheme" to look into that specific pin.

Meanwhile, have you further expanded your idea? Want to share some thoughts/improvements?


  • Thanks for the pointer to the P82B96 IC! I see that can provide the RPi 3.3 to 5 (or actually it might as well be 12 V) logic levels for the "long-distance" bus - and having one of those between the bus and the actual I2C devices (as well as the RPi) definitely seems like a good idea to protect the them from the sort of surges and other transient nasties that WILL occur in a distributed installation - even in a domestic environment. I'll just need to source some Schottky protection diodes (BAT85 or suchlike) to clamp any negative going transient voltages on the SDA and SCL lines...
    – SlySven
    Aug 4 '16 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.