ChibiOS Free Embedded RTOS

Giovanni,
1) Looks, like we also need RTC_SUPPORT_CALLBACKS flag for F4x platform. It would be useful when user does not need callbacks from RTC but needs ability of waking up from low power modes on RTC events (event and interrupts are independent). Than he sets RTC_SUPPORT_CALLBACKS to FALSE and completely disable EXTI driver to save some memory. Callback functions (if needed) will be handled in EXTI driver only.
2) Is it really-really need to have ability of multiple RTC cells in single MCU??

Hi,

1)...

I thought that RTC_SUPPORT_CALLBACKS was a capability flag not a configuration option, the difference is that a configuration option is something the user can turn on or off while a capability flag is something the user can only read.

In this case an RTC either supports callbacks or does not support callbacks. The RTCv2 does not support callbacks because it does not have a dedicated interrupt handler.

In my opinion the user should configure the EXT driver independently from the RTC driver and the RTC driver should declare that it does not support callbacks.

2) Is it really-really need to have ability of multiple RTC cells in single MCU??

Not really but what would change? RTC instead of RTCD1? is it worth breaking a system-wide naming convention just to save a "D1" or I am missing your point?

Giovanni

1)

Giovanni wrote:In my opinion the user should configure the EXT driver independently from the RTC driver

Sure, but RTC may (or may not) generate interrupts regardless to events. So lets introduce configuration flag RTC_USE_INTERRUPTS and place it in halconf.h
2) It will save not only "D1" but "D1.id_rtc" and (probably like in I2C driver) some space in flash. Also, macros in RTCv1/rtc_lld.c uses "RTC" name.

I am not sure to understand your idea fully but OK, introduce that configuration option and let's talk about it when it is done.

About the RTC structure, it is not mandatory to have a pointer to the RTC hardware cell in the RTCDriver structure, this is an internal implementation detail.
Note that having the pointer in the driver structure can save flash because taking a pointer from the driver structure requires one single short instruction (2 bytes), obtaining a pointer to an absolute address requires 2 instructions (6 or 8 bytes depending on the method used).

Just to be clear:



Requires 6 or 8 bytes the first time it is met in a function (move+movet or move+address_word).



Requires 2 bytes because °rtcp" is already known, taking the pointer only requires one move.

So careful with flash usage estimations, it is not so obvious if you don't think at what the compiler would produce.

About point 2, it is mandatory however respect the system conventions about drivers, so the function signatures and the driver naming must be respected.

I was under a delusion. RM0090.pdf says:

Exiting Sleep mode
If the WFI instruction is used to enter Sleep mode, any peripheral interrupt acknowledged by
the nested vectored interrupt controller (NVIC) can wake up the device from Sleep mode.
If the WFE instruction is used to enter Sleep mode, the MCU exits Sleep mode as soon as
an event occurs. The wakeup event can be generated either by:
● Enabling an interrupt in the peripheral control register but not in the NVIC, and enabling
the SEVONPEND bit in the Cortexâ„¢-M4F System Control register. When the MCU
resumes from WFE, the peripheral interrupt pending bit and the peripheral NVIC IRQ
channel pending bit (in the NVIC interrupt clear pending register) have to be cleared.
● Or configuring an external or internal EXTI line in event mode. When the CPU resumes
from WFE, it is not necessary to clear the peripheral interrupt pending bit or the NVIC
IRQ channel pending bit as the pending bit corresponding to the event line is not set.

This mode offers the lowest wakeup time as no time is wasted in interrupt entry/exit.

But enabling of just events from RTC is not enough for waking up, RTC interrupts must be enabled too. So RTC_USE_INTERRUPTS flag is totally pointless.

Periodic wakeup tested and works, but device can not pull in sleep mode when use __WFE() insted of __WFI(), any ideas?

No idea, never used WFE before, try looking into the erratas, it is possible there is something there.

Giovanni

Later Joseph Yiu hints in this thread:
http://goo.gl/dIXCT
would be helpful, perhaps ?

Together with section "B1.5.18 Wait For Event and Send Event" from:
DDI0403D_arm_architecture_v7m_reference_manual_errata_markup_1_0.pdf

rev. 3964
Basic functionality mostly done and slightly tested.
Giovanni, could you review naming convention of F4x-specific functions in LL part?

We can make cosmetic/formatting adjustment after the merge, just merge when you are confident on functionality. It is just a LLD-only change, right?

Giovanni

Yes, changes in LL only