Rollover code for 8000 year timer?

[dknguyen]

Would you guys bother writing code that checks and handles rollovers in a timer that would take 8000 years to count out? It feels pointless to run a check every time the interrupt fires when it's never going to do anything but at the same time feels like bad practice to leave it out.

 

[Pommie]

I've not even seen rollover code for the millis() function in Arduino and that rolls over every 47 days.

It may seem sloppy (edit, in your case - not Arduino) but in reality it's not needed.

Mike.

 

[Ian Rogers]

I very much doubt anything you build will still be here in a 1000 years..

 

[large_ghostman]

LOL think Y2K and the forum chats (if it had been invented back then) do you think we should take the year 2000 into account? nah software will be long gone by then......

I would do it just because it will niggle you if you dont.

 

[dknguyen]

I've not even seen rollover code for the millis() function in Arduino and that rolls over every 47 days.

It may seem sloppy (edit, in your case - not Arduino) but in reality it's not needed.

Mike.

Well, this is industrial equipment that stays running for long periods of time....maybe not millennia though lol.

I very much doubt anything you build will still be here in a 1000 years..

32 bits makes it run out in just 1 minute but 64 bits makes it runs out in 8000 years and 1 minute was far too short.

 

[Pommie]

Rethinking this, whilst your project may not last more than 50 years, it may be that hardware/software will be simulated rather than replenish the hardware. So, it's possible it could run for millions of years. If it's important software then write the code. A little more coding may prevent a disaster in 8000 years. If it controls a microwave then don't bother.

Mike.

 

[dknguyen]

Rethinking this, whilst your project may not last more than 50 years, it may be that hardware/software will be simulated rather than replenish the hardware. So, it's possible it could run for millions of years. If it's important software then write the code. A little more coding may prevent a disaster in 8000 years. If it controls a microwave then don't bother.

Mike.

Good point. I was also worried about me copy and pasting the code into something else and changing the variable type to something shorter to suit the duration, forgetting that it was specifically coded to not handle rollover.

 

[large_ghostman]

Rethinking this, whilst your project may not last more than 50 years, it may be that hardware/software will be simulated rather than replenish the hardware. So, it's possible it could run for millions of years. If it's important software then write the code. A little more coding may prevent a disaster in 8000 years. If it controls a microwave then don't bother.

Mike.

Like me, I think you would have to do it Mike, it would just really bug you if you didnt do the job right. Imagine the next 15 years with the niggle at the back of your mind .

 

[Dan Soze]

Rethinking this, whilst your project may not last more than 50 years, it may be that hardware/software will be simulated rather than replenish the hardware. So, it's possible it could run for millions of years. If it's important software then write the code. A little more coding may prevent a disaster in 8000 years. If it controls a microwave then don't bother.

Mike.

Maybe you could use just a small interval of time and measure that interval with the highest possible resolution to find the maximum number of bits for a binary count before a rollover occurs.

For example: I would like to measure a 30 billion year interval in units of Planck time (approx. 5.29116 E44 per second) this would be a count of about 5.00928932448 E+62, or a number that can be represented in less than 210 bits.

As a Planck time is shortest theoretically observable interval, this results suggests that any device that uses more that 210 bits to measure a time interval may be just a tad over engineered.

To to Original Poster:
Now you that the maximum size for your counter the trick is to find the useful minimum size for your application.

 

[dknguyen]

To to Original Poster:
Now you that the maximum size for your counter the trick is to find the useful minimum size for your application.

Perhaps. But it seems kind of like wasted effort and operations because the whole reason I am doing this is because the hardware timer has no prescaler so any prescaler would have to be done in software which would just replace the current 64-bit additions with 32-bit accumulation operations with the end result being reduced resolution.

 

[BobW]

Good point. I was also worried about me copy and pasting the code into something else and changing the variable type to something shorter to suit the duration, forgetting that it was specifically coded to not handle rollover.

That's the reason for putting comments in your code.
Though, I'm happy to see that I'm not the only one who's obsessive about accounting for rollover conditions. During the Y2k debacle, I told people not to worry about my code until the year 99999, because I use a 5 digit year.

 

[dknguyen]

That's the reason for putting comments in your code.
Though, I'm happy to see that I'm not the only one who's obsessive about accounting for rollover conditions. During the Y2k debacle, I told people not to worry about my code until the year 99999, because I use a 5 digit year.

Even with comments I'm worried I might miss it. I would probably code the rollover in but then comment it out since it. I've done that before to remind me why I did not go with a different, seemingly more straightforward method