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.

[LMI2]

Posted on September 18, 2017 at 19:30

Yes, I agree. The idea is good. But it is not complete yet, there are gaps in CPUs and peripherals it supports.

[AvaTar]

Posted on September 18, 2017 at 19:59

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 seconds just by making a few clicks and regenerating the code is a godsend.

Reading that, I immediately thought of the famous quote from Arthur C. Clarke:

Any sufficiently advanced technology is indistinguishable from magic.

[Tesla DeLorean]

Posted on September 18, 2017 at 20:41

>>I see a lot of bellyaching on these forums (especially from knowledgeable grizzled veterans) complaining about the HAL (Hardware Abstraction Library) 

And you know that some of that resulted in some of the egregious bugs in it actually getting addressed, it's a double edged sword.

[Code Wrangler]

Posted on September 18, 2017 at 21:12

Actually, I'm not referring to bug reports at all - Everyone agrees that complaints about bugs are a good thing.

Rather, I am referring to a more philosophical bias against HAL & Cube. It reminds me of certain stubborn and dogmatic people who try to justify their preferences and biases. For example:

'IDE's are useless. Real programmers use VI (or Emacs) and GCC (or clang) and makefiles.'

'Command line tools are better than GUI tools.'

Calculators vs. slide rules

Every Gentoo Linux user ever

That dude who wrote the entire Spinrite hard disk utility in assembly language ('Because it's faster')

Etc.

It's great that they run Linux From Scratch on their hand-built liquid nitrogen-cooled overclocked Beowulf cluster with 12 monitors all running command-line bash shells that can parallel compile their STM32 code in milliseconds written on Emacs customized with all their preferences linked to hotkey macros using only libraries they themselves wrote in hand-coded assembly with direct register access written bare-metal without an RTOS for maximum performance.

Meanwhile let the rest of us mere mortals who just want to enjoy the main programming task rely on our GUI tool crutches and pre-written libraries.

[Vasile Guta_Ciucur]

Posted on September 19, 2017 at 05:12

I agree, when CubeMX works, it does wonders. It Is a must for a beginner as Cortex-M based microcontrollers are at a higher level regarding complexity. HAL is very usable for people that used Wiring language for Arduino boards and never got down to the bare metal using C language. HAL it is like Wiring, very accessible but produce bloated code. I started with STM32 micros in the same way. but there are implementations that are not working for me right now. Have you looked at the Low Level driver? It completes the ST-M package very well and is the best solution for the people complaining about HAL - it is for me.

You know, when you rely so much on this tool and libraries, not having the levels of knowledge of an expert, the amount of frustration increase fast, directly proportional with the hours spent on the problem and the accumulated fatigue. In most of the cases, the people that complains about HAL, are the people that needs HAL. And ST needs them. It is very nice for you to express your gratitude, but the tremendous complexity of these micros, compared with the 8-bit PIC and AVR micros require such tools and libraries. Otherwise, we will look elsewhere for fast prototyping,

BTW, some how related to the 'bloatness', Arduino libraries for STM32 should be based on LL and not on HAL, as I understand it is right now... is not useful to add another level of 'unneeded baggage'. 

[AVI-crak]

Posted on September 19, 2017 at 10:34

Good idea.

Where there is too much magic, religion is born. The person stops thinking, and begins to just believe.

[AvaTar]

Posted on September 19, 2017 at 10:43

Rather, I am referring to a more philosophical bias against HAL & Cube. It reminds me of certain stubborn and dogmatic people who try to justify their preferences and biases.

And I don't like HAL/Cube because of it's 'stubborn and dogmatic' nature/concepts it imposes on the user.

The way it uses Systick, callbacks and wait routines might fit beginners on a superficial level, but excludes alternative design concepts.

Not to mention the hassle with auto-generated code vs. version control.

There are reasons why Cube is not used for price-sensitive projects. The idea behind the microcontroller is a low-cost, all-in-one microprocessor, so this cost-sensitive projects will always prevail.

It is a good starting tool for beginners, but it does not generate insights.

The conclusion 'I can do a Cube project, therefore I know microcontrollers' is terribly wrong.

Just analyze the desperate Cube-related help requests here ...

And then, there are the bugs, and the less-than-completely tested features ...

[LMI2]

Posted on September 19, 2017 at 14:18

There will be some abstraction layers. We are not using assembler to make our own mail software or text editor and so on. We use Windows, or some clone, which surely has its problems.

But the reason I write is because I disagree on that HAL or any other API hides or prevents deeper knowledge. Most works do not need bit level work with settings. And with a good starting point, API or what ever, you can always study more if there is need, but only if you want/need to.

[waclawek.jan]

Posted on September 19, 2017 at 14:24

And with a good starting point

This is the point. As said above, Cube is a bad starting point.

JW