0

I have an old project which is built on using "StdPeriph drivers" for STM32F103 MCU and Keil environment. It uses various drivers for gpio, adc, can, dac, dma, i2c, spi, tim, uart etc.

As these drivers are obsolete now so I want to move to new available ones. But I don't know how much work will be involved in migrating to new drivers let us say CubeMX.

I have heard that CubeMX are not as efficient as was expected of them. Since my application is not very time critical so i think i can live with it so long as my new project-code would be maintainable and scale-able.

I want my project to be easily maintainable and scale-able so that's why I am considering to upgrade to these newly available libraries as well as TrueStudio. But I don't know how much bigger the task will be time-wise and difficulty-level-wise. I have to hire some engineer for this task. How can I quantify this task?

Lundin
  • 17,577
  • 1
  • 24
  • 67
alt-rose
  • 1,441
  • 14
  • 29

2 Answers2

4

If it ain't broke, don't fix it.

The StdPeriph drivers work very well on existing STM32 MCUs, and these are going stay around for a while, as long as ST renews its 10 years longevity promise every year.

The register interface of an STM32F1 that'd be manufactured in 2029 will be exactly the same as that of one built in 2007.

You have the drivers in source code form, you should have every right to use it (but IANAL), so you don't have to worry about not being able to get it in the future.

Not being developed further by ST means that they won't break it either. On the other hand, the STM32Cube libraries had some incompatible changes in their 5 years of lifetime so far.

Maintainability

Changing an existing software to use a completely different library would almost certainly increase complexity and decrease maintainablity and stability. There'd be wrapper calls more or less compatible with the StdPeriph interface, the less compatible edge cases causing lots of headaches. There'd be workarounds for passing STM32CubeF1 data structures (so-called handles) around.

Scalability

You are already aware of the fact that STM32Cube has severe performance problems, so introducing it would be rather counterproductive when scalability is an issue.

StdPeriph drivers exist for the STM32F4 family, which would be the next logical step up from STM32F1.

There are no StdPeriph drivers for the F7 and H7 family, but some peripherals are compatible, others differ only in register layout and some additional functionality, so porting existing drivers would not be a big issue.

Perhaps surprisingly, StdPeriph should work on the STM32MP1 series, because the Cortex-M4 part of the processor is compatible with the STM32F446, for which an StdPeriph driver exists.

followed Monica to Codidact
  • 5,312
  • 1
  • 13
  • 28
0

CubeMX can generate hardware and software initialization according to your setup, which then can be exported to any IDE (Kiel, Atollic ect.), but in that case you would be dealing with HAL drivers. HAL drivers include a complete set of ready-to-use APIs which simplify the user application implementation, which is great since you dont have to deal with LL stuff like handling registers, flags ect. HAL drivers aren't perfect, there are some issues and bugs, but for some basic applications they are, in my opinion the number one solution for any begginer.

Robert Sabljo
  • 95
  • 1
  • 11