Being a cheapskate and not having a pHAT Stack, I noticed that https://pinout.xyz/phatstack says that I should be able to run a PiGlow and Unicorn HAT from the same Raspberry Pi 2.
Unicorn HAT runs fine on standard m/f jumper (jerky) wires, but when I wire up PiGlow everything runs perfectly for a while before the code crashes with an ‘i/o error’. The amount of time the code (Python) runs for varies, but everything seems fine up to the point of the crash.
This occurs if only the PiGlow is present, connected by wires - it makes no difference whether or not Unicorn HAT is wired in too. When the PiGlow is seated on the Pi’s pins, the same code runs indefinitely.
Would there be a reason why wires affect things? As I say, it appears that all the connections are sound as the display works. I’ve rewired a couple of times, so I assume it’s not the wires’ fault.
Generally the communication protocol that PiGlow uses- SMBus/i2s- is designed for really short, very precise PCB-trace wiring. That doesn’t mean it wont work with jump wires, but it does mean there are a lot of factors- noise, crosstalk, bus capacitance, etc - that can make it a bit more of a challenge than a more direct connection.
So you could potentially be right at the threshold of a functional signal for i2c, and periodically crossing that threshold into an IOError.
I’m currently running a couple of breakout boards that way. A MBP180 and an SI1145. They both use i2c. I have male headers on them, and male headers on my Proto Hat where the connection to i2c is made. I used female to female jumper wires. I just took the single shells off the ends and replaced them with 4 or 5 pin shells. It makes plugging and unplugging them easier. I don’t know if it matters but I keep all the jumpers the same length. No errors that I know off. This Pi is portable and headless. There is also a DS3231 and a Sense Hat on i2c. It’s doable.
It may be as @gadgetiod mentioned that that board is a bit fussy and sensitive to interference or something.
I’ve definitely had the odd jumper wire now and then that- for reasons I’ve never bothered looking into- simply doesn’t want to carry an i2c signal without turning it to mush.
But as a counter-example, I’ve had a lot more hastily bodged together i2c setups over jumper wires that have worked absolutely fine!
Just lucky I guess? I honestly haven’t given it a whole lot of thought. I didn’t know it was an issue, or could be an issue? My cables are made from jumpers that came in a kit, so they were all the same length. Mine are mostly away from the PI itself, which could induce noise etc. Noise aka interference would be what I think would mess things up. Pickup from components on the Pi scrambling the signal/data.
The wiring was made in conjunction with https://pinout.xyz/pinout/piglow - and these are Pimoroni Jumper Jerky wires for what it’s worth (and changed for my first attempt). The code still runs fine for a minute or two then crashes with this message:
IOError: [Errno 121] Remote I/O error
As stated before, PiGlow is stable when on the pins, so I’d assume the ‘on the threshold’ theory is good!
I’m pretty well doing the same thing, mine are female to female, but that shouldn’t matter at all. One thing I did different is I separated all the wires, they aren’t still stuck to each other like a ribbon cable. .
Could be worth trying to separate the yellow/green (clock/data) wires from each other, and from everything else. I quite often use a very similar if not identical setup to the one you picture, though, so it could be flaky/marginal jumper jerky.
It’s possible, also, to modify the piglow library to give it some tolerance for IO errors, but not simple.
I tried again, separating the clock/data. I can’t be sure, but doing this seemed to make the crash come later… but it always crashed. I swapped wires (again) and even removed the USB wi-fi in case that was an issue — regretfully, it wasn’t.
Thanks for your help on this. I may try in the future and order some Jumper Jerky Junior, to see if ~100mm wires are better than the ~200mm ones, but not for this festive season.
Wherever you’ve typed “piglow.show()” replace that with the text above, starting with the “try:” line and being careful with the indentation. “Try… Except” lets Python do something but not stop running if there’s a problem, which is what it does here. The error caused by the wires is an “IOError” - an input/output error and this code just means it’s caught (with the “except” statement) and ignored (“pass” - a handy keyword which does nothing but completes the Python syntax correctly).
