@FoamyGuy
i just tested this again with the follwing script:

import board
import busio
import adafruit_tlc59711
spi = busio.SPI(board.SCK, MOSI=board.MOSI)
pixels = adafruit_tlc59711.TLC59711(spi)
print('tlc59711 test - light up 4 pixels.')
pixels[0] = (1000, 200, 10)
pixels[1] = (10, 10, 1000)
pixels[2] = (10, 200, 10)
pixels[3] = (500, 10, 1000)
pixels.show()
print('tlc59711 test - show done.')
print('The End')

unfortunately i did not find my Adafruit TLC59711 Breakoutboard :-(
so i only can check with my own made Boards
these have four TLC5971 on them.
my boards are fixed setup for 5V Power and Logic - so i have a levelshifter between my ItsyBitsy M4 and the boards.

the most significant difference between the two for us here is the Data-Transfer-Speed:
TLC5971 20MHz
TLC59711 10MHz
the protocol itself is identical.
in the multi branch i also do no spi configuration other then in the original lib like this:

self._spi.configure(baudrate=self._spi.frequency, polarity=0, phase=0)

so this should make no difference on the outcome with the given example code.
but maybe the default SPI frequency is different on the different boards?!
but this way with the code the current master branch should also not generate a stabel output...
(i think you used a ESP or similar board in your test-setup?)

for the test i renamed the lib to lib_ so that i am sure there are no other versions used.
So my CircuitPython Disc looks as this:

stefan@stefan-Zen:~$ ls -l /media/stefan/CIRCUITPY/
total 65
-rw-r--r--  1 stefan stefan 39342 Dez 19 12:15 adafruit_tlc59711.py
-rw-r--r--  1 stefan stefan    90 Jan  1  2000 boot_out.txt
drwxr-xr-x 44 stefan stefan 24576 Sep 12 13:28 lib_
-rw-r--r--  1 stefan stefan   337 Dez 19 12:14 main.py

my boot_out.txt:

Adafruit CircuitPython 5.3.0 on 2020-04-29; Adafruit ItsyBitsy M4 Express with samd51g19

here are the two tests results as photos:
Original Master:

multi branch

the first chip on the board is Marked U1 (top left in the image)
(the other chips are showing kind of garbage that is passed through...)
and as you can see indeed the pixel order is changed.
other than this both work fine.

i try to find my TLC59711 Adafruit Breakout board tomorrow..
(but can not guarantee to find it in my current project chaos... 🙈 )

i have to think about what it would take to correct the pixel order...
(i think i had tested this and it slowed down quite a bit)

hmpf the black formating is failing again.
locally it is failing - but for other files ;-)
and this is again the list comma handling...

so are you planing on upgrading the black in the Build CI test?

@s-light

so are you planing on upgrading the black in the Build CI test?

Yes. But honestly, only because you brought this to my attention. We pinned black=19.10b0 and I do not know the reason for this. Just as I pushed for sticking with the latest Pylint to avoid the massive overhaul needed when we moved from 1.9.2 to 2.x, I am going to push for us to move to using the latest Black as well.

My suggestion for now is to force reinstall black with the pinned version, and re-run it to see if you can get it working properly. If you need help with that, let me know. I really want to see progress on this PR, and I apologise that CI is causing roadblocks.

happy new year to you all!!

all fine.
just as reference for others stumbling over this -
with this line you can downgrade / install a specific black version.

pip install black==19.10b0

to later upgrade to the latest version you can use

pip install --upgrade black

(source)

@s-light @FoamyGuy Now that this is passing again, where are we at with it? I don't know the whole story so I don't want to jump in and merge if there are still incoming changes.

@s-light this file has .pdf extension but is in the examples folder and seems to contain python code. I think it must have gotten pdf accidentally and needs to be changed to .py

https://github.com/s-light/Adafruit_CircuitPython_TLC59711/blob/multi/examples/tlc59711_fancyled.pdf

@kattni I was not able to get the examples to run successfully with the new version of the library. Looks like s-light has custom breakouts that may be a bit different than the Adafruit ones perhaps, that is the only guess I have as to the difference in behavior between them and myself. I wonder if it may be possible to get one of the Adafruit breakouts into s-light's hands so they could try these changes out directly on that device.

I've got my circuit still put together stashed away so I can pull it out to re-test any time. But I don't really have any other ideas for troubleshooting at this time.

@s-light Please email me at kattni@adafruit.com. Thanks!

the pdf should be py - sorry... (fixed)

i have extended my search for my adafruit breakout board. and luckily i found it :-)
😄

so i have done a second test here.

testsetup

hw

• Adafruit ItsyBitsy M4 Express featuring ATSAMD51
• Adafruit 12-Channel 16-bit PWM LED Driver - SPI Interface - TLC59711
• LED-Board 4x4 16bit
  (connected in this order)

code i used

import board
import busio
import adafruit_tlc59711

spi = busio.SPI(board.SCK, MOSI=board.MOSI)
pixels = adafruit_tlc59711.TLC59711(spi)

print("tlc59711 test - light up 4 pixels.")

pixels[0] = (30000, 200, 200)
pixels[1] = (200, 200, 30000)
pixels[2] = (200, 8000, 200)
pixels[3] = (8000, 200, 8000)
pixels.show()
print("tlc59711 test - show done.")

# these extra show writes shifts the informatoion on to the next chips...
pixels.show()
pixels.show()
pixels.show()
pixels.show()

print("The End")

results

original

multi

so for me it is working fine.

Open Questions

Only thing open (i think):

• do i have to be backwards compatible with the pixel indices order?
  currently it changes (it currently is a raw un-mapped representation of the buffer to write)

Level-Shifting

as i followed the guide for setting up the test- i just questioned myself if i have overlooked something regarding the Digital-Signal Levels and uC with 3.3V logic -
and checked again in the datasheet:
if you power the Breakout-Board VCC pin (that is connected to the VREG and VCC pin of the chip) with 5V you would have to have also 5V levels for the Signals (SDTI,SCKI) as the Datasheet states:

and 0.7V*5V=3.5V - and that is the minimum for the High-State - so it is not guaranteed to work with 3.3V Signal Levels at 5V VCC, VREF.
so i remembered correctly and to work reliably in the recommend range you need a levelshifter in this configuration.

sadly the board connects the TLC59711 VCC to the V+ (+15 in schematics).
if this would be not the case you could use separate Voltages
breakoutboard VCC: 3.3V
breakoutboard V+ : 5V
to accomplish this you could ignore the nice V+ pins for the leds and connect them in another way.
i understand that this is a tradeof to not get to complicated for beginner users...

i just ignored this fact now for the test setup and followed the instructions.
and of course it works ;-)

@s-light @FoamyGuy Hey! Checking in :). There are some merge conflicts to deal with but they appear to be simple ones.

Where are we at with this?

i can check on the confilcits next week...

Where are we at with this?
i think @FoamyGuy did not get it to work at his site at all...

• afteer this i did a test with the adafruit breakout board and it worked for me -
  maybe this has to do with the used board... ?!

I tested this successfully with two TLC59711 breakouts and can control LEDs connect to both breakouts. Everything seems to be working as intended for me now.

I do think it would be great if we could offer some way to use the index order that matches the silkscreen on the Adafruit breakout, but I don't know if that is a strict requirement. @kattni do you have thoughts on this?

The one other thing I noticed is that the docs don't seem to include the API information any more, and they only have one of the example scripts listed.

Here are the docs built locally from this PR:

and here are the ones live now:

Thanks again for all your work on this @s-light! this is a great new feature to support multiple devices chained together!

@s-light OK - we are SO close! I was going to resolve the merge conflicts myself through GitHub but the conflicts in adafruit_tlc59711.py are more complicated than I expected. You're the one best suited to resolve them as you know what you added. Is this something you can get fixed up? We can address the documentation in another issue/PR. Once the conflicts are resolved, I want to get this merged. Thank you so much for sticking through this!

@FoamyGuy I don't think it's a strict requirement - I would say file an issue, and consider simply closing it, so the issue is there if anyone searches for it, and someone can make a request there if desired.

@kattni I could take a look to the documentation once is merged, if that is ok,

@jposada202020 That would be brilliant! Keep an eye on this PR for when it's merged and then take a look.

Will do already pin in my inbox :)

@kattni i think i have resolved all the conflicts -
and also installed the new pre-commit workflow locally... and after sum tweaks it passes ;-)

😃 🎉

@s-light Thanks :)