Daniel Garcia , Yes, this will be a huge challenge.

@Daniel_Garcia ,

Yes, this will be a huge challenge. Are you interested in taking this on? We’d like to do a demo at the open hardware summit coming up this summer.

We figure it will take about 10 DUEs Each DUE controls eight 160 LED strands. Memory and bandwidth will still be an issue.

We could hook you up with some hardware to get started.

What do you think?

I was going to suggest you take a look at using the teensy 3.0 and Paul’s octows2811 library - it is designed for large scale video wall activities like this.

Thanks for the suggestions @Daniel_Garcia . Since this is for the Open Hardware Summit, I’d like to use open source hardware like the DUE. I’ll have a look at that library.

While not open source, the Teensy 3.0 is cheaper than the DUE, albeit a bit slower, but still plenty fast for this. Though for the OHS, yeah the teensy wouldn’t fit. And the OctoWS2811 is open source just like 99.9% of other libraries out there.

The question with the DUE would be whether or not the arm chip in the due supports the DMA architecture that OctoWS2811 depends on.

Another potential issue here that would need to be dealt with, especially if going a DMA route isn’t possible, is that the ws2811 requires disabling of interrupts while writing out LED data - the timing requirements are fairly tight and precise. This means that your protocol for sending data to the DUE’s will need to take into account waiting for them to be in between writing frames of rgb data out. For timing purposes, it rakes about 30µs per rgb led, which means you have, if you use 100% of the cpu 33,333 rgb led updates/second.

Of course, you’ll need to carve out some portion of the CPU time for receiving data from what ever is sending data to your due’s - bringing you down to 16,666 rgb led updates/second and if you want 30fps video that means each due should be limited to 550(ish) leds.

Your 160x8 setup for a single due is going to have a 38.4ms write time, which is going to cap you at 26fps at 100% cpu usage, which means you’re going to get closer to 15-20fps with this arrangement.

I might be able to play games with interleaving ws2811 writes to do multiple strips in parallel, which should up the aggregate data rate per device.

Note that I don’t yet support the DUE in the library - while the teensy 3 is also arm based, i’m not 100% clear on the differences in arm platforms involved. I also don’t have a timeframe for getting DUE support in place yet. I need to get the rest of the library wrapped up and released, in part because I have a handful of large(ish) projects over the next 3 months that I need to start devoting time and attention to.