Support for RTC Backup registers

[steved]

I will look into it, I have some questions, I would make some adjustments, for example size_t instead of uint16_t and few other things like that.

I wondered about using size_t; felt it was best to have a defined size (since I'm sure I've come across size_t being a uint8_t, but that was a little while ago). No strong views.

About external devices, if the idea is to make an abstract non volatile storage driver then probably it should be decoupled from the RTC, ideally you could have NVM and not an RTC. Wouldn't it make sense to have a specific nvm driver, possibly with multiple instances if more devices are present.
Alternatively a "nvm" interface could be defined and let various drivers implement it, including the RTC. Streams and block devices already do that for characters streams and storage media.

I see the nvm driver being at a higher level than the RTC driver, with RTC memory being one possible device - as you say, in much the same manner as block devices. (I already have a similar style driver for FRAM via I2C). Device support can then include a driver for any on-board EEPROM or RAM, with 'library' drivers for external NVM. Essentially it would become a block-structured driver where the user code manages the storage layout - so it should be simpler than a file system.

I'm in two minds as to the merit of an nvm driver - in my own case, I have a couple of values which I wish to save frequently - this could wear out my FRAM, so I'll hard code use of the RTC memory for these. In this situation there's no great need for a uniform interface, nor for the additional code which goes with it. (Incidentally, even though its much faster to update than EEPROM, I write to my FRAM as a background task - another potential complication for some drivers). Overall I suggest that use of the NVM driver should be optional, with the user readily able to access individual memory blocks directly via their drivers where that is preferable.

[Giovanni]

After thinking a bit about it, I will add a persistent file interface to the HAL and add the interface to the RTC driver. There was a "file" interface in 2.6.x that I could reuse.

The interface will allow to have a NVM associated to the RTC but also to add storage capability to other drivers or make a standalone storage driver.

Your code should be easily integrable in this scenario.

Giovanni

[Giovanni]

Hi,

I implemented the file interface on the RTC driver, the methods are empty right now in rtc_lld.c and should be filled with your implementation if you want to give it a try, else I will do that during the weekend.

The advantage of this approach is that now we have a standard interface to access the data, you could also use chprintf() or any other stream function.

Giovanni

[steved]

Unlikely to have time to do anything on this until next week, but I did want to give some feedback having had a quick look at the changes.

Overall my opinion is that there should be a defined low-level interface to NVM (similar in concept to that which I coded), with the higher-level interface being optional. Each has its own uses.
Several reasons for wishing to retain the low-level interface, with particular reference to small storage areas such as the 20 bytes available in the 32F051:
1. Simplicity - the functionality of the file interface has little relevance with small devices
2. Resources - the file interface will inevitably consume RAM and code space (and my 32F051 project is already closer to device limits than I would like!)
3. Ease of coding - I can use the low-level driver to read or write a small buffer with a single function call. A similar operation using the file interface would take up to 4 function calls (open, seek, read/write, close).

I've been trying to see how the file interface would benefit my own use of NVM, and am not doing very well! I have a fairly narrow use of NVM as blocks of defined size which store configuration/setup information. Each block is protected with a CRC. I can see that the files interface could help with managing the larger blocks, although the CRC complicates this.

I can see some potential for using the streams interface to implement a rolling log, although this would need a mechanism to wrap round at the end of the assigned block.

No doubt others will have applications that would benefit from this new interface, especially in situations where a filesystem represents unnecessary complication and overhead. (And in future, maybe the file system could sit on top of the files interface).

[Giovanni]

The low level interface is possible in the low level driver, it could be also simply a set of macros and would be platform-specific (ie, not portable).

About the interface, it is meant to be an abstraction over a persistent file, there is no "open" and "close" is not necessary unless you want to implement some mechanism that prepares the nvm for a safe shutdown (for example generating a CRC on close).

Giovanni