as far as I can see there are some discrepancies between the doc and the libraries for the dot3k:
https://github.com/pimoroni/dot3k/blob/master/python/REFERENCE.md
as far as I can tell the upper limit is 9. what does 0 corresponds to incidentally?
The LEDs, including the three RGB LEDs for the backlight, are driven via the 18-channel SN3218- so LEDs 0 through 8 are the 9 for the backlight, and LEDs 9 through 17 are the 9 in the bar graph.
The first 9 correspond as follows:
hum, yes you are right… however I got confused because dot3k.backlight.set_bar use 0-8 (not sure where I got the 9 from).
… while I understand why .setbar would not apply to the RGB LEDs I think that is quite confusing. Could 9-17 be aliases of the range below, or handled some in way by the library, so that LED numbering scheme could be consistent in the upper range or is that not technically possible?
actually, it seems that dot3k.backlight.set does nothing at all for me… could it be it is because I have one of the early G/B channel swapped Display-O-Tron?
anyhow, I managed to control the LED (and backlight) how I wanted but I’m utterly confused about the index system, and even more so by dot3k.backlight.set(index, value)
right, I think I see what the problem might be… I had a look at backlight.py and you are missing ‘update()’ at the end of the function ‘set(index,value)’?
… mind you, I’m too new to Python to be sure, but at least after hacking that in I get some result from it.
… bearing in mind I’m trying to get my head around a lot of things, it seems to me that using
set(LED_L_B + 1 + index, value) as part of the set_bar function definition is bound to cause problem for us with the G/B channel swap?
Tell me if I’m wrong but the indexing varies depending on whether I call backlight.use_rbg() or not. That does not sound desirable to me - I think the fog is starting to dissipate for me… I’ll have a go at correcting backlight.py for my needs, but perhaps you should update it to take care of those issues (if they are not just in my head).
the simplest, it seems to me would be to use set(LED_R_R + 9 + index, value) instead, since the LED_R_R won’t be dependent on the swap. Also, makes the definition clearer, at least to my easily confused brain… would there be any drawback doing so?
right, posting my backlight.py hack here in case someone with inverted G/B dot3k find it useful.
def set_bar(index, value):
if isinstance(value, int):
set(LED_R_R + 9 + (index%9), value)
if isinstance(value, list):
for i, v in enumerate(value):
set(LED_R_R + 9 + ((index + i)%9), v)
update()
note that I also added the modulus ‘wrapping’ to the call using a single value. That way the behaviour is consistent whether you supply the function with an int or a list, the indexes 9-17 respond as (I at least) expect), and possibly useful stops the function failing if you supply a value superior to 8.
… it should work for both G/B swapped dot3k as well as the ones wired the right way, so if you are not sure which one you have it does not really matter BUT this is obviously a hack and I wouldn’t recommend it unless you need it!
right, it has occurred to me that there is an example named ‘backlight.py’ so just to avoid confusion, the set_bar definition is not found there but in the dot3k lib itself, I believe universally found on a Pi in:
/usr/local/lib/python2.7/dist-packages/dot3k/
I have set up a github and uploaded the file to it in case it helps anyone. I am totally new to github so hopefully the way I’ve done it makes some sense… if I am able at a later point I will suggest a patch to the official github.
Anyhow, my github: https://github.com/RogueM/