tinygo
tinygo copied to clipboard
tinygo-org
all: prototype of RAM persistence across reset
See issue #1716 which proposes adding persistence regions to TinyGo
- I do not think we should be mixing RAM and flash here.
Reading your thoughts, I think you're right.. There's enough different between them that trying to pretend they're the same will add a lot of complexity without much (if any) clear benefit.
- I don't really see the purpose of the special Region type? Why not return a byte slice from NewRAM?
I wasn't sure how that would interact with the GC. It would be a lot cleaner if that was the interface. I'll investigate.
- Why shouldn't libraries allocate persistent RAM?
There's an ordering constraint I'm not sure how to fix. I don't think the compiler / linker chain guarantees the order symbols are packed into sections - so on a rebuild the layout could vary. For RAM, this probably isn't a concern (good chance the RAM is wiped anyway on a re-flash) - but for Flash, would be good to make the ordering explicit, which is why I left it to the app to allocate the data to libraries. I'm hoping we can have it so that on a reasonable sub-set of devices, flashing a new app will leave the config intact.
This may be another good reason to separate RAM and Flash, since letting libraries allocate persistent RAM on the understanding it will not be guaranteed (or even likely) to be preserved across re-builds / re-flashing seems a good approach.
- How can an application detect whether the memory area has been initialized or not? Should it care?
I'm thinking magic values guarding the memory region, or some kind of CRC - would be use-case specific. If the guard values are wrong, or the CRC is invalid then assume uninitialized and do the initialization. STM32 does the same for RTC - it has a few bytes that are explicitly there for detecting if the RTC has been initialized - they document to set to a magic value of the developer's choosing after initializing the RTC.
- What about compatibility with the Go toolchain?
I really like the idea of using []byte and //go:persistent - feels a lot more elegant. I'll take a look at trying to do that.
Overall, I'm curious whether you have a use case in mind? You've mentioned a few examples where it could be useful, but few practical examples that currently apply to TinyGo. It really helps to know how it will be used to shape what the API looks like.
I've put a sketch of an prototypical app in the issue / proposal #1716, here (https://github.com/tinygo-org/tinygo/issues/1716#issuecomment-798997491)
Just wondering if this is actually now better addressed via the recent flash interface changes?
No, I don't think the flash API is appropriate for this. Flash is very different from RAM.
I do quite like the design here: https://github.com/tinygo-org/tinygo/issues/1716#issuecomment-799125817 I don't think the magic seed in that example is really necessary though: practically all MCUs provide a way to read the reset reason and therefore can know whether the reset was due to a power-on reset (RAM is gone) or a software reset (RAM is still available). We just need to make this available in the machine package.
@kenbell any plans to continue working on this? Perhaps start by rebasing on the dev branch.
Yeah - I'd kinda forgotten about this. I'll take a look in the next few days.