Faster SPI-based SK9822/APA102C leds?

Just ordered a flex board. I want to attempt a POV display with BlinkStick.
From my research WS8211/2 leds are too slow for POV applications.
Is it possible to drive SK9822/APA102C leds from the ATTiny?
Their SPI interface is much faster, providing an external clock line.
It seems the ATTiny can provide clocking, and is even over-clockable although power consumption becomes an issue with USB.

Hey Dominic,

I´ve found POV projects with WS2812 but you are right, the high performance projects using APA102C. The attiny85 itself should work with APA102 as Adafruit offers tutorials for using these LEDs with their trinket board (

But if you want to realize such a project with the Blinkstick afaik @arvydas has to update the firmware to work together with APA102.

I just got the Flex board today, with a handwritten thank you from @arvydas and a very nice UK postage stamp.

Still waiting for my RGB strips to come in from another supplier.

My main question I guess is the pin outs on the Flex board - SPI is different in that it requires a clock line.
What about the power consumption running 32 leds at POV speed over SPI (will USB handle this, or do I need external power?)

I shall experiment with the firmware (likely adding an extra mode for SPI) and post back with any results.

Hi…as per my experience SK6812 and WS2812B used in some of our other similar LED strips, which use a specialized one-wire control interface and require strict timing, the APA102C uses a standard SPI interface for control and has no specific timing requirements, making it much easier to control. Another useful feature of the APA102C is an additional 5-bit brightness control register that allows the brightness of each pixel to be adjusted independently of its color.

prototype pcb assembly services

Managed to do a bit of POV with the flex board up to 60fps with 30 LEDs.

Using a Digispark (ATTiny85) and some hacked BS firmware, I got 60fps out of 60 leds, but burned out one of my USB ports (I put in an auto dimmer over 30 LEDs to fix this). This reduces the already crude brightness control of WS2812 LEDs.

The Digispark supports soft SPI, so I shall attempt 60 APA102C LEDs next. Also I will be using a SATA rail to power them, rather than the USB rail. Hoping the improved clocking and fine brightness control will yield better results.

There is also I2C, which seems to be for controlling LED displays, which I might look into. The limitations right now are the small buffer on the ATTiny85 and the overvolt danger of the USB rail.

One thing I have noticed is that APA102C LEDs are much more expensive than the WS2812 variety. Also WS2812 strips vary in colour balance from one manufacturer to another. You get what you pay for, I guess …

Hi…in my case the problem is that there are interrupts taking more than those 10uS. So to produce flicker-free updates for a WS2812 chain, interrupts need to be disabled during the entire chain update, which means several milliseconds. The capacitance caused by PCB also has it impact on these interrupts. So, you should carefully design and embed the components for pcb assembly. This works (ws2812_draiveris does this), but it’s ugly and completely messes up all other timing that might go on in parallel.
On the Omega2, there’s a PWM unit that can help a bit. It’s not perfect because it lacks DMA support, but it can generate chunks.

As stated I had to hack the BS firmware to get consistent 60 fps. The BS firmware maintains an internal buffer in order to be able to “read” the strip. For POV streaming, “read” operations are not required - it is always one way push buffering.

Note that this internal buffer is the limiter of how many LEDs the BS firmware can support. By removing it, you can theoretically support streaming to much larger matrices. You can always store state on the app side rather than on the controller. One could use the buffer for other things like storing animations for standalone operations.

@dcerisano interested in what you did with the firmware. In my experience when I was working on it, I found that the delay between packets would end up resetting WS2812 LEDs and create erratic rendering of the LEDs. That is why the buffer was added: so that LEDs could be updated consistently. It’s not actually required to have the internal buffer for normal BlinkStick operation, because the software should always “know” what is the color of each LED and normally it’s just one piece of software controlling one BlinkStick.

There is a fastest frequency speed led SK9822-A, PWM frequency can reach 27KHZ.APA102 PWM frequency is 20KHZ,SK9822 PWM frequency is 4.7KHZ. it have Data and Clock signal input and output , which make the signal transfer more stable ,then it can be Anti-signal interference without using capacitor.