WS2811 on Teensy 3.0 using FastSPI_LED library

Status
Not open for further replies.
I noticed that mine went slightly yellow towards the end of the strip, but I put that down to the current limit of my laptop USB. I need to get out my old power supply to see if it changes anything :)
 
mjlynch712 said:
I noticed that mine went slightly yellow towards the end of the strip
Click to expand...

Perhaps the 5 volt power is something like 4.2 or even 3.5 volts near the end of the strip? Those wires are tiny, and towards the beginning of the strip the current is quite high. The blue LED needs more voltage than the red and green, so if you're suffering from a voltage drop, you'd expect to see yellow tint. It's easy to just connect the power at both ends and see if the yellow tint problem goes away?
 
Tint problem was caused by limited current

PaulStoffregen said:
Perhaps the 5 volt power is something like 4.2 or even 3.5 volts near the end of the strip? Those wires are tiny, and towards the beginning of the strip the current is quite high. The blue LED needs more voltage than the red and green, so if you're suffering from a voltage drop, you'd expect to see yellow tint. It's easy to just connect the power at both ends and see if the yellow tint problem goes away?
Click to expand...

So in playing around with the WS2811 strip tonight I realized that this is exactly what was causing my color tint problems.
The wall wart that I was powering the LED strip was limiting the current at 700ma
The manufacturer claims that the strip is 18w/m or 60ma/pixel at full brightness.
This would be a total current draw of 3.6A for a 1 meter, 60 LED/m, 5V strip.
I hooked a 1 meter strip to a lab power supply to see what I could get.
At around 0.9A, the tint disappeared when the strip was set to white, and the pixels all appeared to be a consistent pure white...Yay.
I hooked both ends of the 1m strip up to the power supply, and at 5.0V the strip only drew 1.22A
I got daring, and over drove the strip to 5.5V and the strip drew 1.46A...Well below the manufacturers claims.
This was as high as I dared go, and noticed that after about 10 minutes of color cycling, the LEDs felt slightly warm to the touch.
5.5 V would probably be too high if the light strip was left on Full White (255,255,255) for any length of time without cooling.
There was a noticeable brightness difference between 5.0 and 5.5V.
In the end, I'll probably set up to drive my full project at 5.3V, with power hookups at a minimum of 1 per meter.

Now I'm getting excited about those 68 LED/m strips!
 
Wozzy said:
I see that they now have a new product with 68 LEDs/m GE68RGB2811x which is available in black or white, water proof or non water proof.
Here's a Link: GE68RGB2811
Click to expand...

I don't see any prices there, but these folks have 4-5m strips of 60 LEDs/m for ~$12 per meter, and strips of 30 LEDs/M for ~ $7/m:

http://www.aliexpress.com/store/pro...lt-in-tthe-5050-smd-rgb/701799_633124138.html
http://www.aliexpress.com/store/pro...ilt-in-the-5050-smd-rgb/701799_653641294.html

I just ordered some from them, no other connection.

-c
 
I inquired about the LED strips from Gree LED and they said
GE68RGB2811A Non-waterproof $14.00/m
GE68RGB2811C IP67 waterproof $14.50/m
And it was $25.16 shipping to the UK via DHL

The strips I currently have came from here

I have no connection to any of these companies
 
Last edited:
I tested FastSPI_LED on a Teensy 2.0 using a strip of 20 WS2811. It worked perfectly.

I did have to make one tiny edit to get it to compile, but no substantial changes were necessary.
 
A possible workaround for lack of CS on these would be to change the SPI DOUT Mux - so have your SD card on pin 11 for DOUT, say, then the LED strip on pin 7, and switch the Mux as needed. You'll have to make sure the GPIO of the DOUT pin used for the LEDs is in a harmless state when it's switched away from SPI (output high, I suppose?)

Just make sure you're not doing something with both devices at once.

- Peter
 
Oh hi, I'm very late to the thread but I've been using the Teensy 3.0 on the WS2811 integrated LED strips for a while.

I *just* posted up random pics and videos, but I've had it for a while now. I am using a modified FastSPI library with corrected timings for the chips. The array is 720 LEDs, so no problem with many LEDs. The Update rate can be still pretty respectable even with many LEDs.

Videos and pics here :

http://www.madox.net/blog/2013/01/16/project-sneak-peek-and-procrastination/
 
Nice work, Madox. Can you share a few more details? On your website you mention a controller board that sat between the t3 and leds, and would love to know what changes you made to the FastSPI library to make it work with the WS2811 chips.

Thanks!
David
 
Hi David,

The T3 is connected directly to the LEDs and drive's the LEDs. It receives data from the USB until a 720*3 byte buffer is filled then draws that onto the LEDs.

Since the FastSPI uses NOPs, work can't be done while the data is being sent to the LEDs - this is similar to Paul's code above. I'm interested in the DMA code but I really don't need it for my application.

From memory the "TM1809" is the similar chip in the FastSPI library and you need to change the number of NOPs the library calls. The LEDs with the integrated WS2811s only work off 800 kHz AFAIK.

I'm using FastSPI with a Teensy 3.0 at 48Mhz. My timings are :-
LO ON Time - NOP12 - 250ns
LO OFF Time - NOP48 - 1000ns
Hi ON Time - NOP28 - 600ns
Hi OFF Time - NOP32 - 650ns

In hindsight, I should have dropped 1 NOP operation from each but it seems to work :)

Paul's timings from his NeoPixel post above seems to be completely different but that might be relying the 'trick' or quirk someone else mentioned. I pulled my timings off the datasheet.

I had some luck driving the WS2811s using 'SPI' too. At 3.2Mhz each bit can be stuffed into a nibble and driven out that way.
Lo On - 1 312.5
Lo Off - 3 937.5
Hi On - 2 625
Hi Off - 2 625
The timings end up within spec and working as well and a bit nibble means you need 12 bytes for every pixel you want to draw though...
 
Hi Madox,
Thanks for the detailed info.

I'm a bit new to the inner workings of the teensy (and all micros for that matter) and am trying to learn (one of my resolutions this year). I need help with a couple terms that have come up in this thread:
NOP = ?
DMA = ? (something that was mentioned earlier in this thread)

I've seen DMA support mentioned in other threads/forums as something that should give us LED bliss once solved, but am clearly in the dark (so to speak) on what it is referring to.

Thanks in advance for the guidance!

David
 
Dave,

Admittedly, I have very poor assembly language skills, But a NOP is machine specific Assembly language for "No Operation" It's essentially a pause to skip one instruction cycle. It's period is dependent on the chips oscillator frequency, and the number of clock tics per instruction.

DMA is "Direct Memory Access" DMA allows the peripherals of a chip to directly access memory, without the need of the core processor. For example, if the Hardware SPI module in the Freescale Microcontroller can read and stream out an array of data directly from the EEPROM, or better yet, a Micro-SD card, it can then be run as a background process that allows the core processor to do other work simultaneously.

For controlling RGB LED light-strips, This could be very useful for allowing one to push complex lighting patterns at high frame-rates , while allowing the processor freedom to calculate new patterns, or read sensors and react to inputs.
 
Last edited:
Brilliant. I am now enlightened ;) Thank you!

Now I just wish I knew more to help the efforts in making a DMA version of the library or a softSPI library. Those WS2811 + 5050 RGB LED's are pretty sexy, but I too have the same issue wrt multiple devices attached to the SPI chain (in my case a wireless radio). I'm certainly happy to beta-test if that's a help.

Thanks again!
David
 
virtualdave said:
Now I just wish I knew more to help the efforts in making a DMA version of the library or a softSPI library.
Click to expand...

My idea, which I'm planning to actually work on after publishing beta 12, involves using 3 DMA channels triggered by the edges from a pair of PWM signals. It may be possible to trigger the DMA channels using a the PIT and PDB timers, but for a first attempt I going to go the simpler (and observable on an oscilloscope) route that will consume a few pins.

The PWM will be 800 kHz on pins 3 and 4, which are controlled by the same timer. Both pins go high at the same instant. Pin 3 will stay high for 250 ns (the WS2811 waveform of sending all zero bits), and pin 4 will stay high for 600 ns (the WS2811 waveform of sending all one bits).

The rising edge of pin 3 will trigger DMA channel 0. That channel will be configured to read a fixed location and write a fixed location. The read will be a byte in memory containing 0xFF. The write will be the low 8 bits of I/O port D (which is pins 2, 5, 6, 7, 8, 14, 20 and 21).

The falling edge of pin 3 will trigger DMA channel 1. That channel will read an incrementing location (the RGB image data) and write to a fixed location (port D). For each bit that's 0, the WS2811 will see a 0 write, because the previously written 1 will change to 0 at this point 250 ns later. For each bit that's 1, the pin will remain a 1.

The falling edge of pin 4 will trigger DMA channel 2. That will be configured like channel 0, except the memory will contain 0x00. For the bits that remained high, they'll go low at the correct 600 ns timing so the WS2811 sees a 1 bit. For the bits that went low earlier, they'll remain low.

This scheme should allow a large buffer to stream 8 strips of WS2811 LEDs without any CPU overhead. Of course, each 1250 ns, three single-byte DMA transfers occur, taking 6 bus cycles plug probably a few more for bus arbitration. During the 1250 ns period, the internal bus has 60 cycles available, so the DMA will consume about 10-15% of the available bus bandwidth. Fortunately, the chip has a switched mux matrix, and the RAM has 2 separate busses (one for the low half, another for the high half), so this activity should have minimal impact on code execution because separate buses are used, and if the RGB pixel buffer is placed in the lower half of RAM, it should have minimal impact on the CPU's access to the stack (the other thing that matters for code performance).

At least that's my crazy plan.

There are a couple minor details about triggering on those edges, which will involve jumping certain pins together. The RGB buffer will also have a somewhat strange layout, where each byte in RAM is actually a single bit for 8 different LEDs. A little crafty code can abstract that away for simple animation running on the chip. For people who want to stream video from a PC, they'll probably need to pre-arrange their data before transmitting it over the USB.

I'm also considering a double buffering scheme to allow smooth animation.....
 
Last edited:
One possible problem with DMA, might be latency to gain access to the bus. My understanding is 2 things could initiate lengthy bus busy times... the CPUs interrupt entry/exit which stacks several registers automatically, and the various instructions that read/write/push/pop many registers. In theory, a single ARM instruction can write or read all the registers to/from RAM. I'm pretty sure the processor implements that as a single bus access, which the DMA engine would (probably) need to wait until the transfer is finished. The WS2811 wants pretty tight timing, so that might be too much latency?

In practice, that sort of activity probably only happens to the stack. If it does become a problem, it may impose a limit of placing the pixel buffer in the unused portion of the lower half of RAM (which has a separate bus). The USB buffers are also located down there, so not all of that memory is available for pixels. The memory issues might limit this scheme to a maximum of approx 2000 LEDs.
 
Hah, I love it :)

Hmm now I'm wondering if a circular buffer could be filled fast enough from SD to keep up with the ~800k/sec needed. Certainly I can get approx double that from an SD card on Teensy3, when sequential reading from a file. But it would rely on not getting any slowdowns, like fragmented data or anything.. and of course then there's the extra bus overhead to deal with.

Even still... :)

- Peter
 
Updating 2000 LEDs this way takes only 7.5 ms. Even if reading 6000 bytes from the SD card took twice that long, you'd still achieve a 60 Hz update rate.
 
Indeed, though if you could fill the buffer fast enough to keep up during the refresh, you could do more than 2000 LEDs.

Not that I actually have an application for this, or can really justify buying >2000 LEDs. But hey :)

- Peter
 
those strips look great but when I google them, I don't find a way to order easily. Looks like they expect huge volume orders. Suggestions?

thanks
Charlie
 
Charlie,

GreeLED definatly does not make it easy to purchase their product..
The only way is to get a quote via email, then send them a western union money order, or arrange a direct money transfer.
While I know of several people that have successfully purchased from them, this type of transaction makes most people very nervous.

If anyone knows of a supplier or reseller that carries GreeLED, let me know
 
PaulStoffregen said:
Updating 2000 LEDs this way takes only 7.5 ms. Even if reading 6000 bytes from the SD card took twice that long, you'd still achieve a 60 Hz update rate.
Click to expand...

Hmm... So around 30ms for 8000? If so that's fast enough. I'm doing a 128x64 Video wall and had written off the WS2811's thinking one could never get that kind of speed.
 
hunter said:
Hmm... So around 30ms for 8000? If so that's fast enough. I'm doing a 128x64 Video wall and had written off the WS2811's thinking one could never get that kind of speed.
Click to expand...

You'll need Teensy++ 3.0 for 8000, because Teensy 3.0 doesn't have enough RAM. Or in the near term before T3++ comes out, four Teensy 3s would be the best plan.

Of course, this all depends on software the doesn't exist yet..... but I will be working on it soon.....
 
Status
Not open for further replies.
Back
Top