OctoWS2811 performance issues

markb

Active member
I noticed some changes to the OctoWS2811 library that have had a negative impact on performance.

The change with the most impact on performance was this one:

https://github.com/PaulStoffregen/O...11530cd#diff-baf1e8544e6d4607249cff6356e85e46

There's a delay(1) in the MK20DX256 case in OctoWS2811::show(). Is there any reason for that? 1ms is quite a lot of time.

Then there was this change:

https://github.com/PaulStoffregen/O...a5cf39a#diff-baf1e8544e6d4607249cff6356e85e46

Here, the previously configurable frameSetDelay has been hard coded to 300us. Previously it was 50us for 2811. I see the commit comment that 300us is required for newer WS2812B pixels, but what is the reason for not keeping this as configurable?
 
Please open an issue on GitHub about the 1ms delay. I'll remove it, but probably can't work on this for a couple weeks. Please, start an issue... and ping me in a couple weeks if I forget.

The 300 us reset time is unfortunately becoming the norm on newer WS2812B chips. Worldsemi is a pretty terrible company when it comes to incompatibly changing their silicon but keeping their part numbers identical.
 
Please open an issue on GitHub about the 1ms delay. I'll remove it, but probably can't work on this for a couple weeks. Please, start an issue... and ping me in a couple weeks if I forget.

Ok, will do.

The 300 us reset time is unfortunately becoming the norm on newer WS2812B chips. Worldsemi is a pretty terrible company when it comes to incompatibly changing their silicon but keeping their part numbers identical.

Yeah, I get that. But can we still have an option for this? Sometimes, that extra 250us is more than I want to give up, and as long as I have compatible pixels, I shouldn't have to. Would you entertain a pull request that adds a flag for this (keeping the default at 300us)?
 
Back
Top