I'm using fastled with Octows2811 controller and les per strip at 300.

Archive FastLED Archive
1

I’m using fastled with Octows2811 controller and les per strip at 300.
I’m getting 10,000uS for LEDS.show();
Is that correct?

2

10ms? That sounds high - can you post the code you’re running to gist and link to it here - also what clock speed are you running the teensy at, and which teensy are you using? Finally - what version of Arduino (and Teensyduino) are you using?

3

ok… gimme a sec
was thinking it should be around 2ms if I’m understanding fastled documentation

4

96Mhz.
teensy 3.2
arduino 1.82
teensyduino 1.37

//fastled speed test
#define USE_OCTOWS2811
#define LED_TYPE OCTOWS2811
#include<OctoWS2811.h>

#define FASTLED_ALLOW_INTERRUPTS 0
#include “FastLED.h”

#define COLOR_ORDER BRG
#define NUM_STRIPS 8
#define NUM_LEDS_PER_STRIP 300

CRGB leds[NUM_LEDS_PER_STRIP*NUM_STRIPS];
#define BRIGHTNESS 255

elapsedMicros showTime=0;
void setup() {
LEDS.addLeds<LED_TYPE,COLOR_ORDER>(leds, NUM_LEDS_PER_STRIP); //i use this for teensy 3.2 when using octows2811 library

// set master brightness control
FastLED.setBrightness(BRIGHTNESS);
}

void loop() {
// put your main code here, to run repeatedly:
static uint8_t hue = 0;
for(int i = 0; i < NUM_STRIPS; i++) {
for(int j = 0; j < NUM_LEDS_PER_STRIP; j++) {
leds[(i*NUM_LEDS_PER_STRIP) + j] = CRGB::Red;
}
}
showTime=0;
LEDS.show();
uint32_t ledShowTime=showTime;
Serial.print(“LEDS.show() took: “);
Serial.print(ledShowTime);
Serial.println(” uSeconds”);
}

5

Your code isn’t setting the showTime values at all - are you sure that’s right? (Also - please post code to http://gist.github.com - not into comments here - the formatting messes up constantly on mobile)http://gist.github.com

6

I think it’s right. It’s printing values around 10000.

I think elapsedMicros is a teensyduino/pjrc thing (if that’s what your talking about).
Very handy.

7

Gist.github:
http://gist.github.com - gist:887f401d003ef604f966e8510d6e02d2

8

Ah - right - I see what elapsedMicros is doing now. 10ms still sounds high - there’s a slim chance you’re getting bitten by code that tries to cap frame rate/finish DMA output before switching over - which would increase the amount of time in there - for laughs, put a delay(100) before the showTime=0; line - and see if that affects the printed values at all. (I don’t have any hardware handy to test here right now)

9

I get on it now…

10

Well that is interesting…
LEDS.show() took: 3221 uSeconds
LEDS.show() took: 3217 uSeconds
LEDS.show() took: 3215 uSeconds
LEDS.show() took: 3216 uSeconds
LEDS.show() took: 3215 uSeconds
LEDS.show() took: 3216 uSeconds

Thats closer to what I expect…
I’m running fastled 3.1.5

I’m going to sleep but can someone point me to a link in fastled documentation where it talks about fastLED.show() in relation to calling it quicker than leds can be updated.

I know we are talking about a bug in this case, but it occurs to me now that my light sequence code isn’t right.

I’m updateing one frame every loop and running fastled.show() every loop, however I believe on any loop where fastled doesn’t update (becuase looptime was shorter than ws2811 update time (9ms in my current config) then I will be skipping frames.

I’m hoping fastled.show() has a return value or something to help me out here. something like while(!fastled.show());

I may have to think about this more as I may be better processing serial comms in this time…

Actually probably want to set a frame rate too and still do usefull stuff in the wait time.

sleep now.

11

Ok - I see/know what’s happening. When you call LEDS.show() when it is using OctoWS2811 - it has to wait for the previous frame to finish writing out before it can start writing out the new frame.

While FastLED itself will only take about 2.5-3ms to do all the data prep for the frame (scaling/dithering/rgb reordering, and packing it in the format that OctoWS2811 wants internally) - it will take ~9ms to write out all the led data (the WS2811 data protocol is about 800khz, it takes roughly 30µs to write out a single LED worth of data (or, in the case of OctoWS2811, it takes 30µs to write out 8 parallel LEDs worth of data). You have 300 leds on each strip, which means it is going to take a minimum of 9ms for all the data to be written out.

So, what you’re seeing is that when you were running the loop as quickly as possible, LEDS.show() was taking about 2.5ms (give or take) to prep the data for OctoWS2811, but then it was waiting for another 7.5ms or so for the previous frame to finish writing out.

With 300 leds on each strand, you’re going to be maxed out at about 100fps.

When you’re spending more time in between calls to LEDS.show(), it means that more of the previous frame’s data will have been written out by the time you call LEDS.show() (in fact, it may even be finished) - in which case, LEDS.show() won’t have to wait for writing the frame to be finished, so it can return faster.

12

LEDS.show() will always try to write led data - if it has to, it’ll wait until it’s ok to write data again. (You can override FastLED’s internal frame rate limiting by calling LEDS.setMaxRefreshRate(10000) or something equally high – however, that won’t help you in this case, because OctoWS2811 blocks until it has finished writing out the previous frame).

13

Roger that. That’s cleared up everything for me. I’ll have to try harder to use up more teensy cycles on animations.