2024-05-17 04:38 AM - edited 2024-06-11 02:45 AM
Both X-CUBE-EEPROM and STSW-STM32117 (AN4061 - for STM32F0) use "Virtual Addresses" in the emulated storage:
But nowhere explains how these "Virtual Address" numbers are determined/decided.
It seems to me that (apart from 0x0000 and 0xFFFF being reserved)*, the choice is completely arbitrary - is that right?
The examples use "sparse" virtual address values - is there any advantage in doing that ?
Would there be any benefit in choosing values with maximum spacing - more "entropy" ?
EDIT:
* Both 0x0000 and 0xFFFF are reserved by X-CUBE-EEPROM;
Only 0xFFFF is reserved by AN4061 (presumably also by AN2594, AN3390, AN4056, and AN3969?)
Solved! Go to Solution.
2024-06-11 02:34 AM
Hi @Andrew Neil ,
Yes these 3 values are arbitrary chosen. You can give them the value you want (in the X-Cube example the value are 1/2/3, etc.).
The thing is that you can give the value you want, it can be useful if you want to give a value that means something in your application, but right there, that's totally arbitrary.
I hope this helps,
Best Regards,
Florian LR
2024-05-17 05:04 AM
As I understand it they are arbitrary, stored as metadata in a journal, and allowing for recovery of a subset of the entire virtual address space.
Personally I'd journal a configuration structure over doing it this way.
2024-05-17 09:06 AM
@Tesla DeLorean wrote:Personally I'd journal a configuration structure over doing it this way.
Hmmmm ... maybe you're right.
The 100% overhead, and only being able to access individual 16-bit "items" does seem cumbersome.
I have mostly 8-bit data, and a number of strings.
So maybe something more like this: https://www.silabs.com/documents/public/application-notes/AN568.pdf ?
2024-05-21 07:49 AM - edited 2024-05-21 07:51 AM
Andy,
Assuming you really need the wear leveling, I found AN568 and AN798 both worth looking at. In my opinion, some of these are better for structures (AN568) and some better for individual bytes (AN798).
https://www.silabs.com/documents/public/application-notes/AN798.pdf
GB
2024-05-21 07:52 AM
Yes, I saw them & got the same impression.
I also saw their UG103.7 - "Non-Volatile Data Storage Fundamentals" – for their Cortex-M parts. It seems rather more advanced (complicated!).
2024-05-21 07:54 AM
@STTwo-32 for the ST implementations, can you confirm that the values of the "Virtual Addresses" are, indeed, purely arbitrary?
2024-06-11 02:34 AM
Hi @Andrew Neil ,
Yes these 3 values are arbitrary chosen. You can give them the value you want (in the X-Cube example the value are 1/2/3, etc.).
The thing is that you can give the value you want, it can be useful if you want to give a value that means something in your application, but right there, that's totally arbitrary.
I hope this helps,
Best Regards,
Florian LR
2024-06-11 02:38 AM
Thanks for clarifying that.
Having now looked at it for a while, I find the term "Virtual Address" unhelpful - maybe even misleading.
I think something like "Tag" or "Key" would be more appropriate.
2024-06-11 02:43 AM
Yes it can indeed mislead, we'll think about an other way of presenting this for future release.
Thank you for this feedback !
Florian LR
2024-10-10 09:47 AM
@Florian LR wrote:Yes these 3 values are arbitrary chosen. You can give them the value you want (in the X-Cube example the value are 1/2/3, etc.).
This applies to the AN4061 code for STM32F0, STSW-STM32117, but It seems that X-CUBE-EEPROM is different:
"the virtual addresses MUST be 1 to NM_OF_VARIABLES and therefore contiguous) for the PagesTransfer function to work"