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.

[Tesla DeLorean]

Posted on September 21, 2017 at 17:49

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

It's a trap....

The five of you probably did a more thorough job. Today there enough pieces of example code that any half-wit can stitch together a proof of concept using cut-n-paste and google. There a countries with whole software industries based around zero knowledge code development.

Try applying a little stress to your test conditions. Have multiple interfaces interact. Introduce some errors and see if things recover or collapse.

The same can be said for people who've been developing 8-bit assembler apps for the last 30 years, and discovering I can run productivity rings around them with a C compiler.

[AvaTar]

Posted on September 21, 2017 at 20:06

You are correct, if one assumes a free economy with actual competition.

This is not always the case, to express it cautiously.

You can lobby a government body to issue regulations in your favor, making millions with mediocre products.

I rather not go into details ...

[Oliver Sedlacek]

Posted on September 21, 2017 at 23:35

A lot of people here have also got up and running impressively quickly using the Cube tool, and I for one would suggest sticking with it. My caveat is that I've been bitten by bugs in the tool, both in its operation and in the output it produces. Debugging someone else's code is much harder than debugging your own code, and can throw a real spanner into the project timescales because you can't usually estimate how long it will take. If ST persist and fix the bugs, these problems will ease and we will all be grateful to escape the drudgery of writing peripheral configuration code by ploughing through 100s of pages of datasheets.

Comparison with the frameworks used for the development of PC software are interesting. Microsoft had several goes at it with technologies like COM and MFC, and it's only when they produced .NET that they got it right.

[AvaTar]

Posted on September 22, 2017 at 08:09

There is the catch: ST adds new devices and functionality (read: new bugs) faster then they can fix old bugs.

It's certainly o.k. to support new devices, but some rigor with regression tests seem appropriate.

[Code Wrangler]

Posted on September 22, 2017 at 08:43

Clive One wrote:

Try applying a little stress to your test conditions. Have multiple interfaces interact. Introduce some errors and see if things recover or collapse.

I accept the challenge!!!

Currently my project has:

5 peripherals (timers, SPI, DMA) generating ~1000 interrupts per second each

255,000 ADC samples processed per second generating ~664 DMA interrupts per second

24kHz DAC output with signal processing generating 50 DMA interrupts per second

USB HID device

Some other stuff that isn't very stressful, like low-bitrate USART

Data buffers being passed between all the interrupt routines

Bone stock STM32CubeMX / HAL project EXCEPT for two tiny encoder overflow interrupt handlers that I hand-coded (and they only trigger after 32768 counts, so I easily could have put them in the HAL callback functions).

Zero bugs, rock solid. Haven't encountered a single HAL problem or bug yet.

Your statement doesn't make a lot of sense to me because Cube / HAL is just initialization code, boilerplate interrupt handlers and some rudimentary peripheral state machines (like for UART transmission). If things are going to break under stress, then it's going to be in your code and be your fault. You can't blame the framework if you happen to be a sloppy programmer who doesn't write robust code. And it's not like the HAL is a closed-source binary-linked object code library - You can easily trace into it if it isn't doing what you expect.

[Code Wrangler]

Posted on September 22, 2017 at 09:14

AvaTar wrote:

It's certainly o.k. to support new devices, but some rigor with regression tests seem appropriate.

That's what customers are for. Also for support. Much cheaper that way.

[Oliver Sedlacek]

Posted on September 22, 2017 at 09:54

Not my experience! Mysterious lock ups traced to macro loops coded without timeouts. Even with access to the source, that was really tough to find.

[AvaTar]

Posted on September 22, 2017 at 11:38

True, but creates a certain reputation of said company amongst the users in the know ...

[AVI-crak]

Posted on September 22, 2017 at 15:44

This problem can be solved by an external repository with open access for active users.

For example, bitbucket.org is ideal for this function. I think that the ST company is rich enough to pay for free access for users. This will help to close the problem of 100500 identical topics about the standard periphery - open source ready-to-use code. For users, you do not need to copy to your computer the entire huge directory from an external resource, as currently happens with CubeMX - only the most necessary at the moment.

So you do not need to store old versions of software in the event of an atomic war, the whole story will be freely available. All corrections and improvements will be immediately visible and fixed in time. Offers from users (comments, corrections, their code) - will be visible to all users, as well as administration - with the right to merge the branches of the project.

Unfortunately, the bitbucket.org service does not have a system of counters, polls, and external link systems. But I think that for a fat and rich client - they can do anything. This is real, when, according to the example of ST, new users of the st will come to this resource.

ST can make its own repository, can use someone else's resource - but for some reason does not do it, and it's strange.

[Oliver Sedlacek]

Posted on September 22, 2017 at 16:00

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.