Adding Support for RTC to RP2350 with Millisecond Precision

[engigeer]

I have an application which would benefit from timestamps on the realtime reports so I would like to extend the RTC support to include the RP2350. I have a test implementation working using the "pico/aon_timer.h" library and modifying the get / set functions as follows:

static bool set_rtc_time (struct tm *time)
{
    bool ok;
    struct timespec ts = { .tv_sec = pico_mktime(time), .tv_nsec = 0 };

    if(hal.driver_cap.rtc_set) {
        aon_timer_set_time(&ts);
        ok = true;
    } else
        ok = aon_timer_start(&ts);

    return (hal.driver_cap.rtc_set = ok);
}

static bool get_rtc_time (struct tm *time)
{
    bool ok;

    if(hal.driver_cap.rtc_set){
        struct timespec ts;

        aon_timer_get_time(&ts);
        pico_localtime_r(&ts.tv_sec, time);
        // rtc_millis = ts.tv_nsec / 1000000;
        ok = true;
    }
    return ok;
}

I wanted to get some input on using the non-calendar timer functions, which would result in some double conversion on RP2040, but opens up the possibility of including millisecond precision in the timestamp. I think only a small core change would be necessary to make this millisecond timestamp accessible to plugin code.

These changes could also be guarded to leave the existing RP2040 implementation intact, although from what I can tell the aon_timer functions are intended to be universal - with the caveat that the non-calendar versions are internally converting from calendar date/time on RP2040. This makes the additional conversion back to date/time for compatibility with the core somewhat inefficient and its not entirely clear to me if the sub-second precision is retained.

[terjeio]

I'll add an optional hal.rtc.get_time function pointer in the next build, it takes a pointer to a struct timeval as its argument.
BTW you already have hal.get_micros (microseconds since startup) and hal.get_elapsed_ticks (milliseconds since startup) available that can be used for relative timestamping.

[engigeer]

I'll add an optional hal.rtc.get_time function pointer in the next build, it takes a pointer to a struct timeval as its argument. BTW you already have hal.get_micros (microseconds since startup) and hal.get_elapsed_ticks (milliseconds since startup) available that can be used for relative timestamping.

Sounds great. And yes, I did some testing with get_micros, but it proved non-trivial to obtain the offset relative to the rtc timestamp in order to sync the seconds roll-over.

[terjeio]

Added for the RP2040 driver in the latest commit - untested.

[engigeer]

Tested and all seems to be working, thank-you very much for the help!