New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.show() blocking loop? #526

Closed
the-magister opened this Issue Nov 21, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@the-magister

the-magister commented Nov 21, 2017

In .show():
void CFastLED::show(uint8_t scale) {
// guard against showing too rapidly
while(m_nMinMicros && ((micros()-lastshow) < m_nMinMicros));
...

That looks like a blocking while() loop. Would it introduce problems to change this to use the yield() function? For an AVR, this probably translates to a NOP. For devices with other "background" tasks (I'm looking at you, ESP8266), this would allow the WiFi stack to get serviced.

void CFastLED::show(uint8_t scale) {
// guard against showing too rapidly
while(m_nMinMicros && ((micros()-lastshow) < m_nMinMicros)) { yield(); }

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 21, 2017

Member

It is blocking, but only for cases where a maximum frame rate has been specified (e.g. for the 400hz specified by WS2812 leds, that would mean it'd block for a maximum of 2.5ms) - given how long show often blocks for without calling yield while writing out led data (milliseconds, if not dozens of milliseconds), I'm not sure that a yield here would buy you much.

Member

focalintent commented Nov 21, 2017

It is blocking, but only for cases where a maximum frame rate has been specified (e.g. for the 400hz specified by WS2812 leds, that would mean it'd block for a maximum of 2.5ms) - given how long show often blocks for without calling yield while writing out led data (milliseconds, if not dozens of milliseconds), I'm not sure that a yield here would buy you much.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 21, 2017

Member

In fact, if i remember right, ESP8266 wifi is handled via interrupt, and interrupts will be handled in this while loop (they don't get disabled until writing out led data).

Member

focalintent commented Nov 21, 2017

In fact, if i remember right, ESP8266 wifi is handled via interrupt, and interrupts will be handled in this while loop (they don't get disabled until writing out led data).

@the-magister

This comment has been minimized.

Show comment
Hide comment
@the-magister

the-magister Nov 21, 2017

the-magister commented Nov 21, 2017

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 21, 2017

Member

Don't use setMaxRefreshRate for this! setMaxRefreshRate should really only be used for cases like the WS2812 where, if you update them at a higher rate than 400hz they start to freak out.

And no - this yield wouldn't change the esp crashing problems (that has to do with interrupts being blocked, not yield not being called) and the default max refresh rate is uncapped (and set automatically to 400hz when using leds like the WS2812 that glitch visibly when you update them at higher than 400hz). I think you're the first person I've heard of that's attempting to use setMaxRefreshRate to control animation speed.

The proper way to manage frame rate (note that this is different from refresh rate) is by using delay (either delay or FastLED.delay) and/or the EVERY_N_MILLISECONDS macros and such.

Member

focalintent commented Nov 21, 2017

Don't use setMaxRefreshRate for this! setMaxRefreshRate should really only be used for cases like the WS2812 where, if you update them at a higher rate than 400hz they start to freak out.

And no - this yield wouldn't change the esp crashing problems (that has to do with interrupts being blocked, not yield not being called) and the default max refresh rate is uncapped (and set automatically to 400hz when using leds like the WS2812 that glitch visibly when you update them at higher than 400hz). I think you're the first person I've heard of that's attempting to use setMaxRefreshRate to control animation speed.

The proper way to manage frame rate (note that this is different from refresh rate) is by using delay (either delay or FastLED.delay) and/or the EVERY_N_MILLISECONDS macros and such.

@the-magister

This comment has been minimized.

Show comment
Hide comment
@the-magister

the-magister Nov 21, 2017

the-magister commented Nov 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment