BlynkTimer revisited

Solved
1

Hi,

With the BlynkTimer library, I noticed that some people add the L (long) character after the number as

timer.setInterval(1000L, myTimerEvent);

However, the library code is expecting already an unsigned long number

// Timer will call function ‘f’ every ‘d’ milliseconds forever
// returns the timer number (numTimer) on success or
// -1 on failure (f == NULL) or no free timers
int setInterval(unsigned long d, timer_callback f);

I know it doesn’t do any harm adding the L but, for space crunching, is really needed that extra byte?

2

Isn’t this “extra byte” only in source code? I don’t expect it to occupy flash memory… (?)

3

OK, as I said, it does no harm even if we want to be pickier by using UL instead of L.
I just wanted to satisfy my curiosity. Thanks

4

On some platforms, int is 16-bit, so numbers like 120000 can’t be represented.
In millis, this is just a 2min interval…
If your MCU is 32-bit, you can skip this, but still keep in mind. Yes, the specifier is only in the source code, but may impact the way the code is generated.

5

@vshymanskyy So, is it safe to say that we should use the data type UL for the BlynkTimer library just to be in line with the data type used in the library itself? In the SimpleTimer library, the L data type was used.

6

UL is unsigned, L is signed. no problem using L whenever you aren’t using the most significant bit, which is 99.999 situations