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.

[AVI-crak]

Posted on September 22, 2017 at 19:17

All the secondarily used code are simple functions. Their work can be easily understood even without additional description. It's often faster to write yourself than to look for someone else's solution. But when functions are part of a large algorithm - it's easier to take the finished one.

Such code can be found on external open repositories, forums and websites - wherever discussion is available.

Without discussion and improvement - it's useless to use dead code. You can deal with this code only if you have free time, which is not always permissible. But now think about how often the algorithm of HAL functions is discussed. Not the application of functions (this is in bulk) - namely the algorithm itself.

The library in my understanding is precompiled code with unique compilation settings, and its own unique description of functions. Almost black box. I do not use this muck either.

[Vasile Guta_Ciucur]

Posted on September 23, 2017 at 09:45

Oliver Sedlacek wrote:

A lot of people here have also got up and running impressively quickly using the Cube tool...

Is not that we don't know how to program a microcontroller. The majority of noobs like me are coming from 8bit microcontrollers and the main complain is that 32bit Cortex-M based micros are very complex and there are tons of examples of people trying to program them for the first time bare metal, as they are accustomed, and failing. There are a lot of configurations to be made and the datasheets are not at the level Microchip make their owns. CubeMX is of tremendous  help but using HAL, is like going back to Wiring language (is ok for those that never got past to it). I think LL is the best bet for the future. In our opinion, a code for a Cortex micro is already fat (the second complain) because of those configurations, no need for a HAL ballast.

[Glen Larson]

Posted on September 23, 2017 at 22:11

Some much negativity and with a good dose of arrogance!

I can do better, too. I just have things to accomplish and don't want to internalize thousands of pages of reference manual, data sheet, core architecture and instruction set documentation. Someone mentioned this is good for 'noobs.' I bet it is. I've been in the field since when a 286 was a cutting-edge processor. (Look it up!) I can get so much more done using higher-level tools that doing truly bare metal work in 2017 strikes me as absurd.

I've got applications running that'll have multiple communication buses running simultaneously in addition to classic embedded control work and I only have to write the business code. Amazing stuff.

Customers and users expect higher-and-higher levels of capability and the cube tool allows me to deliver this with a small, cost-effective team.

[AvaTar]

Posted on September 24, 2017 at 19:45

Customers and users expect higher-and-higher levels of capability and the cube tool allows me to deliver this with a small, cost-effective team.

By hiring zero-knowledge, minimum-wage noobs ?

With

a good dose of arrogance!

, one can interpret it that way ...

[kraiskil]

Posted on September 25, 2017 at 12:04

Oliver Sedlacek wrote:

I absolutely and totally disagree. Every company I've worked for has tried to set up a code library to promote re-use and to improve productivity. These efforts have without exception failed, with programmers building up and relying on private libraries. To make a shared library work users need 100% clear documentation on what every module and function does and what restrictions there are. The code also needs visible test result records to provide confidence of code quality. A freely accessible public library will not do.

There are two parts to this:

HAL is -currently- an open-source, freely accessible public library, intended to promote re-use and improve productivity.

Allowing in users to submit patches to it sounds like an awesome idea to me. The opposite is reporting bugs on this forum, without any possibility of follow-up.

As a bonus to uploading the HAL to the suggested code hosting repo, we (the end users) would actually get to see the 'visible test result records', which we don't have access to right now. Not to mention being able to bisect issues popping up with our custom platform, that the library developer don't have access to.

An open-source development model of the HAL sounds like a no-brainer to me.

Now, for due diligence's sake the write (merge) access to this might be restricted to ST.

Then there is an 'application library' like the example codes that come with Cube currently. These probably would benefit from a more lose control, giving more people opportunity to contribute. For the diligent programmer, these would rather be references or starting points, not to be used in end products at least as such.

But I'd love to see both. I hate to have to do patches

https://community.st.com/thread/40591-usb-audio-microphone

.

[Code Wrangler]

Posted on September 25, 2017 at 16:43

I'm inclined to mark this comment as the 'answer' of this thread.

Guys and gals, any objections? It seems like a fantastic suggestion that we can (almost) all support.

[Thomas Borowczak]

Posted on September 27, 2017 at 13:51

Thank you very much

homert2014

for taking the time to express your satisfaction about STM32CubeMX and HAL. Our teams have worked very hard to make this happen and will continue to improve our softwares and firmwares with the only objective to ease the life of STM32 MCUs developpers. These users feedback are precious for us to improve our offer and adjust our development strategy. Do not hesitate to continue contributing. Once again, and on behalf of all STM32 teams,thank you.

[Code Wrangler]

Posted on September 27, 2017 at 23:12

You're welcome. It is the least I could do considering how much time and frustrationCubeMX and HAL have saved me in terms of getting my project up and running.

I made a new thread listing some

https://community.st.com/0D50X00009XkXVVSA3

for future consideration.

Keep up the good work.

[vincenthamp9]

Posted on September 28, 2017 at 10:30

I'm just a casual reader around here and just found this topic with a little help of STs last community update newsletter, but since I always appreciate ST folks reading complaints and suggestions around here, I feel like I need to post some thoughts.

First of, yes, I think HAL is an enrichement compared to bare-metal programming, but it also still has flaws. I've reported 2 bugs last year, one of which could easily have been avoided if whoever developes the L4 library would have communicated with whoever is responsible for the F4 one, since a bug was duplicated.

I can see how some people compare about things being 'bloated' because especially the configuran/init functions are too big. It might take forever to re-config some tiny thing which might be a single register change in reality. The LL version might help in that regard.

Whats generally just in a really really bad shape are the .svd files, those are always either incomplete, lack the newest chips or generate non uniform names for peripherals!

Concerning further abstraction or a 'HAL2.0' I feel like C++ would be the way to go. I've recently been involved in development of a L0/L4 library which practically compile-time optimizes every peripheral configuration down to direct register writes by heavy use of template classes and functions. It also takes care of DMA -> peripheral linking and configuration for you, without the need to remember which DMA and channel is responsible for what... there are so many possibilities using advanced modern C++.

[LWade]

I wouldn't have complained about the CubeMX if it wouldn't have generated lousy, bloated, inefficient and buggy code. But it does. The whole design principles behind the framework is just nonsensical.

For software developers wanting to use C or C++ in an object oriented approach the ST HAL code efficently destroys every attempt on a structured design. Global handles everywhere, insertion points based on callbacks that rely on these globals everywhere.

It is obvious that they really haven't thought things though, they build nearly everything on weak function overrides (a gcc feature), in different layers on confusing places instead of thinking about how and where the user actually want to inject it's code or be able to do abstractions and modularization around it.

The HAL code makes itself dependent of an internally maintained tick instead of using injections points for timeouts etc. They should have used the microchip's xdk for avr's as a reference instead, those guys knows how to write properly structured code.

It is also almost impossible to version control it in an efficient and sustainable way.

Regardless how one twist and turns this subject, the code written by the ST engineers is very poor and very amateurish from a structured point of view.

On top of all this, it is extremely badly documented if you want to know the rationale behind the usage of a function (or, more precisely, not really documented at all). There are some function headers that "document" (repeats) the obvious (like people maybe did in the 80's), but nothing useful about context, and the actual why's.

It may suit for a small and very simple play-around home hobby project (and that is MAYBE).

But for professional development with the thoughts of reusability, extensibility, modular design with isolation, this crap is just going to cause headaches and a lot of costs for the company and product.

I suggest to use only the GUI as an overview of the pins, generate some code that helps doing the pinouts, clock settings.

But try to evict anything else, it is just junk that wastes precious cpu cycles.

ST HAL code is junk written by dummies for dummies that wants to stay dummies.