Arduino Question

Hopefully a quick question for the Arduino experts out there. I have a simple sketch that changes an RGB LED's color, reads a potentiometer, increments a counter. and outputs some text to an OLED display--once per second. The sketch compiles with no warnings and runs (it's super simple and I can post it if need be).

What's weird is:

1. I let it run for 24 hours and when I checked on it, the counter was on about 5,000--which means the Arduino restarted (there were no power glitches that I know of).
2. I let it run for another 24 hours and when I checked, the counter was on -24,000 and counting up (towards zero). This one one is especially puzzling.

The only thing I can come up with is that the counter value (type int) becomes too big and the board freaks. I don't know how that's possible in one day because the value should only get to 85,000. My next step to try is to lose the OLED and output the text to serial and watch it over time.

Is it common for these boards to periodically restart on their own?

Answering my own question--my guess is that an integer overflow is the culprit.

On the Arduino Uno (and other ATmega based boards) an int stores a 16-bit (2-byte) value. This yields a range of -32,768 to 32,767 (minimum value of -2^15 and a maximum value of (2^15) - 1).

You are on the right track with the variable type. According to the Arduino reference (https://www.arduino.cc/en/Reference.Int), Arduino Uno and the like store an int as 2 bytes (16 bits). This means that with a signed value you will have a usable range of -32,768 to 32,767. Since there are 86,400 seconds in a day, that is why it appears to roll over.

You could switch to use a long instead of an int since Arduino stores them as 32 bits which gives you a usable range of -2,147,483,648 to 2,147,483,647.

Great advice. Thanks!

This is just social distance tinkering at this point, but it's clear that I need to spend more time with the docs (which goes against my default, "How hard can it be?" mentality.)

Great advice. Thanks!

This is just social distance tinkering at this point, but it's clear that I need to spend more time with the docs (which goes against my default, "How hard can it be?" mentality.)

No problem! I think you've got the right way of thinking. If you immediately thought it must be very hard, then I'm willing to bet you wouldn't try out a lot of ideas. (I know this concept very well - I've been working on the same project for almost 5 years now...)

Just a little tip: Arduino is built right on top of C, so you can use things like uint32_t or uint16_t instead of defining your variables as "unsigned int" or "long". The "u" means unsigned, so positive only. The "int" means you are storing an integer. The "16" and "32" is the bit size, so you can have more control over the size of the variables. The "_t" signifies that this is a standard across platforms. For example, if you define an "int" on an Arduino Uno then it will be stored as 2 bytes, but the same code running on an Arduino Due will be stored as 4 bytes. So defining a variable as uint32_t guarantees that you have 32 bits of unsigned data at your fingers.

Sweet. The only thing I know about C is that it comes after A and B.

That's not entirely true, but it ain't far off.

I haven’t used C outside of Arduino/esp8266 in a while- I think you just debugged two side projects, great post and answer!

As a follow-up, I changed my sketch to initialize the counter as uint32_t and this morning the counter was on 69,900. I think it's clear that the issue I was facing was an integer overflow.

Cheers for the advice.

The only thing I can come up with is that the counter value (type int) becomes too big and the board freaks. I don't know how that's possible in one day because the value should only get to 85,000. My next step to try is to lose the OLED and output the text to serial and watch it over time.

In case you care, the board isn't actually "freaking out" -- a signed integer is going to be stored in two's complement... in this system, the most significant bit of 1 will indicate a negative number. So if you are just continuing to add 1 eventually when that bit flips over you end up with a negative number. So a good indication for the future is that if you have a counter that goes negative you are overflowing your data type and should use unsigned as suggested.

Some languages add in checks when compiled and throw exceptions when this happens at run time. You will find that C pretty much lets you do what the *(&!^*% you want which is both a blessing and a curse. More than once a computer has almost been bludgeoned to death because a pointer wasn't wrapped in parenthesis before adding ++.

In case you care, the board isn't actually "freaking out"

That definitely fits. Looks like I'm going to have to be more careful.

Fortunately, if anything gets bludgeoned to death it will be a $20 microcontroller.