I’ve purchased two Scroll pHATs to use simultaneously running on one RPi, sharing an I2C bus. I’ve looked at the datasheet for the 31FL3730 and noticed there is a pin (pin 6 - AD) for setting the I2C address. I’m assuming you’ve hardwired the pin to ground - are there any traces I can cut or access to re-route this pin to have another I2C address so I can use multiple Scroll boards on the same bus? Is there another way to accomplish this that I’m missing?
Side note, why not just break out that pin so people can choose their own address (assuming you haven’t already done that and I’m missing things)?
We tend to be opinionated about our pHAT and HAT boards, and don’t offer options for configuration. This is a shame for advanced users like yourself, but makes sure things tend to just work for everyone else.
IIRC the address pin for the 31FL3730 needs to be tied to VCC, GND, Data or Clock. It may be possible to cut a trace and re-route it, but I suspect it might be tricky, I’ll have to dig up the schematic when I get into the office.
I think @RogueM might have actually accomplished this on one board. But I think our canonical answer for advanced users is that: “You can use up to 2 by using the second i2c bus”. He’s gone a long way toward making this possible with several products already :D
That’s right, I’ve been working on an experimental feature for the scroll phat library lately, that allows you to control 2 units, one on each bus, using a unified API:
It is still in motion, and it’s possible the final implementation, if the approach is not completely ditched, will break in the near future. It is however fully compatible with the current library, and that’s something I’m keen to ensure at every step.
Anyhow, feel free to poke around and see if that is any use to you. Note that you need to enable the videocore i2c bus, and that it won’t work on a Pi 3 (due to the bus being used in support of the bluetooth/wifi, and officially described as not suitable for userspace).
There’s a set of examples included that showcase how you can control the second unit located on i2c0 (but basically you need to call all officially documented methods with a alt. prefix.
Thanks for the help! I understand the choice to go for something that just just works out of the box. As I’m trying to run things on a RPi3, the software solution doesn’t quite cut it for me, though I think it is a cool workaround for the Zero and Pi2. A board schematic or trace diagram would be really beneficial. Worst case, I’ll just make my own boards in EagleCad and make a batch with a breakout for all of IC pins.
Is this code working now - and if so, how do I use it?
I’ve just started a project which involves displaying several train times (live), and this seems like a much more elegant (and cheap) solution than loads of 7-segment displays. I’d ideally like to have two running at once (so I can display train times to two different places).
I haven’t touched the code since then, but yes, it should be fully fonctional.
check scroll-text-two-phats.py for how it works, but basically all methods documented in the regular API can be preceeded by alt_ to address the unit hooked up to i2c0.
To enable i2c0 you can use:
curl https://get.pimoroni.com/i2c0 | bash
… feel free to ask for anything not overly clear or working, but as I recall there not a great deal more than this.
On the scroll-text-two-phats.py example it tells me that that it can’t detect a phat on i2c0 - but running i2cdetect -y 0 tells me that there is definitely a phat connected there with addr 0x60 (and the same on i2c1).
When I run the test-both.py file, and change the commands in the sine.py example to have an alt, it gives me an AttributeError that the module has no attribute ‘alt_set_buffer’.
hum, are you sure you have python-smbus installed? if the answer is yes, and you can’t run any of the old examples with a scroll pHAT on i2c1 (i.e as normal) then I’m not sure what could be wrong.