Improvement for the definitions of factory calibration values

[Piranha]

Inspired from a beginner issues in this topic, I noticed a possible improvements. Let's take an example from a stm32f767xx.h definition file:

#define VREFINT_CAL_ADDR_CMSIS                   ((uint16_t*) (0x1FF0F44A))

The first improvement is to add a const qualifier for the referenced memory and remove the useless parentheses for the address:

#define VREFINT_CAL_ADDR                   ((const uint16_t*) 0x1FF0F44A)

The second is to make the macro access and actual data:

#define VREFINT_CAL                   ( *((const uint16_t*) 0x1FF0F44A) )

This way developers can just use it as a normal variable in their calculations, which is the typical usage of those values. And those, who do actually need the address for some purpose, can still take it with an & (address of) operator.

Also it is clear what the "_ADDR" part of the name means, but the "_CMSIS" part is nonsense. If it is used for making the names more unique in the namespace, then it would be better to add some "ADCCAL_" or something like that at the beginning of all those calibration data definitions so that it makes some sense.

[waclawek.jan]

Whatever the format, just keep it consistent throughout all STM32 device headers.

Also, while from usage point of view these constants may appear to be ADC-related, the CMSIS-mandated device header is more "location" oriented than "usage" oriented, and rightly so. These constants are in the System memory. And there are other noteworthy constants in the system memory, like the UniqueID, FLASH size, package, OTP area and the Option bytes. Maybe I've forgotten some.

So my suggestion would be to put them to a struct similar to other items in the header, so that then we could write things like SYSMEM->VREFINT_CAL.

JW

[Piranha]

Took a look on those other values and it looks like consistence is also not ST's thing...

#define UID_BASE              0x1FF0F420UL

But the addresses are close enough to pack them in a single structure the same way like it's done for peripheral registers. Therefore that is indeed an even better approach.

Anyway, one thing is for sure in all scenarios - the referred memory must be qualified as const.