mhenstell wrote:would you mind sharing the teensy sketch you were using to pump data from USB out to SPI, if you still have it?
Sure, why not?
Well, actually, one good reason would be because nobody has written corresponding code on the Processing side, to convert a video stream to the bits-packed-in-bytes format this needs. Philip intends to do so at some point, but he's been very busy and unable to work on this. He wanted to avoid a problematic tech support situation. Since then (I wrote this on March 2, 2012), several people have expressed interest and I've emailed the code, but never posted it publicly anywhere.
Well, maybe it's worthwhile to just make it available here? It's sort a catch-22 situation, not releasing publicly because nobody has written the host-side code, but few (if any) people are working on the host side code because the device side isn't publicly released.
One caveat is this code requires reformatting the LED data. It drives 8 strips, not just one. So you need to divide the image into 8 bit streams, and then pack them into bytes. Each byte you send causes 1 bit to shift out to each of the 8 LED strips. This code also requires you transmit data in multiples of 64 bytes. If your strips plus the end-of-frame latch stuff works out to be less than a multiple of 64, you must pad the end with zeros (or anything you like) to make the total write a multiple of 64. Of course, don't just send 64 bytes at a time, write the largest mulitple-of-64 block you can, so the USB host controller and drivers handle it efficiently (especially on Windows which has some special driver limitations).
So, with all these issues in mind, here it is.
This forum wouldn't let me upload a .pde or .ino extension, so I changed it to .txt. Changing the extension back ought to be the least of your worries. The special organization of the bitstreams will require some significant coding. Until somebody does that, this code is pretty much worthless, other than proving 1 Mbyte/sec speed is indeed possible.
This code is extremely fast. It's able to keep up with full speed (12 Mbit/sec) USB. In fact, in the 3 #defines, you can usually add 3 more nop instructions for even slower waveform output and still (usually) keep up with data at full USB speed. The main speed limitations are scheduling limitation in the USB driver code (especially on Windows) and bandwidth taken away by other USB devices.
On the other USB devices issue, on thing that helps is connecting Teensy through a USB hub. Hubs have a "transaction translator" (TT) which converts from 12 Mbit/sec to 480 Mbit/sec in crafty ways. Some hubs have only a single TT, so they only optimize bandwidth to 1 device. Other hubs are "multi-TT", where they optimize all connected devices. On Linux, you can use "lsusb -v" and look through the long list for you hub to check which type it is.
Good luck, and please, if you redistribute this code (as its open source license allows), I would like to personally request you do so only together with a well documented example that sends data in the special format it requires.