Is there any detail on the new data types introduced by FastLED like uint8_t?

Is there any detail on the new data types introduced by FastLED like uint8_t?

I’m curious if I have a need for basic integers, it’s better to use that than standard int?

Really depends on what you need to do with the number, and what type of micro you are using.

Using an 8 bit micro, you’re likely to encounter uint8_t is equal to unsigned int, so simply using int isn’t critical, but probably bad programming (you can’t assume a size or endian of a type).

If you’re using a 32 bit micro (Teensy, others), then you have the problem where uint8_t is not the same as an unsigned int, and using them interchangeably will have odd affects on your code.

Also, uint8_t is not a new data type, and can be found in most compilers and systems in the stdint.h or cstdint.h header files.

Mostly, uint8_t is used because LED’s have a resolution of 0 to 255 for all operations, so constraining the data type to the max resolution makes a lot of sense.

@Peter_Buelow is mostly right with one small, but important tweak - on an avr, “int” is a 16-bit type - as is unsigned int. This means that any operations you do with an int will take at least twice as long as with a uint8_t (for example, on the avr adding two uint8_t’s together is one instruction cycle, but adding two ints together is two)

Very helpful information! Thanks!

Possibly a dumb question, but would it also help with firmware size? I use uint8 exclusively for LED colors (and basically any variable I need constrained to values of 0-255).

AVR, ESP8266, ESP32 may differ on bit count for “int” and “byte”. Certainly, “word” is architecture dependent. use of “uint8_t” removes any ambiguity.

Having done projects where AVRs and ESP’s must ship data between each other, this is a really good idea!