Note to ST: HAL & STM32CubeMX are awesome!!!

[Code Wrangler]

Posted on September 18, 2017 at 19:27

To ST Microelectronics (especially the programmers who work on HAL & STM32CubeMX):

I see a lot of bellyaching on these forums (especially from knowledgeable grizzled veterans) complaining about the HAL (Hardware Abstraction Library) and the STM32CubeMX configurator program. Here is my counterpoint to that:

STM32CubeMX: This tool has saved me so much time. Being able to move a pin in secondsjust by making a few clicks and regenerating the code is a godsend. Not to mention having pin variable names auto-generated fromuser labels so that the code is nice and understandable.

But the best part is how many bugs I've manage to avoid by having the graphical tool prevent me from doing something stupid and/or impossible. I'll try to create a setting, for example setting the memory width and peripheral width to different values without the FIFO enabled and it won't let me - So I look in the datasheet and see that isn't allowed.

And don't even get me started on clock configuration. Not having to deal with weird clock divider and multiplier coefficients and formulasis priceless. And being warned that intermediate clocks are not acceptable (like for example the USB clock not being 48 MHz) saves much precious time and head-scratching trying to figure out why things don't work.

Pin layout is a breeze with Cube. The number of pin assignment permutations on a 208-pin chip with multiple possible functions on each pin is staggering. It makes my head hurt just to think about how much time I wasted in years past assigning and moving pins.

Using comment lines to delineateauto-generated code blocks from user code blocksis a genius idea. I don't understand the people who advocate running STM32CubeMX once and then doing all further customizations manually (i.e. not regenerating the code). I've run 'Generate Code' hundreds of times over the course of this project as I've added new functionality or needed to move pins or change settings. The amount of time savings is incredible. And being able to avoid bugs during each regeneration cycle via the rules built into the graphical tool has saved incalculable amounts of debugging time as well.

HAL (Hardware Abstraction Library): I previously used the SPL (Standard Peripheral Library) and it was better than raw register access, but I am really impressed with how much better the HAL is. The biggest complaint on these forums about HAL is that it is 'bloated'. Well, yeah, if you actually go into the source code, you see that it is bloated for a reason. The HAL interrupt handlers take care of hundreds of maddening corner cases that normally would cause subtle bugs and require hours of debugging. And no one is required to use them - If you think they are too bloated, take the boilerplate HAL code, strip out the parts you don't need, optimize the parts that you do need, and replace the existing HAL interrupt handler with your new custom handler above it like so:

void SPI1_IRQHandler(void) {  /* USER CODE BEGIN SPI1_IRQn 0 */   My_Special_Custom_SPI1_IRQ_Handler();  return;   // HAL interrupt handler below never gets called   /* USER CODE END SPI1_IRQn 0 */   HAL_SPI_IRQHandler(&hspi1);   /* USER CODE BEGIN SPI1_IRQn 1 */  /* USER CODE END SPI1_IRQn 1 */ }�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Having the boilerplate initialization code and program skeleton auto-generated again saves so much time. And much if not all of the initialization code is not time-critical, so who cares about an extra 10 milliseconds of startup time over hand-crafted C or assembly in exchange for saving tens or hundreds of hours of programmer time AND having clean and understandable initialization routines.

Of course, for highly time-critical routines, hand crafted C or assemblywith directregister accessis called for, but that usually constitutes a tiny fraction of the codebase.

Anyway, I just wanted to express my appreciation of your efforts. In my opinion, these tools (and the powerful STM32 chips) put ST head and shoulders over the competition.

#idiocracy Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Code Wrangler]

Posted on September 20, 2017 at 17:54

waclawek.jan wrote:

PS. You might want to look also at the

always_inline

function attribute.

Yes, but it isextremely laboriousto add that to all the inline functions of an existing library like the LL driver library unlessyou want to usesome kind of an ugly hack like:

#undef __INLINE
#define __INLINE __attribute__((always_inline)) inline
#undef __STATIC_INLINE
#define __STATIC_INLINE __attribute__((always_inline)) static inline
#include 'stm32f4xx_ll_gpio.h'
#include 'stm32f4xx_ll_tim.h'
etc.�?�?�?�?�?�?�?�?�?

[Code Wrangler]

Posted on September 20, 2017 at 18:21

I do use that level of abstraction:

static inline void LED_Blue(uint32_t Brightness)
{
#ifdef LED_RED_BLUE_USE_GPIO
 if (Brightness)
 LL_GPIO_SetOutputPin(LED_Blue_GPIO_Port, LED_Blue_Pin);
 else
 LL_GPIO_ResetOutputPin(LED_Blue_GPIO_Port, LED_Blue_Pin);
#else
 LL_TIM_OC_SetCompareCH1(TIM12, (Brightness <= MAX_PWM) ? Brightness : MAX_PWM);
#endif
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Only now, using the LL functions suggested by Vasile, my code is much cleaner than with the previous direct register access.

[waclawek.jan]

Posted on September 20, 2017 at 19:04

Yes, but it is extremely laborious [...]

I never suggested you to do that. I am known to despise the 'libraries' as such.

JW

[Code Wrangler]

Posted on September 20, 2017 at 23:48

I ended up doing the ugly hack. Even '-Og' optimization killed useful techniques that I use for debugging like making an 'if' statement for the condition I wanted to break on, then setting a variable to itself in order to have a place to put a breakpoint on. '-Og' optimized the whole code away.

waclawek.jan wrote:

I am known to despise the 'libraries' as such.

Yeah, we know it's part of your stealth plan to retire from your ST Technical Support 'job'

As more and more people move to the libraries, you will be able to say 'That involves a library I'm not familiar with. Sorry, can't help you.'

But serious question, if tomorrow you were made vice president of the ST Software Support division, what exactly would you do in terms of libraries, support, etc.? I have a feeling that your choices would sooner or later lead to the bankruptcy of the microcontroller division as people said 'Forget this chip - it's too complicated. I have to memorize a 1400-page datasheet just to toggle an LED.'. But at least they would be able to toggle the LED at the highest speed possible!

People complain about catering to noobs, but the Arduino pretty much saved Atmel from bankruptcy. Granted, it couldn't save them from acquisition, but that's a different story.

[Oliver Sedlacek]

Posted on September 21, 2017 at 10:44

Code reuse and higher levels of abstraction are the future! Programmer productivity needs to increase to drive down development times and cost, and configurators like the Cube are here to stay. They sit above the silicon and the compiler, allowing the application developer to concentrate on added value code. My big complaint is that the quality of these tools needs to be every bit as good as the compiler and silicon, and the quality of the Cube isn't. Finding bugs introduced by the tools is really, really hard, and the loss of confidence is hard to restore. It can be done as Silabs have demonstrated with their tools, but it's hard to see how ST can restore the reputation of the Cube.

[AvaTar]

Posted on September 21, 2017 at 12:28

Programmer productivity needs to increase to drive down development times and cost, and configurators like the Cube are here to stay.

This statements are only true if your project management agrees. My experience, and not my opinion.

[Oliver Sedlacek]

Posted on September 21, 2017 at 12:43

True, but I've never worked for a manager who didn't want to drive down development times, sometimes with a total lack of understanding of the impact on quality. Ever heard the mantra 'We don't have time to do it right, we do have time to do it over'?

[AvaTar]

Posted on September 21, 2017 at 13:44

True, but I've never worked for a manager who didn't want to drive down development times, ...

I did, and others too.

While I started my career with assumptions similar to yours, I experienced many instances were all efforts to modernize SW development were overthrown in favor of lower hardware costs.

And often, being the first on the market with a mediocre/buggy device is more rewarding than being second or third with a perfect one. Think IBM PC, MS Windows, or VHS video recorders ...

For years I worked with an ASIC that had a 8051 core, with all debug support removed - for cost reasons. How many SW engineering freshmen would accept such a job today ? (now, me neither ...)

For 100k or more devices sold p.a., a few cents saved on HW costs will finance many month of SW development.

Those companies exist as well, and they will not follow the ST Cube mantra in the foreseeable future.

[Glen Larson]

Posted on September 21, 2017 at 16:17

What?! Perhaps I'm too new to this tool to have a bad impression from the past. I'm getting work done that 10 years ago would have taken a team of 5 and that's assuming the off-the-shelf parts were purchased.

It's fairly unbelievable that the tool generates working applications with such ease.

[Tesla DeLorean]

Posted on September 21, 2017 at 17:06

That's worked well for Microsoft, some times when you ignore fit-and-finish the competition (Google/Apple) come along and eat your lunch. You get known for mediocre quality, and tolerable performance. People get wise, the bar to entry is now higher, so to re-enter the market you have to be significantly better.

It is also a false economy, lack of rigor on the engineering side significantly increases costs and loads on the support side. You don't need 3 tiers of tech-support when you are dealing with just idiots who can't read the manual, and real issues you can help fix and resolve. First, it makes you focus on idiot-proofing your designs, and second you can focus on real issues, not noise from people who find surface defects in your product.

I come from an IC Design background, shipping something that's marginally functional is not something you can fix post delivery. You test stuff thoroughly because you have to wait weeks to see the results.

The other issue with CubeMX is the deceptive nature of the ease of code generation. There are going to be surprises with latent issues due to blocking, dead-locks, race-conditions, priority inversions, etc. Spurious failures you see in the lab scale very quickly in the field. Have fun when your products fail at the most inconvenient times, and nobody knows how anything actually works.

https://community.st.com/tags#/?tags=idiocracy

‌