API access to rtc calibration registers

[hugglesfox]

Just wondering if there's interest in providing methods to control the RTC_CALR register in the RTC register block. If so any suggestions as to what that api should look like? My thoughts are something along the lines of

enum CalibrationPeriod {
    8_Seconds,
    16_Seconds,
    32_Seconds,
}

rtc.calibration_offset(ppm: f32);
rtc.calibration_period(period: CalibrationPeriod);

I'm happy to write the decided on implementation.

Thanks!

[jamwaffles]

If you need the feature I'd be happy to accept a PR :). How does the calibration period work though? Do you set a flag and it calibrates in the background for CalibrationPeriod seconds, or is it something the application has to wait for? Would it make sense for the API to be something like rtc.start_calibration(period: CalibrationPeriod);?

[hugglesfox]

Sorry I probably should've added some explanation. The way the calibration works (as I understand it from reading RM0367 section 27.4.12) is you specify the number of rtc clock cycles to be masked (ignored) in CALM, thus slowing down the RTC. Setting the CALP bit will add a clock pulse every 32 seconds and conversely speed up the RTC by a fixed amount. So by setting CALP then offsetting it with CALM you can set a specific speed up.

I'm still trying to wrap my head around the calibration period however the number of usable bits in CALM depends on the calibration period. Longer the calibration period, the more bits available in CALM and therefore the finer the control on how much the rtc is slowed down. By default the period is 32 seconds (matching the period of which pulses are added by CALP) but the CALW8 and CALW16 bits allow that to be changed to a period of 8 and 16 seconds respectively. I'm not sure exactly what the use case for changing the period is but the functionality is there.

So to answer your questions (finally :sweat_smile:)

• Calibration is something which is constantly occurring in the background. What you're doing is applying a constant offset to the RTC crystal frequency. Therefore the software doesn't need to wait for calibration to finish. However once the calibration register has been written to, it's blocked from further writes for a small amount of time (until the RECALPF bit in the rtc interrupt register returns to 0).
• rtc.start_calibration(period: CalibrationPeriod); does make some sense however I don't see the use case for changing the calibration period after it's been initially set. It possibly could be something which is set as apart of Rtc::new but I don't know if we want to further convolute it.

Hope this clears things up!