Maximum sizie of WS2811 displayMemory

Status
Not open for further replies.

artag

Active member
I'm using teensy 3.2 to drive 4500 WS2811 leds. For $reasons, they're connected to only 3 of the outputs, so ledsPerStrip is 1500.

Yes, I realise this isn't the most efficient way to do it, but for the moment it has enough performance (or at least, it did when there were only 1200).

If I change the leds to a number above 1365, the code doesn't run (or rather, it runs once and then crashes / halts).

I'm using single-buffered mode (drawingMemory set to null) so it's not running out of ram, but perhaps there's a limit on how much DMAMEM is available ? It's notable that 6 * 4 * 1365 (the size of displayMem) is 0x7ff8.
 
perhaps there's a limit on how much DMAMEM is available ?

Yes, only half the 64K memory can be used as DMAMEM, and that includes the USB stuff.

When you configure 1365 LEDs per strip, OctoWS2811 is actually driving 10920 LEDs. It doesn't matter if you're using fewer than all 8 of the pins. It still does all 8, so you're configuring it to use 10920 this way. There are limits...

When the K66 board is released, much more memory will become available. :)
 
Yes, I realised I was wasting the memory - I'd had to disable the double buffering when I used too much earlier. I just hadn't realised I couldn't use all 64K for display memory.
 
On the same system (now with ledsPerStrip at 750), I'm trying to use the nRF24L01 with the maniacbug RF24 network library. I'm getting a lot of failures, and it seems to be when the leds.show() call is made. On the sender side I get lots of errors, and on the receiver side I get lots of missing data (90%). I think a few messages get through but timeout on the acknowledge - I do get a few more successful receives than the transmitter appears to see.

I know there are a huge selection of other support libs but that lib worked for me before. I don't yet know about the others.

I first found that I was calling leds.show() frequently enough that it was blocking, stopping RF24 updates. So I now call the RF24 update while leds.busy() is true. This provides a fast poll most of the time but didn't much affect the failure rate.

Any ideas on what might cause this ? Does the DMA clobber the memory bandwidth and make the teensy run slow ? My planned workaround is to give the RF24 control to another arduino and have it send buffered and summarised updates to the teensy, but I'd rather not do that if I can avoid it.
 
When the K66 board is released, much more memory will become available. :)

I'm using the K66 Teensy 3.6 now but it still doesn't work when configuring more than 1365 LEDs per strip.
Does the library need to be adjusted to support the larger memory of the Teensy 3.6?
 
I'm using the K66 Teensy 3.6 now but it still doesn't work when configuring more than 1365 LEDs per strip.
Does the library need to be adjusted to support the larger memory of the Teensy 3.6?

Recently Paul updated the octows2811 product page saying that 1365 LEDs per strip (i.e. 10,920 LEDs total) was the absolute maximum due to the DMA hardware limits.
 
Status
Not open for further replies.
Back
Top