Start a new topic

make the restspace of the internal memory for saving data?


I read some posts on saving data to the SD card. 

I understand this is not possible so here is my idea : 

why not make the rest space of the internal memory for saving data?

For example a device has 32Mb and if the project only uses 8Mb there is 24Mb space left.

So would it be possible to have that space or some of that space reserved for saving data?

And if possible would it be an interesting feature?

best regards 

Intriguing concept.

Would you care to elaborate how the end-user would make use of this?

Any considerations on what happens to that data on a power reboot?  when TFT Files are upgraded?

How would your data be retrieved from the device during Normal device operations?


update of TFT files means all data is lots. I think that it is a common idea that updating TFT files are rarely once a project is stable and in release mode.

So for me I would have no problem that data is lost on TFT file upgrade.

However if you would safe data on TFT update via SD it could be a possibility I think. But i don't know enough on the internal structure , so I am just thinking free...

before the SD card data it flashed into the device flash maybe it can do a save from the device to that SD card and after installing the new TFT file it could also restore the "internal memory" for example.

But this is a random idea ... so for me if data is lots on update like said previous, i would not mind.

Commands that would be needed is something like this

wimd data.val,8000000  --> Write Internal Memory Data : Value, start add of this value

rimd 8000000 --> Read Internal Memory  Data : start add if the value to read.

it would be basically the same as the repo and wepo  command

I too am just thinking about this free-style.

I would say that it would be nice to make use of the additional resources

- especially since they are there, and not being used.

One difficulty in saving to SPI flash is that an entire page of data (256 or 512 bytes) has to be saved at the same time.  The STM/GD MCU on the back of the Nextion would have to devote that space in SRAM (which we know is limited).

With the EEPROM on the Enhanced Models, it is possible to store as little as 2 bytes at a time (one char string) or 4 bytes in a 32-bit number value.  But the EEPROM was made for this purpose, it is limited to only 1K, but it doesn't require additional SRAM to hold chunks of values before committing.  It does require the design to know where every piece of stored data will reside and in what exact format.

There are other considerations in SPI flash that EEPROM doesn't need to be as concerned with and that is wear leveling of the Flash pages.  They have limits on how many writes can be made.  Continuous writing to the same location will wear that page out.  This would then require more firmware to avoid such wearing.  If you were to hold a 256 byte page in SRAM so you could commit an entire page at once, to help prevent as much wearing - you risk data loss should power be lost between writes.

For correctness the EEPROM also has limits, I just don't think wear is as great an issue.

To dump the data over to microSD would be interesting - but that also introduces another issue.

Those updating over serial are unable to insert the microSD card before updating.  Many projects also bury the Nextion screen inside some type of case - making the microSD slot inaccessible.  At present, it is also not possible to leave the microSD inserted - when the Nextion boots, if a card is detected, then it triggers an update and reboots - you don't get to the point where the HMI design actually runs.

There should be a means to make use of the existing resources, especially on a 32MB device.

It will require a bit more pondering on the how to make it happen so the feature is useful for all.

thank you for your detailed point of view

I see it is indeed not easy and sram is always limited :)

the blocks of 215byes would not be a big problem I think, it means that if you have 8Mb free space divided by blocks of 215byes it still would mean 31215 places to put data. Way more than the 1000 eeprom bytes which are actually max 512 bytes when using a char to save in eeprom data . 

about the write cycles, sram does have plenty write cycles and it would mean that the specs are just as the sram. can't expect no more  than what the manufacturer specs promise :)

anyway thanks for having a thinking about the topic and who knows in the future.... it maybe is possible

have a nice weekend.

Clarification - it is the SPI flash that has the write cycle restrictions, SRAM writes are nearly unlimited.

And I thank you for putting the request forward and having aa bit of discussion on it.  More discussions are a necessity to get good ideas like this one to come to a reality.

When developers sit back and wait for the ideas to come to them, there is little chance that their idea will match the users idea and actually be useful what someone else is hoping for.  When there is a discussion, some understandings between what is possible from a technical perspective (so ideas do not become way out to lunch) and what can be truly helpful to the user (so the user can create awesome projects).

I believe when understandings can come together, compromising what is possible with what is desired, and the how to make it work are discussed to understand what limits it may have -- then the feature has a chance of becoming a reality.

A feature request without the possible methods on how to make it happen is merely a wish.

I think your contribution to this discussion may make it easier for the developers to figure out the hows.

So here is hoping we gave them enough for them to further it for future versions.

I am now reviewing all of the Feature Requests, this will take some time, patience please.

The request has been carried forward

Login or Signup to post a comment