Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000474FirmwareSerial Commspublic2011-12-08 16:012012-04-05 00:24
ReporterFred 
Assigned ToFred 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.3.0Fixed in Version 
Summary0000474: Provide Up Time Through Various Mechanisms
DescriptionUp 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.
TagsNo tags attached.
FirmwareVersion
Issue TypeNew Feature
Risk of Breakagelow
Attached Files

- Relationships

-  Notes
User avatar (0001103)
Fred (administrator)
2012-01-07 13:29

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
Powered by Mantis Bugtracker