smaillet-ms
commented
8 years ago Yes, these types of assumptions and rigidity in the design of the HAL/PAL are problematic as the underlying technologies change and adapt. Going forward the idea I want to get to is where the NETMF doesn't care one way or another how that is implemented. That is, NETMF should focus on the abstraction of the functionality (e.g. persistent settings data) rather than on prescribing the implementation details of HOW that is done. We can also consider whether we need such a configuration at all or a better alternative exists. (At some point the system will need to have some persistent data but does it need to exist in the HAL/PAL or can it be entirely in managed code? ) For v5 nothing should be considered sacred or absolute simply because that's how it's been done in the past.
Some of the recent CPU variants, namely STM32F74xx and STM32F75xx, have flash memory divided into sectors of relatively large size, starting at 32 KB (then 128 KB and 256 KB).
In the current implementation, the NETMF configuration data requires a dedicated flash memory sector (BlockUsage::CONFIG), but its actual size is much smaller (<< 4 KB), which results in wasting precious flash space. (The situation will most likely be even worse, due to the size of tinybooter which is roughly 30 - 50 KB, depending on transport and presence of crypto libs.)
I am not sure what would be the best way to solve this problem (move the config data to some other block, deploy it as an assembly ?...); I guess this is rather something to keep in mind for v5...