Some questions about the 16 way work.

Archive FastLED Archive
1

Some questions about the 16 way work.

Given a simple sketch on a teensy 3.0 how long should an update take for 185*16 lights? Would I gain anything by moving to a 3.1 or am I gated by the speed of updating the lights?

-Zeke

2

What lights are you using?

3

If you are writing linearly, then it would take 88.8ms to write all the LEDs (30us per led). With the 16 way output, it would take 5.5ms to write out the same frame (roughly). I believe it works as well on the 3.0 as the 3.1.

4

@marmil if he’s asking about parallel output it is ws2812’s since that’s all I support for parallel at the moment :slight_smile:

5

The 3.1 only has more memory (compared with the 3.0), clockspeeds and instructions are the same I think.

6

Thanks Daniel that makes sense. Yes I’m using WS2812’s. Also this board is actually a teensy 3.1 (I have one of each set up right now).

Unless I’m measuring incorrectly (which I probably am), I’m getting about 1ms per show(), but there’s a lot of variability (some Shows are 4xx ms some are 14xx ms.

-Zeke

#define FASTLED_ALLOW_INTERRUPTS 0
#include<FastLED.h>

#define NUM_LEDS_PER_STRIP 185
#define NUM_STRIPS 16

CRGB leds[NUM_STRIPS * NUM_LEDS_PER_STRIP];

void setup() {
// put your setup code here, to run once:
LEDS.addLeds<WS2811_PORTDC,16>(leds, NUM_LEDS_PER_STRIP);
LEDS.setBrightness(128);
Serial.begin(115200);
}

void loop() {
// put your main code here, to run repeatedly:
static byte hue = 0;
static unsigned long beginTime = micros();
static unsigned long endTime = 0;
static unsigned long averageTime = 0;

for(int i = 0;i<NUM_STRIPS * NUM_LEDS_PER_STRIP;i++)
{
  leds[i] = CHSV(hue,255,255);
}

beginTime = micros();    
LEDS.show();
endTime = micros()-beginTime;
averageTime += endTime / 16;
Serial.print(endTime, DEC); 
Serial.print(", ");    

if(0 == hue % 16)
{
  Serial.print("avg: ");
  Serial.print(averageTime);
  Serial.println();
  averageTime = 0;
}
hue++;

}

7

@Kasper_Kamperman it also has 2 hardware spi buses.

@Zeke_Koch this is because for ws2812 and friends, FastLED enforces a maximum 400hz refresh rate.

8

3.1 also has a superior internal bus structure. When clocking faster than 48 MHz, and especially if you edit boards.txt to enable 120 MHz overclock, it helps compute-intensive code run faster. For such a simple program, this probably make little or no difference. But when you do complex animation, or if you also run the audio library and use compute-intensive stuff like synthesis & filters & effects, it can make quite a dramatic difference.

9

Another wonderful lesson in premature optimization. I started down the ‘am I gated by led refresh speed’ because I ran the noise example on my art piece and it ran dog slow.

I just went in and threw in timing code everywhere and discovered the real culprit.

That’s because all of the time was spent in fillnoise8. That example program assumed a square array, but my car is 16x185 so it’s very, very much not square. Tweaking it to be rectangular instead of square both increased perf by an order of magnitude and saved a HUGE amount of memory.

Is there a reason you have that square in NoisePlusPalette?

10

Because the initial hardware we had were square matrices - but also, see this comment/bit of code:

  // We use the value at the (i,j) coordinate in the noise
  // array for our brightness, and the flipped value from (j,i)
  // for our pixel's index into the color palette.
  uint8_t index = noise[j][i];
  uint8_t bri =   noise[i][j];

That flipped value won’t buffer overflow, but it does mean some weird boundary lines in the noise values you are reading.