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
