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 seconds just by making a few clicks and regenerating the code is a godsend. Not to mention having pin variable names auto-generated from user 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 formulas is 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 delineate auto-generated code blocks from user code blocks is 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:
/* USER CODE BEGIN SPI1_IRQn 0 */
// HAL interrupt handler below never gets called
/* USER CODE END SPI1_IRQn 0 */
/* 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 assembly with direct register access is 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.