PiGlow LEDS mis-numbered (?)

Support
1

Hello everyone!

I was given a PiGlow for Christmas, and my first project was to make a (crappy) clock out of it. One weird thing though. As I was testing out manually controlling each of the 18 LEDs, I found that they are controlled 'out of order like such:

[…6…]
[…7…]
[…8…]
[…5…B.D…]
[…4…A…F…]
[…9…1…]
[…C…11…]
[…E…]
[…0…3…]
[…1…2…]

I Can’t figure out any reason why they’d be numbered this way and not say 0-5, 6-B,C-11. I finished my clock, but couldn’t figure out any pattern in this setup to make for good coding- so it’s a jumble of if/else’s for each LED. If they were sequential, I think I could figure out something clever in terms of controlling the LEDs…

On top of that, for the life of me I can’t find full documentation on smbus for python (not that I’d know how to, but I thought maybe I could change the mappings for the LEDs)

python docs smbus link: //docs.python.org/2/library/smbus … dead
i2c python docs link: http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc...uhh
git kernal docs link: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/i2c/smbus-protocol … Do I read this correctly, there is no option to re-route the mapping from these commands?

Thanks for reading! This is the first thing I’ve ever programmed… so sorry if I’m missing something glaring here.

2

The order of the LEDs is based on the pinout of the IC we use to drive them (SN3218A) - the “mapping” of the LEDs to a sensible layout needs to be done in software!

3

First off, I applaud you for getting so dug into using i2c on the Pi that you’ve actually discovered this problem. It’s an interesting one, if you’ll bear with me:

In short, Re-mapping the LEDs can only be one either by:

  1. Keeping an array of addresses in your user code/python module for driving the PiGlow
    or
  2. Physically changing the hardware

The smbus stuff is actually a very, very thin Python wrapper around C’s smbus functionality and is a bit of a red herring.

When you pass an LED number like 1, or 12 into smbus to communicate with the PiGlow, what you’re actually doing is passing the register address, this maps to a physical hardware location within the sn3218 chip that drives the PiGlow and isn’t supposed to be a sane and rational number…

Each LED on the PiGlow is connected to one of these physical registers on the sn3218, and they’re laid out for sanity and convenience… so generally we’ll route the LED on the PiGlow to the pin on the sn3218 to which it’s closest. Because the register is a fixed piece of hardware, we can’t do any device-level re-mapping to account for this- and you end up with something of a mess!

But that’s okay, the PiGlow is an odd beast and doesn’t really have an order- where’s LED 1 for example? I could pick it arbitrarily, or with only a little basic reasoning.

In the Pibrella library we might map LEDs like so:

legs = [
  [ 6, 7, 8, 5, 4, 9 ],
  [ 17, 16, 15, 13, 11, 10 ],
  [ 0, 1, 2, 3, 14, 12 ]
]

Because we tread each “leg” ( or arm ) as a separate entity. Using a list like this, basically means you can pass in legs[0][0] and get LED 0 on leg 0. You can accomplish your mapping with a single flat list, I’d imagine! That’s not messy at all!

yourmapping = [6, 7, 8, 4, 9]

address = yourmapping[0]
>> 6

Hope this helps!

4

Gadgetoid,

Thanks so much for the thorough response! That explains it very well, and I’ll definitely employ the “leg” mapping you suggested.

5

You’re welcome, have fun with the PiGlow and let us know what you do with it!