|Anonymous | Login | Signup for a new account||2017-04-24 09:14 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000474||Firmware||Serial Comms||public||2011-12-08 16:01||2012-04-05 00:24|
|Target Version||0.3.0||Fixed in Version|
|Summary||0000474: Provide Up Time Through Various Mechanisms|
|Description||Up time in seconds sounds reasonable:|
((((2^16) / 60) / 60) / 24)
If we have an uptime counter in seconds, and it's 16 bit, then we have 18 hours of uptime before the roll over, easy to detect and handle. 24 bits is 194 days and hugely excessive. This same var could be used for longer term things like fuel pump turn on/off and similar. Care will need to be taken to ensure that roll overs don't do weird stuff.
Possibilities are poll for this number and maybe some other stats as a sort of stats/health package and/or include it in various datalogs. Personally I don't care about uptime when reviewing a datalog in most cases, so that feels wrong to do.
|Tags||No tags attached.|
|Issue Type||New Feature|
|Risk of Breakage||low|
Thinking again, 18 hours feels a bit short.
(2^32) milliseconds = 49.7102696 days
Perhaps that is a winner? At least in the code it's a single line in RTI to update it, though that will reduce to a bit of asm to do the 32 bit operation. Not a big deal.
Resolution is good at 1ms and 50 days should cover anything imaginable.
|Copyright © 2000 - 2011 MantisBT Group|