Came on something I don't understand. Not really a FastLED question but...

Archive FastLED Archive
1

Came on something I don’t understand. Not really a FastLED question but…
when I use NUM_LEDS in math from
#define NUM_LEDS NUM_LEDS_PER_STRIP * NUM_STRIPS
I cant figure out what the heck is going on. But…
#define NUM_LEDS (NUM_LEDS_PER_STRIP * NUM_STRIPS)
and everything works as expected.
FastLED 3.1 Arduino Due 1.6.4 on pins 25,26 2x8 strip

–John

2

Without seeing the rest of your code, it’s hard to tell - post it up to gist of pastebin?

3

Is that not just a simple syntax issue here ?

(NUM_LEDS_PER_STRIP * NUM_STRIPS) gets evaluated and that value is used for the definition of NUM_LEDS

While…

NUM_LEDS_PER_STRIP * NUM_STRIPS would probably assign NUM_LEDS_PER_STRIP (or NUM_STRIPS… I do not know for sure which?) for the definition of NUM_LEDS.

4

What is happening is at my math location I was /NUM_LEDS but at that location if I /(NUM_LEDS) it works. So what is happening is really /NUM_LEDS_PER_STRIP * NUM_STRIPS
8 leds 2 strips so
255/16 != 255/82
I assumed the 82 happened at the define location but it must happen again everyplace that you have NUM_LEDS.

5

Was this already known? Cause I am going to use #define NUM_LEDS (NUM_LEDS_PER_STRIP * NUM_STRIPS)

6

@JP_Roy you’re mistaken on that.

@John_Herren Ok, what you’re seeing is a math precedence issue.

When you have a #define macro basically it just tells the compiler “when you see this thing, put in this other thing before doing any compiling or parsing or evaluating expressions”. So, when you have:

#define NUM_LEDS NUM_LEDS_PER_STRIP * NUM_LEDS

and a statement like:

255/NUM_LEDS

then the substitution is literally:

255/NUM_LEDS_PER_STRIP * NUM_LEDS

and the 255/NUM_LEDS_PER_STRIP gets evaluated first[1] and then that result is multiplied by NUM_LEDS.

When you do:

#define NUM_LEDS (NUM_LEDS_PER_STRIP * NUM_LEDS)

when the substitution looks like:

255/(NUM_LEDS_PER_STRIP * NUM_LEDS)

now, the order precedence is on the multiplication first, then the division.

[1] See Order of operations - Wikipedia for more info on this type of thing with math

7

(which is a long, roundabout way of saying, yes, if you’re worried about using NUM_LEDS in math operations, wrapping the definition in ()'s is a good way to ensure that it’s evaluated consistently, and how your’e expecting)

8

Math precedence? Oh yeah I think they taught me something about that some years back. About the same time I was waiting for the mailman to bring the Users Manual for that killer new chip, the Z80. I was good until the 8086 and 8088 and then I was in over my head. They made Arduino simple enough for me to get back into this stuff again. I just assumed that the 8*2 was done and finished at the #define location. Took me two hours to figure it out. Thanks for the conformation and thanks for FastLED!

9

“#define” is a preprocessor macro – it just substitutes the text into your source code wherever it appears, AND THEN the compiler kicks in and does the whole order-of-operations thing. “#define” is just a text macro substitution into the source code later on.

10

DOH!

I know for sure now that I learned it a few decades ago… How could I forget :wink:

Actually my first idea was to post something like…

“Doctor, my arm hurts when I move it like this !”

" … then don’t move your arm like that!!"

In retrospect, it was a better answer than the one I posted… :wink:

11

It’s a good idea to always put extra parens around things – especially so in a “#define”. Reduces potential error and ambiguity, and doesn’t “cost” anything in terms of executable size or speed.