-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers/periph: define rtc_mem and implement it for sam0_common #16758
Conversation
eb05241
to
f1b57cf
Compare
PR looks fine! So you decided making the API suitable for external nvrams is not a good idea? bikeshedding: maybe "rtc" in the name is limiting, as in, this feature might not be implemented by RTC hardware? |
Well we have this with all APIs that are usually implemented on the MCU, but could also be provided via software emulation or external hardware. We would need a higher level API that sits on top of the periph API / external driver API or switch to a pointer based API interface. But this is beyond the scope of this PR.
Maybe, but what's a better name? RTC memory has some characteristics that are different from other types of memory.
What other implementations are you thinking of? |
@benpicco are you aware of other hardware with this kind of feature or only |
I've tested with a SAMR34 chip, which consists of a SAML21 CPU (rev B) plus a SX1276 radio. I can read and write all 4 registers without problems.
Your RTC test passes and prints "RTC mem OK" on saml21 (well, samr34 as said above). Iv'e tried compiling one of my firmwares (that makes use of ztimer module) against this PR. Without adding module periph_rtc_mem I get the following error:
This API indeed solves my problem. A small note: you're intercepting rtt_init(), but the RTC memory is cleared also by calling rtc_init(). To keep things more readable, I'd rather save/restore the bytes in _ rtt_reset(), so you get all the possible paths at once. What do you think? Another little glitch: in rtc_mem_read and rtc_mem_write the asserts should really be
in order to fully use the available memory. |
I expanded the test so now the whole RTC memory is read & written - before I only write the first two words.
Nah that was my fault as well - the driver should still work without
The
Thank you, fixed! |
I can confirm that on SAMR34 your code works (it would on SAML21 too, then). |
This one should provide a more general solution to the problem that #16757 was set to solve |
84633dd
to
c40b1c4
Compare
As always, SAML1X complain.
|
SAME54-XPRO also complains. |
Ah SAM L1x has the same RTC peripheral as SAM D5x (GP and Alarm registers are shared), but there is no second set of GP/Alarm registers. The RTC only supports a single alarm. Since we use that alarm already, we can't use the GP register to store data. |
Mine says it's fine
|
On my side, SAME54-XPRO returns:
|
Just unplug/replug and seems to work now... |
Why did you disable support for SAML1X in latest commit ? |
It can't be used together with RTC / RTT alarms as there is only a single set of GP/Alarm registers |
Please squash ! |
3dba105
to
8e5cd31
Compare
#ifdef __cplusplus | ||
extern "C" { | ||
#endif | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to tie this to rtc
? For stm32
this could be used regardless of the rtc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If STM32 have persistent GP registers across reset we can extend and move this interface somewhere later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK.
Tested work on SAME54 and SAML21.
Now that SAML1X is out, let's merge this.
drivers/include/periph/rtc_mem.h
Outdated
/** | ||
* @brief Write to RTC memory | ||
* | ||
* @param[in] offset Offset to the start of RTC memory in bytes | ||
* @param[in] data Source buffer | ||
* @param[in] len Amount of bytes to write | ||
*/ | ||
void rtc_mem_write(unsigned offset, const void *data, size_t len); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make the behaviour explicit when attempts to write out of bounds? Will it write what it can or fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a @note
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments on the api, see above
See #16803 for why I removed the CI: ready for build label. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, changes addressed
842732f
to
c8d94e8
Compare
Contribution description
The RTC often provides some memory that can be used to store data across reset / deep sleep.
Expose this memory with a proper API.
On SAM D5x/E5x general purpose registers are shared with the alarm registers.
Since the RTC/RTT interface only exposes a single alarm, we can only use the second pair of General Purpose Registers.
The data sheet for SAM L1x and SAM L2x do not mention such limitations, but according to the data sheet SAM L21 only has 2 General Purpose registers whereas the vendor files have definitions for 4. I didn't yet test if they do indeed all work.
Testing procedure
So far this only has been tested on
same54-xpro
. Bothtests/periph_rtc
andtests/periph_rtt
have been adapted to make use of the feature and to ensure it does not interfere with normal RTC/RTT alarms.saml1xsingle set of shared Alarm / GP registersIssues/PRs references
alternative to #16757 - @ant9000 does this work for your use-case?
previously proposed in #11369