Use STM32CubeF4 or Standard Peripherals or DIY?

[mduffy]

Posted on November 26, 2014 at 02:01

I can see that STM32Cube is the new hotness, but...

I am starting a new project with the STM32F405xx and FreeRTOS (ideally the current rev 8.1.2).  It seems that there are lots of layers added to peripheral access in the name of the HAL.  On the other hand, STM will be devoting most/all of its resources to the Cube.

Just interested in the opinions of others who have made similar decisions lately.  I don't want to be fighting a library that it supposed to make things easier to port among various STM32 devices, but I do want to be smart about leveraging library code.

TIA,

Mike

#stm32f4 #freertos #stm32cube

[stst9193]

Posted on November 26, 2014 at 09:40

Hi Mike,

I made similar decision some months back, I ported existing code to new HAL and free RTOS based on Cube generated code that I used as framework for my port.

The good side is that you get a working code fairly quicky even using some complex feature like DMA without having to dig into documentation to write your own code. You also have to write a lot less code for accessing hardware than with the previous ST libraries.

For the down side, look at my other post ''[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/FreeRTOS%20and%20HAL%20driver%20timeout%20issue&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21]FreeRTOS and HAL driver timeout issue'' . The HAL driver are poorly architected with wait loops under interrupts and lack flexibility as well as fonctionnality. You may end up having to re-write them.  By the way they are not RTOS aware so you need to provide your own protection as necessary for your application.

One can expect ST to improve their implementation to address the current shortcomings and limitation. But when?

Gerard

[frankmeyer9]

Posted on November 26, 2014 at 11:58

The good side is that you get a working code fairly quicky even using some complex feature like DMA without having to dig into documentation to write your own code. You also have to write a lot less code for accessing hardware than with the previous ST libraries.  ...

 

 

For the down side, ... the HAL driver are poorly architected with wait loops under interrupts and lack flexibility as well as fonctionnality. You may end up having to re-write them.

 

That is exactly the problem with the Cube software - it targets (intentionally or not) the casual hobbyist with superficial/mediocre knowledge of the MCU. It promises to deliver complex application by a simple point-and-click interface, without the need to RTFM.

Not unexpectedly, the results are mixed for hobbyists, and disappointing for professionals.

You may end up having to re-write them.

 

That is a no-go for commercial users. If such a code generator were used, it had to be touched every time the generation model is changed - a waste of ressources.

And by the way, commercial projects tend to have tight budgets, and often go for the least possible hardware costs. That excludes fat/buggy libs, even if auto-generated without much effort. Those companies tend to hire developers that can go beyond point-and-click, read/understand long datasheets, and code down to register level.

The payoff comes with the number of units sold, so they are prepared to invest in professional tools and developers, and in project time. I have personally witnessed project delays for weeks to avoid the next, bigger MCU, costing a few cents more.