The RTC driver topic

[Giovanni]

Release is done, open a ticket about this, it will go in 3.0.1.

Giovanni

[AdShea]

I'm trying to get an SNTP client (and PTP eventually) working, the HAL works great for getting and setting time, but frequency calibration is missing. I propose a pair of functions which handle adjusting trim values:

Code: Select all

int32_t rtcGetTrim(RTCDriver *rtcp);
int32_t rtcSetTrim(RTCDriver *rtcp, int32_t ppb);


The return values are the current RTC actual trim in ppb and the rtcSetTrim call does the limiting and conversion to hardware trim internally so that the interface can be platform agnostic. This functionality is important for getting good RTC performance over any real length of time.

I've been using this for the STM32F4 where the range is clamped to -487,100ppb and +488,500ppb and the hardware step size is 954ppb. The conversion from ppb to hw is (ppb*4502062)>>32 (this is one SMMUL instruction) followed by masking to 0x1FF and some bit twiddling to handle the CALP bit. Converting back is just bit-twiddling the CALP bit back in and multiplying by 954.

Currently they're not in the ChibiOS coding style and access registers directly, but I can split them into a top-level and an lld and reformat things if there's interest.

[Giovanni]

Hi,

Please go ahead. I am not sure it will make the next release however.

Giovanni

[steved]

Not sure whether 'ppb' is the most appropriate unit to use; might be better to deal with smaller integers which fairly directly translate to the actual values written to the calibration register.

Regardless of the final definition, the ppb multiplier (i.e. adjustment granularity) needs to be available, and could be implemented as a platform-specific macro. (IIRC there's at least one RTC where the multiplier is different for positive and negative corrections, which is a complication; so a parameter might need to be supported).

I think its implicit in your definitions, but please make sure that the sense of the trim values is defined to be consistent across device familes - so increasing the value is guaranteed to make the clock run faster, regardless of the clock chip, for example.

And IMO an attempt to set a trim value which is out of range should set the nearest value which is within range, rather than give an error.

I'm looking at how my own use case would map to the interface here; my clock trimming mostly starts as commands to 'run faster' or 'run slower', which translate into increments/decrements of the physical register trim values

[Giovanni]

I agree with above points, in addition, we need to define the behavior if the feature is not available:

1) Driver implementations should silently do nothing.
2) An RTC_SUPPORTS_TRIM macro should be exported (TRUE/FALSE), the API is only exported if the low level driver reports TRUE.

Giovanni

[AdShea]

Currently, my implementation changes ppb into the internal representation, where + is faster and - is slower then returns the actual value set including scaling and clamping so filters can take system accuracy into account. This never returns an error and allows you to use the same time-management filter constants across different RTCs. I chose ppb as the unit because I didn't find any RTC that trims more finely than that and it allows for an integer parameter that is platform agnostic. This also allows the driver to wrap non-linear mechanisms where larger trims are less accurate (the STM32F4 can actually trim several percent through the trim register though the resolution is lower at higher trim values).

If the platform doesn't support trim, both of these return zero for any arguments.

I'll definitely add an RTC_SUPPORTS_TRIM flag.

[caheo]

Hi all, i'm a newbie to ChibiOS and thanks @Giovanni for releasing ChibiOS to the world

I'm not sure it's a bug or not but RTC wakeup from Power-Down Deep-Sleep mode on my STM32F103C8T6 only works if STM32_RTCSEL is set to STM32_RTCSEL_LSI (LSE is broken so I haven't gotten a chance to test out but I assume it will work). I tried to enable both HSE and LSI and set STM32_RTCSEL_HSEDIV and connect VBAT to 3.3V but it didn't work. Any idea why it happens?

One more question, from my understanding, VBAT needs to be supplied with 1.8-3.6V in order to make RTC, external LSE and backup registers functioning properly. But it doesn't required for LSI? Is that correct?

[Giovanni]

hi,

It is probably because HSE is shut down, about LSI, I don't know if VBAT is required, it is possible if it is part of the backup domain.

Giovanni

[caheo]

hi,

It is probably because HSE is shut down, about LSI, I don't know if VBAT is required, it is possible if it is part of the backup domain.

Giovanni

I'll try with LSE tomorrow and will update here so others may aware of.