Why is the driver code for different lines (F2, F4, F7, etc) duplicated by ST

[bst]

If you compare the code from e.g. the STM32CubeF2 and STM32CubeF4 archives you'll see that its almost identical. The only differences seem to be the name of the files and defines (have F2 or F4 in them) and the F4 code containing some additional functions compared to the F2 code.

We work a lot with STM32 microcontrollers at my company, even using multple chips within a single project. We're trying to maintain a single reusable codebase for infrastructure, utilities, etc. Obviously this codebase also contains the STM32Cube code so we can readily start a new project if needed.

The fact that each line within the STM32 family has it's own driver code makes it a difficult job to write (correct) generic code which we can reuse for different types of microcontrollers. This has nothing to do with real differences between those controllers, it's just that headerfiles have different names or defines need to be set differently.

[waclawek.jan]

> The fact that each line within the STM32 family has it's own driver code makes it a difficult job to write (correct)

> generic code which we can reuse for different types of microcontrollers.

Why would that be so? The primary purpose of Cube/HAL is being HW-independent. As long as you stay behind the Cube/HAL's API, you shouldn't care what's behind the API, i.e. you shouldn't care about the differences in the drivers.

JW

[Tesla DeLorean]

ST's trying to get this as unified as possible, but it is a big job and one they are doing iteratively, and which evolves. Something that's at least 10x more complicated than you're complaining about.

The naming on different families has evolved as the the register sets have expanded, and bits have been added. ie SDMMC doubles up and becomes SDMMC1 and SDMMC2, etc. The libraries tend to track the Reference Manual naming. Could this have been done with more rigor and foresight, perhaps, but some of this is baked in the cake now.

I'm wrangling demo code across perhaps 6-7 families of STM32 parts, and a much larger selection of boards within each group, and frankly the amount of similarity makes well abstracted code a breeze to merge back and forth. I've had to adapt a couple of the ways I've done the abstraction, and implement my own light-weight routines where HAL creates unnecessary complexity, but nothing I'm going to raise objections over. I'm not a purist and I'm going to cherry pick the stuff that works, and discard what doesn't.

My complaints are really around how rigorously things are tested and vetted, and then the real-world application of the library where forced usage within the company would challenge the HAL API guys to have a better practical understanding of their priorities, and what customers actually need.