Notifications
Clear all
C++
35
Posts
2
Users
1
Likes
6,472
Views
Topic starter
2020-02-21 4:11 pm
Stopwatch?
Maybe, but I don't think so! That is something for a sketch.
But it reminded me of experiments during physics classes, with a ball bearing suspended under an electromagnet, a couple of feet above a trap door, to prove Newton was right. And that was before SI units had been officially introduced into schools in the UK. That came in 1968!
And I just put a LiPo in a charger backwards! Apart from the smoke, I discovered it had completely desoldered an SMD. ? ?
2020-02-21 4:40 pm
Stopwatch?
Maybe, but I don't think so! That is something for a sketch.
I'll show you an interesting stopwatch... I'll have to dig it out from one of my archives.
What goes up, must come down 😀
Topic starter
2020-02-21 4:44 pm
I have put the old code back (timestamp comparison) in the .cpp file and have just started running the microseconds until rollover, to see if it does make any difference, I'll let you know tomorrow
Topic starter
2020-02-22 8:14 am
You were right, the rollover problem did not occur when comparing timestamps. Nevertheless, I was surprised to find that "long unsigned" integers rollover too.
When I ran this code I was expecting a runtime error:
void setup() { // starts the serial monitor interface and shows sketch details Serial.begin(9600); } void loop() { // put your main code here, to run repeatedly: unsigned long myInt = 4294964295; unsigned long myInt1 = 10000; unsigned long result = myInt + myInt1; Serial.println(result); while(1); }
But the result variable returned 6999.
2020-02-22 8:30 am
You were right, the rollover problem did not occur when comparing timestamps. Nevertheless, I was surprised to find that "long unsigned" integers rollover too.
Yeah, I thought it should be ok, as we're only comparing the difference between counts... not actual timestamps. Either way, I prefer the last version anyway, as I think it's cleaner code.
As for overflow... it is of course an error when the size of the type cannot support a greater number, but should it matter if it was signed or unsigned?
Topic starter
2020-02-22 8:31 am
And when I added another zero to the variable "myInt" the code was still compiled, but "result" returned 4294947286!
Topic starter
2020-02-22 8:37 am
I did see a discussion about using <uint_64> and incrementing the higher 32 bits at each rollover. This would, with millis(), then rollover at about every half a billion years!
But I don't intend to test that theory ? ? ?
2020-02-22 8:39 am
From memory, unsigned overflow is well defined in the C++ standard... but I don't recall the exact answer off the top of my head - I'll have to pull it out and see if I can find the relevant section!
Cheers!
Topic starter
2020-02-22 8:40 am
Topic starter
2020-02-22 8:52 am
The meaning of life!
Doesn't everything boil down to that?
But it does surprise me that the compiler doesn't tell me that the number 42949642950 is too big to handle!
2020-02-22 8:59 am
Yep! 🙂
Unfortunately, Arduino doesn't implement the full C++ standard library due to size limitations, therefore exceptions are left out, as well as a host of excellent container classes and features that we can only dream were available.
Topic starter
2020-02-22 10:22 am
What goes up, must come down
Have finally joined the dots! The Alan Parsons Project is the answer!
An Arduino Pyramid Monitoring Program. With uint_64 you could measure how many milliseconds it would take for a pyramid to turn back to dust. Now that's what I call a timer! ? ? ?