Hi, >> I didn't find >> anything in xpcc, so I would have to use some lower level functions I >> think, > > Yes, we have not implemented storing persistent data in flash yet. > However, we would be more than happy if you want to work on an implementation. > > As many different micro controllers support writing to flash, I would suggest > to separate the code into two layers: > 1.) a low level hardware abstraction layer (HAL), that encapsulates low level > access to the STM32 registers > 2.) a high level layer that uses the HAL to access the flash and implements > the required data organization and wear leveling techniques.
+1. Might also be worth to take a look at the STM32 HAL drivers in the CubeF1 libraries. They are quite convoluted (they’re written for a context switching OS, with semaphores and the whole shebang), but maybe you can reduce them to something useful with which you can write a cheap prototype, before deciding how to proceed. > > but what I don't know is how to allocate space for the data in >> the flash so it's on a separate page? > > This probably has to be done in the linkerscript. > I think Niklas can tell you best how to specify a separate flash section for > data. The way I see it, you have two choices for the physical arrangement of persistent memory: 1. Add another memory section to this linkerscript like so: https://gist.github.com/salkinium/10daa6eec7788aea1cae#file-stm32_ram-ld-L60-L69 The alignment buffer is important, because you might not want to write a flash page that code is currently executing from. If you have very, very simple data, all of the same type (could be a struct, but should be ATTRIBUTE_PACKED), then you can create _one_ large array that fits into this section. However, there are some _significant_ drawbacks with this solution: 1. __persistant_start can change at any time. Can be easily fixed by setting it to a fixed address though. 2. If you have multiple symbols in this section, their order is not guaranteed. 3. the .persistent section would be overwritten on every programming. Not that useful for persistency. In short: Don’t do it this way 2. The saner alternative would be to use a data structure that serialises objects for you with a specification and tested implementations. Might have higher setup costs than the naive solution above, but it will probably pay off later. In short: Have a look at http://cbor.io. Niklas _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
