STM32CubeMX suggestion: be able to flag a driver to not be overwritten upon regeneration

[dhaselwood]

In some cases the USER sections are not sufficient to make some needed modifications to the HAL drivers. When modifying a configuration in STM32CubeMX, it would be useful to be able to flag drivers so that they are not overwritten when the code is generated.

Obviously, one can work around the current scheme by inserting code in the IRQ handler call, and include other routines with names that do not conflict with the HAL driver names, but that becomes a bit of a mess, especially when there is only minor change called for in the HAL driver.

[Tesla DeLorean]

Here we uniquely name the things we change in the HAL and keep local copies in the project directory

stm32h7xx_hal_sd_localized.c

It is a) obvious that a modified file is being used, b) it can be readily fixed again or ported into another project, c) falls within the scope of source management separate from the unmodified library code.

CubeMX often uses a "nuke it form orbit" approach because otherwise they'd get swallowed by support issues, from things like metastability and loops, where everytime you build you get something different.

[dhaselwood]

One solution not involving CubeMX would be to save the HAL routines that are user modified in a directory. When CubeMX is run and the project code regenerated, with a trivial script, copy the saved files back in, overwriting the the regenerated routines. Of course updates to the original HAL routines are lost, but when one is groveling in the details of the driver one is off on a different course with the driver anyway.

Having done bare-metal on the STM32 for about five years, I find CubeMX, (in order of value)--

1. Clock tree setup -- the gui tool is #1 on the usefulness scale.
2. Pin selection display--also a great advance. With the F4, the datasheet inclusion of the pin peripheral matrix figure was a step forward. The display makes it easy to find and select alternate pins to help with board layout.
3. Initialization code--setting up the peripheral registers in the proper sequence, etc. saves a lot of study and work.

The actual drivers are ok for most ordinary applications, and good for those new to the product. However, the big time and effort savings is the above three items. In my experience, getting the pins and peripheral registers setup and initialized was a major part of the effort of using these processors and the CubeMX effort is on the right path.