Why does get_rtc_time_us() truncate the result to uint32_t?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Maybe wakeup, read old cal value, do new cal, set rtc counter to
rtc_counter = ((rtc_counter_before_sleep * old_cal) + (sleep_count * (old_cal +new_cal)/2)) / new_cal
??
If we are worried about drift shouldn't we recal more often (not just at boot) and continue to rebase rtc_counter on latest cal value?
rtc_counter = ((rtc_counter_before_sleep * old_cal) + (sleep_count * (old_cal +new_cal)/2)) / new_cal
??
If we are worried about drift shouldn't we recal more often (not just at boot) and continue to rebase rtc_counter on latest cal value?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
I was thinking along the similar lines, the only remaining question is how to do this without introducing RTC_DATA variables. Currently if the application doesn't use RTC_DATA, we can power it down.
Another option is to store these values in RTC_FAST_MEM, if it is kept enabled.
Probably will go for "rebasing" of the counter value after wakeup, assuming that calibration value was constant in deep sleep, and storing the calibration value in one of the remaining RTC__CNTL_STORE registers.
Another option is to store these values in RTC_FAST_MEM, if it is kept enabled.
Probably will go for "rebasing" of the counter value after wakeup, assuming that calibration value was constant in deep sleep, and storing the calibration value in one of the remaining RTC__CNTL_STORE registers.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Sounds good. So is it more accurate to take the constant new cal value on wake rather than some average since the die temp is going to be the major factor and is more representative of the die temp during deepsleep (assuming no large changes in ambient)? Should we do periodic cal as the die temp changes during runtime since temp at boot is not representative of temp at steady state full power?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Re. doing calibration at runtime — this can be exposed as a API to applications, so that they can do it once in a while if needed. Or just use 32k xtal if time precision matters.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Got it. Will it be possible to call from a wake stub?
Now if we are using FRC1 for timekeeping during runtime we probably don't need to be doing calibrations but should we sync RTC counter to FRC1 before deepsleep?
Now if we are using FRC1 for timekeeping during runtime we probably don't need to be doing calibrations but should we sync RTC counter to FRC1 before deepsleep?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
RTC seems to gain 0.8-1.1sec/min on FRC1 in normal runtime mode.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Calibration might still be messed up? Okay, will debug that as well.
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Also s_microseconds rolls over at 32-bit.
Code: Select all
RTC Time: 4330469173
FRC1 Time: 4260909211
RTC Time: 4391418173
FRC1 Time: 25941852
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
I'm not getting the 1sec/min difference here, but will try a bunch of other boards, might be chip dependent?
Re: Why does get_rtc_time_us() truncate the result to uint32_t?
Can't reproduce this here, can you hint at how you got these results?WiFive wrote:Also s_microseconds rolls over at 32-bit.
Attached are graphs of RTC/FRC timers offset w.r.t. the timer on a PC.
RTC time was obtained from system_get_rtc_time, FRC time — from get_time_since_boot
Who is online
Users browsing this forum: Google [Bot] and 82 guests