You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The notion of flash page and page size requested by the SMTC api is not really good for having a correct abstraction. THis is really related to a technology of flash and should not be concidered by the LBM stack. It up to the MCU to manage the flash and pages as it needs to manage it.
As an example, STM32WL implementation uses a virtual eeprom system and the underlaying flash paging system is abstracted. The LBM should only request a linear storage zone, up to the mcu interface to deal with the paging when required.
The text was updated successfully, but these errors were encountered:
Hi,
It is used only for store & forward feature (flash page & page size).
The store & forward algorithm is based on this memory structure.
In your implementation, do you need store & forward ?
We also provide an example with an eeprom (STM32L0 example) but without store & forward.
Many thanks,
Best regards
I understand your ploint and it's not blocking for me, but my point is still : a library should not care about the final storage technology ; it's a constraint at the end.
The notion of flash page and page size requested by the SMTC api is not really good for having a correct abstraction. THis is really related to a technology of flash and should not be concidered by the LBM stack. It up to the MCU to manage the flash and pages as it needs to manage it.
As an example, STM32WL implementation uses a virtual eeprom system and the underlaying flash paging system is abstracted. The LBM should only request a linear storage zone, up to the mcu interface to deal with the paging when required.
The text was updated successfully, but these errors were encountered: