OctoWS2811 POV

Status
Not open for further replies.

Edwin Park

New member
Hi,

I have a question: is it possible to modify the OctoWS2811 library to change the output pin assignments?

Here's why I'm asking: I'm working on a Persistence Of Vision project where we're using a Teensy 3.0 to drive two WS2811 strips spaced 180 degrees apart from each other and spun around a central axis. Let's call them strip A and B, and at startup let's say that strip A is in front and strip B is in back. The Teensy is loaded up with a static bitmap image to be displayed. During the first half rotation, strip A displays the left half of the image while strip B displays the right half. At the end of a half rotation strip A is now in back and strip B is in front, so for the second half rotation strip A needs to display the right half image while strip B displays the left half image.

We want to move to OctoWS2811 because of its speed and the fact that it frees up cpu time during display updates, but it requires the pixel data for all the strips it is driving to be interleaved at the byte level. This means that if we want to do what I just described and just send the same image data to different strips at different times, we would either need to rewrite every bit in the image for the alternate representation, which eats up cpu time, or we would need to store multiple interleaved image representations, which eats up memory. It would be much easier however to just keep a single image representation and somehow tell OctoWS2811 to change the output pin assignments. I know the OctoWS2811 library doesn't support this now, but my question is, would it be possible to modify it to do this? How difficult would it be?

Thanks,
Edwin
 
I have a question: is it possible to modify the OctoWS2811 library to change the output pin assignments?

No, you can't change the pin assignments. It writes to the native port using DMA, which happens to be those particular pins. Each bit maps to a unique pin. You can't alter that mapping.

I just described and just send the same image data to different strips at different times, we would either need to rewrite every bit in the image for the alternate representation, which eats up cpu time, or we would need to store multiple interleaved image representations, which eats up memory.

Those are probably the 2 best ways. Have you measured how much CPU time this really costs? If done well, the ARM is really quite fast. Aren't you doing pretty much the same sort of thing many times during each half of the rotation?

Another possibility would be an external logic chip to route the signals.
 
I hate to burst your bubble but I think you are going to have an issue with refreshing them fast enough.

From what I have been able to find they run at 400 or 800Kbps. If this is the case then it takes 1.25uS per bit, and 24 bits per WS2811 so 30uS per pixel. And you need what 30uS to latch?
Anything slower then 600RPM or about 10FPS just does not look good to the human eye. At 10 FPS you need to redraw every 100mS, say you go for a 64 x 192 pixel image, you need to go to the next image line every 520uS. You would only have time to send data to 16 WS2811's and then used the leftovers to latch the data.

<<<UPDATE>>>
Now if you go with say a 32 x 96 display you could possibly do it. 0.1s/96lines = 0.001042s / 30uS = 34.72 == 32 pixels + room for latching.
But you would have to keep it small or it would not look to good.

You could also stack them possibly? Have a top and bottom set of 32 each driven by a Teensy 3?
<<<END UPDATE>>

Data rate and timing are your biggest enemies with POV. Take a look at my sig, that took me and a friend almost a year to build and we spent most of that time researching different ways to do it. In the end we went with a known working design and scaled it up some. My next version is currently beating me to a bloody pulp. But it will be 12 bit per color.
 
Last edited:
Status
Not open for further replies.
Back
Top