It looks like too STM32-specific for a generic driver. There are several assumptions: 1) Data are 32bits wide. 2) The number of backup registers. 3) There is backup space.
Placed in the low level implementation would be OK. The function name would be changed in rtcSTM32xxxx().
A more abstract approach would be implementing a memory stream on the backup RAM, but still it is something that could not be present.
It looks like too STM32-specific for a generic driver. There are several assumptions: 1) Data are 32bits wide. 2) The number of backup registers. 3) There is backup space.
Placed in the low level implementation would be OK. The function name would be changed in rtcSTM32xxxx().
A more abstract approach would be implementing a memory stream on the backup RAM, but still it is something that could not be present.
Giovanni
I dont understand what you mean by too STM32-specific ?
The lld_rtc.c(in RTCv2 forlder under platform/stm32) is totally only for stm32, the rtc.c yes should be generic, but what is more generic than "rtcReadBackupData". Yes the data type being passed could be generic and be cast to the correct type further down in the low level driver, also the reg number could have a boundary check/assert around it. If other platforms dont support this functionality then surely this could be conditional for STM32F platform ?
If you dont think this is the right place to add the extra functionality of the rtc module that the STM32 has then please advise. What i want to do help develop these areas that are currently lacking the functionality.
If the data size and the size of the array is not known then there is no abstraction over the functionality, without proper abstraction there is no point in having a high level API.
What you could do: 1) Assume data is always unit8_t. 2) Export a macro RTC_BACKUP_DATA_SIZE from the low level, zero means that the functionality is not present (excluding the API). The array would go from zero to RTC_BACKUP_DATA_SIZE-1.
It looks good bu it still does not address the size of the data, 32 bits is an assumption valid on the STM32 but not necessarily on other devices. Even the STM32F1 has 16 bits backup data registers.
Giovanni wrote:It looks good bu it still does not address the size of the data, 32 bits is an assumption valid on the STM32 but not necessarily on other devices. Even the STM32F1 has 16 bits backup data registers.
Giovanni
So this is what we have.....
F0/L0/L1 Devices 5 x 32Bit (20 bytes)
F1 Devices 10 x 16Bit (20 bytes)
F2/F4 Devices 20 x 32Bit (80 bytes)
Why the F1's are 16bit is very bizzare to me......
I understand using uint8_t types would be better for supporting other 8/16/32bit MCUS, but fo me it would mean taking the 32bit data and serializing to 8bit sream, seems not very efficient to me.
Building on the preceding posts in this thread, I've given some thought to a more general-purpose interface to non-volatile memory; both to accommodate on-board EEPROM/battery backed RAM, and possibly to integrate any user-added NVM - such as an external EEPROM or FRAM.
With EEPROM in particular, it may be necessary for the driver to carry out any writes in the background - probably an application-specific arrangement.
For the low-level drivers, I suggest a general-purpose interface of the following form:
The despatch table entry would have pointers to read, write and initialisation routines for the specific type of non-volatile memory. It could also include ancillary functionality such as details of memory size, whether a generic access method can be used, and so on. This arrangement appeals to me, since a certain amount of the range checking and suchlike can be done before the specific driver is called. It also gives a single entry point, as well as the option of adding access to off-chip devices.
I think its inevitable that a generic set of NVM access routines works with bytes; drivers can aggregate these where appropriate (byte ordering shouldn't matter, as long as the read routine manages ordering in the same way as the write routine). I agree that this philosophy is inconvenient for the ST32F series, especially since if I've understood the manual correctly, the RTC registers have to be accessed 32-bits at a time. However I would imagine that accessing non-volatile memory is a relatively infrequent operation, so any inefficiencies should have negligible impact.
Does anyone have any thoughts on a preferred approach here?
Given the lack of comment on my previous post, I've gone ahead and done a byte-orientated interface to the RTC registers, much along the lines I proposed.
I've attached the updated drivers, together with a test project.
As Tabulous says, using a byte stream with 32-bit registers isn't very efficient, especially handling writes across longword boundaries.
I had not further comments, probably I should have specified that, my fault.
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.
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.
