Marc Miller said that:

Marc Miller said that: “FastLED.delay() calls FastLED.show() under the hood so you shouldn’t need both as consecutive lines.”

That is something I did not know. I tested this, and yes, it displays with just a FastLED.delay() call.

Unfortunately, that call doesn’t support power management, i.e.

set_max_power_in_volts_and_milliamps(5, 500);

and

show_at_max_brightness_for_power();

This tells me that if you’re using delays and power management in your display, then you had better not use FastLED.delay().

My recommendation would be (that unless there are issues we don’t know about with power management) to:

  1. Set a default value for the current to be ‘0’ (aka unlimited).
  2. Change FastLED.show() to be power managed.

Thoughts?

Edit: I’d better make sure I’m using delay_at_max_brightness_for_power()

Well… delay() doesn’t ALWAYS call show, I think. It only calls it if there’s time to do a show() before the delay() time is up.

UPDATE: Nope, this is wrong. Here’s what’s right:

FastLED.delay() basically always does { delay(1); FastLED.show() }. There are two cases where it doesn’t:
(1) if the delay value == 0, then FastLED.show() is NOT called by FastLED.delay()
(2) if the delay value == 1 AND the millis() timer ticks between the first read and the second read inside delay(), then show() will NOT be called.

But if the delay value is 2 or more, FastLED.delay() calls FastLED.show().

There is also the power-managed version of delay:

delay_at_max_brightness_for_power( uint16_t ms)

Bottom line, I think is exactly what Andrew said at the top: “if you’re using delays and power management in your display, then you had better not use FastLED.delay().”

Or to put it another way, don’t MIX the power-managed versions of show/delay with the NON-power-managed versions. EITHER use these
show_at_max_brightness_for_power();
delay_at_max_brightness_for_power( uint16_t ms);
OR use these
FastLED.show();
FastLED.delay();
…but don’t mix them, otherwise you lose the power management controls.

In an ideal world, we’ll get the power management integrated into regular FastLED.show() and FastLED.delay(), but right now they come with a (small) performance overhead that we don’t want to impose on people who aren’t using them.We’ll get there eventually, but for now the separate APIs are the way to go.

Thanks for pointing that out Andrew, as I have not tried out the power management stuff yet.