Skip to content
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

WIP: introduce periph_sleepmem #11369

Closed
wants to merge 2 commits into from

Conversation

kaspar030
Copy link
Contributor

Contribution description

Some MCU's offer a couple of registers or memory that retain(s) state even in the deepest sleep mode (when e.g., RAM is not retained). This PR tries to come up with a generic API to make those usable, and an implementation for stm32's RTC backup registers.

While working fine on stm32f4, this is otherwise completely WIP and missing licenses, docs, test application, ...

Testing procedure

I'd say this is in planning phase, so please check if the API makes sense.

Issues/PRs references

Briefly discussed backup registers in #11258 (comment).

@kaspar030 kaspar030 added State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR Area: drivers Area: Device drivers labels Apr 10, 2019
@stale
Copy link

stale bot commented Oct 12, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Oct 12, 2019
@stale stale bot closed this Nov 12, 2019
@kaspar030
Copy link
Contributor Author

Still useful.
I'm thinking on renaming this to backupmem or something. Opinions?

@kaspar030 kaspar030 removed the State: stale State: The issue / PR has no activity for >185 days label Feb 13, 2020
@benpicco
Copy link
Contributor

Yea the sam0 RTC also has a bunch of registers that can be used for this very purpose.

Comment on lines +9 to +10
size_t sleepmem_put(void *src, size_t n);
size_t sleepmem_get(void *target, size_t n);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API is a bit strange though.

  • add an offset so we don't always have to write the whole memory at once
  • just return an error if the buffer won't fit, partial writes are not really useful

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* add an offset so we don't always have to write the whole memory at once

I didn't add an offset because I assumed that it might require extra logic if the sleep memory has to be written as a whole.

* just return an error if the buffer won't fit, partial writes are not really useful

totally, will fix

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed that it might require extra logic if the sleep memory has to be written as a whole.

Is that the case on STM32?
On sam0 you can just write individual registers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, stm32 can also write individual registers.

@benpicco
Copy link
Contributor

Another question would be if this API should also cover I2C RTCs like ds1307 (comes with 56 bytes of NVRAM)

@kaspar030
Copy link
Contributor Author

Another question would be if this API should also cover I2C RTCs like ds1307 (comes with 56 bytes of NVRAM)

I'd say, why not? At that point, a pointer based interface should be considered.

@fjmolinas
Copy link
Contributor

This seems useful..

#include "cpu.h"

#ifndef RTC_BKP_NUMBER
#define RTC_BKP_NUMBER (20u)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this true for all stm32?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, from a quick scan L4 has 32, L1 has UP TO 32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants