[Feature] Small user persistent data space

[GianCann]

There is a way to store very small data between session?
4 or 8 bytes, to save some values to reuse between a execution and another execution.
(For example, the speed value for a motor)

[dlech]

Although it is technically possible to implement something like this, it is not something we have on the roadmap right now.

[GianCann]

This is a use case...
Stop the motor at x% speed, and restart (after a shutdown) at the same speed:
https://youtu.be/7qaltulX_iU

[laurensvalk]

Here’s an alternative which will do what you want in another way:

Just capture the stop button and turn the light off. The hub will look off, and yet it isn’t so you can save as much as you like in memory.

With lights and motors off, the battery should last quite a while. And since your program is persistent, there isn’t much of a loss if the batteries do run out eventually.

So now the feature request is really reduced to saving a tiny bit more battery. You tell us where that should sit on the priority list 😄

[GianCann]

Hi @laurensvalk ,
I think having a few memory slots to save some bytes can be useful, but you developers are better aware of the priorities and difficulties of implementing new features.

For example, I would prefer to have the UARTDevice class first and the ability to communicate via Bluetooth without interrupting the process with the Input () as it is now.

In any case, as "end user", when I have an idea for a new feature, I tell to you this idea.

After this, are you that evaluate which priority (if any) assign to the idea 😄

[laurensvalk]

But what about the alternative solution suggested above? Is there anything that cannot be done that way?

[GianCann]

But what about the alternative solution suggested above?

It's a solution, of course.
I can turn off the led, but not the bluetooth radio.
In short, I however waste energy if I leave the hub idle for a long time.

[GianCann]

but not the bluetooth radio.

The ability to turn on/off the BLE radio could be another useful feature 😄

[laurensvalk]

So it is just about power saving then 😄 We’ll probably look at that at some point. There are special low power states that preserve RAM.

I’m teasing a little bit - the main take away is that sometimes a new feature might sound good but often there are existing alternatives that work nearly just as well if you look at the problem from a different angle.

[laurensvalk]

Another related use case: remember some states between consequtive runs of the same program. Such as:

• Whether you have already initialized the motors: [Feature] Make motor rotation sensor reset optional #389. This way, you could choose to initialize only on first run after boot.
• Some counter value (program runs, detected objects, moved objects)

Usage could look like this

from pybricks.tools import ram_data

ram_data(b"1234")

data = ram_data()
print(data) # prints 1234

Since this is mostly for advanced users, this could be done fairly minimally with a single function for both saving and reading as shown above. Data could be written to and read from a finite, static uint8_t buffer of say, 32 bytes so it gets preserved between runs.

Numeric data could be packed with ustruct.

[laurensvalk]

Among the users that have requested this over here, ~100 bytes seems to be enough, so we can start with 128 bytes on the Powered Up hubs.