apa102 slower than ws281x?

[mecha1]

I'm working on a large POV display that currently uses LEDscape with a bunch of ws2812 led strips (http://beagleboard.org/blog/2013-12-17-project-spotlight-orbital-rendersphere/). I'm trying to increase the resolution of the display, which also means considerably increasing the frame rate. I was hoping to use LEDscape in conjunction with some apa102 strip to be able to refresh all of the pixels in my display at the higher rates I need, but it looks like LEDscape is actually driving the apa102 strips slower than ws281x strip of the same length. Here is representative output from running opc-server with a ws281x config and an apa102 config using the same number of pixels:

ws281x, 17 pixels, no interpolation, dithering: [render] fps_info={frame_avg_usec: 745, possible_fps: 1342.28, actual_fps: 1335.50, sample_frames: 13355}

apa102, 17 pixels, no interpolation, no dithering: [render] fps_info={frame_avg_usec: 792, possible_fps: 1262.63, actual_fps: 1256.60, sample_frames: 12566}

However I actually want to have longer runs of apa102 leds than I had of ws2812s. But then performance gets even worse:

apa102, 41 pixels, no interpolation, no dithering: [render] fps_info={frame_avg_usec: 1836, possible_fps: 544.66, actual_fps: 543.40, sample_frames: 5434}

The comment at the top of apa102.p says that it is pushing data to the strips as fast as it can, which it indicates is about 1.6mhz. I've seen numerous other references from people who are able to run apa102 strip at much higher rates however. Is there something that can be done to increase the frame rate for apa102? Or is there some limitation with LEDscape at work here?

[Yona-Appletree]

I'm not sure why apa102 is slightly slower than ws281x, I'd have to look closely over the assembler, but I certainly never expected it to be any faster. Unfortunately, we're basically pushing the limits of the speed of the PRUs for driving 24 channels of data.

If you are driving fewer than 24 channels from each PRU, you could write a modified version of the program that omitted some channels. If you only need 8, for instance, you could modify the PRU program to only use 4 on each PRU. The speed should increase more-or-less linearly inversely with the number of strips.

I am currently working on a new method of writing the PRU scripts so that they can adapt at run time to the number of strips, and do this automatically, but it is currently unfinished. You're welcome to e-mail or call me if you'd like to chat about other options or for advice.

[mecha1]

Thanks Yona. I could benefit from driving fewer channels per PRU. I also noticed that LEDscape is generating separate clock signals for each apa102 strip, which is largely redundant and halves the number of available outputs; I'm wondering if generating a single clock instead would be another way to reduce the amount of work done and increase performance. I'd love to chat personally about options/advice. I don't have your contact info, but if you'd like you can reach me at esp@mecha1.com.

Edwin

[Yona-Appletree]

I'm going to close this issue for now. We can create a new one specifically for particular methods of improving speed if desired.