Last night I was going through my code for a project and found something

Archive FastLED Archive
,
1

Last night I was going through my code for a project and found something that should be a bug, but wasn’t affecting the operation of my project.

To assign a hue or pick a colour from a palette, I’m cycling through the range to 1024 and dividing by 4 to get a value in the range to 256. In one instance, I forgot to put a check in place to rollover my values to 0 if I exceed 1023. This didn’t cause an error. I decided to test by setting my hue value to multiples of 256 (512, 1024, -256, etc) and found that the colour red was returned, the same as if I set to 0. It even worked for negative numbers.

Is this a feature of FastLED that I hadn’t noticed until now? Or is it to do with the functions only expecting a byte, and discarding the rest of the information, and the byte received happening to be the least significant byte?

If so, can I sustainably keep passing values higher than 255 as the hue or colour from palette variable, or will it lead to problems? If I can, it will save me multiple calls to rollover my 1024 to 0, which would be nice.

Thanks for the great library

2

Welcome to C/C++:

“Or is it to do with the functions only expecting a byte, and discarding the rest of the information, and the byte received happening to be the least significant byte?”

This is exactly it. If you try to write a 16 or 32 bit value into an 8-bit variable or parameter in C/C++, only the low 8 bits will get written, there’s nowhere for the higher bits to go!

This is also why FastLED’s HSV function uses a color wheel that goes from 0-255 instead of 0-360.

3

Thank you. That makes sense