Is there something like OctoWS2811 for LPD8806 led strips

Status
Not open for further replies.

bongo

Member
[Quick intro, as I'm new to Teensy + this forum: I'm Bongo, and I have been making digital musical instruments for a few years. I have recently been working on combining this with addressable LED strips.]

I am working on a project which may end up driving 1024 or more addressable RGB LEDs. I have already invested in 10s of meters of LPD8806 strip, and I am wondering if anything like the awesome OctoWS2811 library exists for the LPD8806 strips, i.e., using 8 Teensy pins to push updates to 8 strips at once using DMA? I am trying to both update my pixels as quickly as possible, and off load this so I can make the most of my Teensy 3 cpu's while the pixel update is happening. And it would be great if multiple Teensy's could be interconnected with a sync wire so multiples of 8 strips could be updated at the same time.

Thanks in advance for your thoughts/help.

Bongo
Amherst, MA, USA
 
Yes, there is. I wrote it about 1 year ago.

Well, sort of. It only streams USB to LPD8806. There's no ability to run stand-alone, generating your own animation with double buffering. It's also not really well documented like OctoWS2811. It only works on Teensy 2.0 and Teensy++ 2.0.

See this message for info.
 
Thank you Paul for the quick reply. I checked the thread you linked to , and I understand that there may not be much demand for an "OctoLPD8806." I would try to create it myself, but I don't think I have the skill to do this. And I know you have far more important tasks demanding your time.

I have been working with the Teensy 3.0 for a few weeks now, and love this board!
 
Daniel Garcia is working on a new version of FastSPI_LED. He's working on optimizations for Teensy 3.0, maybe DMA-based SPI? Even without the DMA, the SPI has a fifo that really helps to easily sustain maximum speed. It will probably only drive a single strip, but the LPD8806 has very flexible timing and can accept fast data, so that might not be such a limit as it is with WS2811. FastSPI_LED's next version will probably be the best LPD8806 library anyone will ever write. I'd keep an eye out for Daniel's new version....

Writing OctoLPD8806 would indeed be a lot of work. Even if you're very familiar with the complex DMA controller, it still involves a lot of careful verification of the waveforms with an oscilloscope or good logic analyzer. I spent many hours doing this for OctoWS2811. In fact, it might not even be really feasible for LPD8806 at higher bit rates, due to the DMA request latency to copy the TCD info in and out of the DMA engine?
 
There's a preview release of the next rev of FastSPI_LED that pushes (roughly) 6.6Mbps out to the LPD8806's using hardware SPI support. There's still two sets of optimizations that I need to make to it - one is to directly use the ARM's SPI registers directly - which should improve per byte performance quite a bit - and then the second is to enable DMA support for writing out the the LPD8806.

Keep in mind that the WS2811's run at ~800Khz for data, or, 33,333 rgb led updates/s per line or ~1,111 rgb/leds at 30fps per line, which means OctoWS2811 can get you 30fps refresh rates on up to almost 9000 leds. Once I get DMA support for the LPD8806 working (the next rev of the library's been derailed a couple of weeks for a personal project as well as some work and personal travel), there's no reason I wouldn't be able to get a full 8Mbps (maybe faster?) out over the LPD8806's, which is 333,333 rgb led updates/s per line, or 11,111 rgb leds pushed at 30fps.

Now, given that I question how well a 11,000 led chain of lpd8806's would work - the final implementation will likely allow you to have multiple lpd8806 lines, with separate select pins for each (note, you'd need to do some hardware work off the teensy 3.0 to handle that routing) so you could have multiple shorter strings but still get close to the max performance out of the world (and have the code on my side of life that at the end of each lpd chain flips the select pins, then DMA's the next chain)

(N.B. - the numbers above are a bit handwavey, and reality is probably a bit slower - but the rough differences in terms of data rates hold true.)
 
Paul & Daniel - I am humbled and thrilled by the work you do!

Paul, thanks for letting me know about Daniel's current work. And Daniel, this latest work on FastSPI_LED sounds like it could be exactly what I am looking for. I am presently working with 256 pixels on LPD8806 strip, but hope to do an installation with somewhere between 1024-4096 pixels. Should I be thinking about using multiple lines to update this many pixels. I understand that you can push 6.6Mbps, and perhaps 8Mbps, out over LPD8806's, which would provide for a more than adequate refresh rate for 4096 pixels. Are there limitations to the LPD8806 itself that would suggest using multiple lines (shift rate? data loss? other?).

Thanks again to both of you,

Bongo
 
Hi Paul I loaded octows2811 in teensy 3 (Arduino> File> Examples> OctoWS2811> VideoDisplay)
but I could not open them with any video program. What video player you use to communicate plug and play, with teensy3 (VideoDisplay).
Thanks.

Iulian H.IASI/ROMANIA
 
hope to do an installation with somewhere between 1024-4096 pixels.

The LPD8806 is dramatically faster than the WS2811, and the timing is very flexible. The only downside is that do cost more, which really adds up when you scale to many thousands of LEDs. The main idea behind OctoWS2811 is you can save a lot of money on the LEDs.

For many LPD8806s, keep in mind the RAM limit. There's only 16K, and usually about 3K is needed for USB buffers and other essential stuff (you can edit the code to reduce the number of USB buffers, if necessary). 4096 LEDs might be able to work, but using 12K for a frame buffer will be a tight fit and not leave much room left for the stack and other memory usage.

Teensy++ 3.0 will have a lot more memory. We're currently waiting for Freescale to release the chip it will use. The info is currently under NDA, so I can't discuss the details, other than it will have significantly more memory.
 
What video player you use to communicate plug and play, with teensy3 (VideoDisplay).

You need to use Processing.

http://www.processing.org/

It looks very similar to Arduino, because the Arduino IDE was originally made using Processing's code. It works more or less like Arduino, except the programs run on your computer and the language is mostly about graphics instead of hardware. The VideoDisplay example has a folder called "Processing", with the movie2serial program you need to open with Processing.

When you get it running, it should look like these screenshots from the OctoWS2811 page.

td_libs_OctoWS2811_5.png


td_libs_OctoWS2811_20.jpg
 
It's 6a in Oregon! Another kindred soul who is up early - I've been up since 5:30a on the east coast.

Thanks Paul. I will certainly be looking into the WS2811 vs LPD8806 as I scale up what I am doing. And thanks for pointing out the potential memory limitation and your Teensy++ 3.0 plans. Hopefully by the time I am ready to scale up, you have the new board available.
 
It actually looks like I can get closer to 11Mbps with the LPD8806's before they start glitching out on me. Feed that into the math above for LPD8806 vs WS2811 from a timing standpoint :)
 
With some grounding I'm able to get the strip up to almost 15Mbps, but I get glitching beyond about 210-220 leds in a single strip. Need to see if there's more I can do with this. Paul - I may put up another release of the library sooner rather than later to get the real teensy 3.0 SPI out the door, then focus on DMA (I was going to wait until I got DMA working as well).
 
Also - once I get the library stuff settled down on the LED side, as well as get a couple more personal projects wrapped up and out the door, I'd like to investigate making the SPI portion of the library useful in both directions, vs. right now where it's useful for sending data out over SPI. (This version of the library has the SPI and Pin access code all broken out so people can use that for things other than LEDs because, well, I was shocked to discover, but there are other things people use these devices for than LEDs! :)
 
If your code just waits for the data to transfer, native code using the FIFO will probably be the same speed as using DMA. You really only need DMA if you're going to allow other stuff to run while the data is moving.

A more general API sounds great. :)
 
Right - I want the DMA support because right now, I can basically do ~750k rgb led updates/second, but that's if I devote nearly 100% of the CPU to pushing updates. Being able to dedicate most of 48/96Mhz of CPU time to pattern generation with the leds updating in the background has a certain appeal to it.

The SPI library right now is usable for non-led related stuff if all you are doing is writing. but you can say something like:

Code:
SPIOutput<11, 12, 0> SPI;
SPI.init();
SPI.writeBytes(myData, nDataBytes);
[CODE]

And based on the platform you're on and the pins you choose it'll make the decision to use hardware or software spi and if hardware will use AVR SPI or ARM SPI appropriately (in theory, there's AVR USART in SPI mode support, but it's not working at the moment).

The way this API looks publicly is still in a bit of flux, though (part of why i'm still calling these releases preview - I want to get feedback on how people are using it and nudge things around a bit).  I should get some SPI peripherals and play around with the SPI code and them to see if any other use cases/API needs shake out that I want to get worked in.

Obviously, for DMA'd transfers there needs to be some methods for "are you done yet?" and friends.
 
Yup, you found my little serial2parallel program. It's limited to streaming from the PC without double buffering and without the ability of the microcontroller to do anything, other that just move the data from USB to the LEDs.. At least a few people used it to build very large and impressive LED projects.

It was inspired by earlier work by Phil Burgess using the FTDI chip. Here's the link:

http://www.paintyourdragon.com/?p=225
 
Status
Not open for further replies.
Back
Top