ChibiOS Free Embedded RTOS

Regarding subsecond precision for STM32 RTCv1, I am thinking of taking a crack at adding such support through a compile-time constant defining the RTC clock speed/precscaler.

The following comment from os/hal/platforms/STM32/RTCv1/rtc_lld.c is incorrect:


There is a possibility to change it if the prescaler is less than 32767. If we allow the user to define a different prescaler for the application, then subsecond precision is available. It is then a fairly straightforward matter to make the conversion from tv_sec/tv_msec to and from the CNTH:CNTL register format (RTC clock ticks). The default functionality would be unchanged, but if the user defines the prescaler to less than 32767, then the time conversion to/from CNT register would be altered, giving subsecond precision.

I am willing to work on this if it sounds reasonable, Giovanni.

colin, It looks like dirty hack. It will change period of "seconds" interrupt. Probably broke something else.
When I wrote

I mean that there is no straight forward way to change prescaler counter like in F4 family.
I think about using of systick timer to implement soft reading subseconds on devices without hard subseconds. Probably this way can be used to set/keep time with subsecond accuracy.

For power saving purpose you can use following procedure:
1) wake from deepsleep with second accuracy
2) after waking up switch to crystal (4MHz) clock without using of PLL
3) do not enable and do not clocks any peripheral
4) enable WFI hook in idle thread
5) call shThdSleepMilliseonds(N);
6) fire up PLL if needed, perform task and go to deep sleep
For a moment ChibiOS has no powersaving subsystem. Do you want to work in this direction as ChibiOS developer?

barthess,

I don't see a less-than-one-Hz RTC clock it as a “dirty” way to go. You reduce the prescaler to increase the granularity. OK, so the “seconds” interrupt would no longer represent seconds... but I may not care about seconds interrupt, only alarm interrupt. The seconds interrupt is redundant if you can set the alarm for the next wakeup time or event time (alarm interrupt is more general).

Your suggestion about using the seconds-granularity RTC wakeup with a subseconds “remainder” idling using a non-deep-sleep mode with a reduced system clock is an interesting alternate idea. Couldn't you optimize more by using 500 kHz HSI (instead of 4 MHz HSE crystal)? Is it troublesome to change MCU system clock on-the-fly due to compile-time constants for clock rates? (I suppose it's OK if all drivers/interrupts are disabled while the system clock is running at an “abnormal” rate?)

However, I still think that changing the RTC prescaler is a simpler way to go and will ultimately result in much better power savings for applications with frequent, short wakeups (e.g., a wireless node that wakes up to communicate for about 5 ms every 2500 ms).

I am interested in helping ChibiOS if possible, but I am new to ChibiOS and have only a little experience with the STM32 so far. Has there been any suggestion of what direction ChibiOS should go in terms of providing better support for low-power applications (i.e., those that spend the majority of the time in some reduced-power sleep mode)? Also, my time is very limited in both work and personal spaces, but I am also very anxious to apply STM32 and ChibiOS to our low-power products that run off small batteries for weeks, months, or years. So I will do what I can.

Sorry if the talk about low-power operation is getting a little off-topic for The RTC driver topic, but obviously they are tightly related. Is it worth starting a thread dedicated to discussing low-power features of ChibiOS? --> I put my first question about WFI and the ChibiOS/RT Idle Thread in a new forum thread, The Low Power Topic (Sleep Mode).

Maybe it's worth doing a PWR driver or something like that. After all, most microcontrollers these days, including most of ChibiOS's supported ones, have low-power features.

But that's a topic for another thread.

barthess wrote:Giovanni, where is the place for such library in ChibiOS?

I think it could go in ./os/various but I am thinking to create a directory ./os/lib for this kind of modules, chprintf, evtimer and memstream could go there too. I would collect all the useful and common code that does not belong to kernel nor HAL.

Giovanni

colin wrote:OK Giovanni, that seems reasonable.

Where is this ongoing work on the RTC driver being done? Is it in trunk?

What RTC improvements will make it into 2.4.x stable releases?

It is in the trunk but I think barthess will branch again.

About backporting to 2.4.x, as long the changes do not have impact on other things (restricted to RTC implementations, no other modules changed) it can be backported if there is demand.

Giovanni

Giovanni wrote:I think it could go in ./os/various

Ok. I will create rtc_lib there and move code unrelated to hardware. I plan to do that in terms of sdc_dev branch.

Giovanni,
Currently I am writing code in chrtclib. Hm... it becomes ugly. I am reinventing the HAL.
Functions like RtcGetFatTime() must be there, but functions converting "raw" RTC to unix (or calendar) time must be provided by ChibiOS HAL. Without this feature the RTC HAL layer is close to pointless. Without it I can not perform painless migration from F1x to L1x (or external RTC ic) and vice versa. I would prefer to move this functions inside HAL.