"sys.uptime" diagnostic data

[sergeuz]

Problem

The system should report its uptime in seconds.

Solution

• Add HAL_Timer_Get_Seconds() function returning the number of seconds passed since the device was powered on or woken up from sleep.
• Add hal_timer_millis() function returning the number of milliseconds passed since the device was last reset as a 64-bit value.
• Add System.uptime() and System.millis() methods returning the system uptime in seconds and milliseconds respectively.
• Add sys.uptime diagnostic data source.

Steps to Test

Run wiring/no_fixture_long_running test.

Example App

#include "application.h"

SYSTEM_MODE(MANUAL)

namespace {

const Serial1LogHandler logHandler(115200, LOG_LEVEL_WARN, {
    { "app", LOG_LEVEL_ALL }
});

bool logDiagData(void* appender, const uint8_t* data, size_t size) {
    Log.write(LOG_LEVEL_INFO, (const char*)data, size);
    return true;
}

} // namespace

void setup() {
    delay(3000);
    uint16_t id = DIAG_ID_SYSTEM_UPTIME;
    system_format_diag_data(&id, 1, 0, logDiagData, nullptr, nullptr);
    Log.print("\r\n");
}

void loop() {
}

References

• Diagnostics service #1390
• [ch8155]

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[m-mcgowan]

Any reason to not use a 64-bit type and keep the precision to milliseconds?

[sergeuz]

I just decided not to use any types which are non-native for the target platforms. We also don't seem to have a good use case for such extended milliseconds counter.

[sergeuz]

Updated the milliseconds counter to use uint64_t.

[m-mcgowan]

I am unsure about moving the #define since it will change the actual exported function name. I realize the chances are small, but someone could be using the HAL_Timer_Get_Micro_Seconds function. What is the value gained to moving the #define - if it's minimal, I'd prefer not to change it unless there is a known gain.

[sergeuz]

hm, but these macros do the opposite: they define aliases for already exported functions, rather than define their exported names. I don't see a possibility to break anything with this change, but, for sure, it doesn't bring any value either :)

[m-mcgowan]

This is an open question - do we break compatibility of these low-level functions? My instinct is to say no and move the 64-bit version to GetSystem1MsTick64 or similar, but happy to hear arguments to the contrary.

[sergeuz]

👍