Upgrade of RTC api.

Michał Kruszewski <mkru@...>

I wanted to implement rtc driver for nrf chips and I think that rtc.h api is too loosely defined.
Chips from IC vendors are very  different in terms of RTC peripheral, for example:
a) different number of RTC instances
b) different number of compare/alarm registers
c) some can generate additional events like TICK for tick-less RTOS
d) some have registers for current time and format of that time can also differ
e) different size of COUNTER register (that's actually not a big issue cause you can   always implement 32 bit counter in software).

I would like to implement more advanced rtc api and I would like you to help me define how it should look like. For example:
1. How many alarms can be set on single RTC, should it be configured via Kconfig (even with single alarm register it is possible to implement it in software) or the number of alarms should equal to number of available compare registers?
2. Should we keep track of current time inside rtc driver or should there be some higher module that would only use rtc driver, if yes then what format of time should we use, should it be configurable?
3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
4. What about some extra events like TICK, OVERFLOW?
5. Should there be only one callback function? rtc_api_set_alarm could then return descriptor to alarm and inside callback function we could check what exact alarm was triggered. Or maybe we should pass pointer to callback function  as an argument to rtc_api_set_alarm function?

I want to implement that api and some drivers but I need more details from people who have impact on how the project looks like, people who can make decisions.

Michał Kruszewski

Sent with ProtonMail Secure Email.

Join devel@lists.zephyrproject.org to automatically receive all group messages.