Not Fast enough about apa102-pi

[tinue]

According to documentation the SPI bus speed should go up to about 50MHz. I could think of two reasons why it's not going anywhere near this limit:

• There is a limitation in the Adafruit Library that drives the SPI bus
• The floating point calculations in "set_pixel" take too much time.

My library is written in Python, which is an interpreted language. You could try to get some timings for Python itself: Run your sample with and without the "strip.show()" part, and add some time gathering logic. You should be able to find how fast the set_pixel_rgb() is in comparison to show(). My suspicion is that the Python overhead itself is limiting the code to about 8MHz.

Regards, Martin

[oussamajegham]

Thank you for your replay and I am very sorry for my late , The problem is that python very slow , if the library was written in C ,it would work , So i will be glad if you can change it to C , because your library it has many features the others don't have .

[RubenMomoa]

maybe its because show() uses spi.write 5 (or more) times
clock_start_frame makes 1 call
show it self makes 1 call
and clock_end_frame does 1 + some based on num_led calls (up to 64 calls for 1024 led's)

maybe it would be faster to do this in 1 call
this works (in my limited testing)
write([0] * 4 + led_data + [0] * 4 + [0] * ((num_led + 15) // 16))
it combines the start, data, end frames all in 1 call
the downside is that the num_led limit isn't 1024 anymore it would be 956

[tinue]

Hello, I wrote the library initially to learn Python, and to understand the APA102 protocol. I wanted to pass on this knowledge in the form of documented code, so I published it on Github.

So the code is inefficient, and at the same time easier to understand compared to a "tuned" version. Your change is a good example: I also think that this would work fine, and it would probably be faster. On the other hand: If one wants to understand the protocol, then "start frame" etc. are important elements, and having separate calls makes this easier to comprehend.

This is why I don't plan to optimise the code at the cost of readability. However, feel free to fork the repository and try to provide a "high speed" version of the library. People who simply want to use the library, and not understand the protocol behind it would certainly prefer this version.

For a really speedy version, one would have to provide an implementation in C or C++, but I don't plan to do this.

[dasl-]

For anyone interested, @jordanlewis had some success increasing the performance of this library by implementing some of the internal logic using numpy: https://github.com/dasl-/pifi/blob/96d11bbb0bbdc6cd69a662e12b5f28c66ded62d8/pifi/led/drivers/driverapa102.py#L26-L62

The TLDR is that we set the APA102.leds array manually, thus bypassing some slow logic in the APA102.set_pixel method. By reimplementing that logic in numpy vectorized operations, we were able to speed things up a lot, and avoid the overhead of so many function calls in python.

We are running our code on a raspberry pi, and the speed up was significant there.