ARM-M7 - Worried about STM32Cube stability (chaos imminent?)

So I am pretty new with the STM32 MCUs and following good advise I am using the standard peripheral library - nothing is more frustrating than driver bugs.The only problem so far is that little compiled HMTL for the F0 had for some reason the timer functions in the modules index (weird). But the source files are so well commented that I use them instead.

But now the ARM-M7, the STM32F7. The only driver library is on the STM32Cube. For what I've head there are some bugs in the other families libraries and I am worried about that.

I come to ask for more experienced users opinion on the cube at this moment (the F7 and other families). I want to keep using the standard library (though I really liked the MX) but then I will have a different library for the M7!F4 codes in Standard Peripheral library are for the most part lost no?

As annoying as it may be, moving to HAL really is your only long-term option, particularly if you want to use the STM32_F7. The only support they (at present) have for the STM32 F7 is the CubeMX HAL library. Like any vendor library, it has the usual annoyances, and as other posters (Clive, etc) have noted, it does have lots of bloatware. In general, I use the HAL stuff for initialization, and then switch to register level programming for the actual time-critical I/O routines.

As far as the STM32 F7 Discovery: I just received mine this afternoon and started working with it. It can be described in one word: AWESOME.

The board itself (IMHO), is the best Discovery board that ST has ever produced,Excellent TFT graphics, great price (USD 50), lots of (HAL based) software libraries, and at 216 MHz, just an absolutely screaming fast MCU. This chip is going to be a home run for ST.

Unfortunately for ST, the competition has a faster part (300 MHz), with more memory (2M, 384K), and a full FPU. That's a bit of a dangerous mix if either choice requires me to rewrite a skid load of code, and I have math heavy problems.

As ST was trying to be first to market, I think they migrated the lower speed bus, memory, and peripheral set from the F4xx family as a fast safe path, rather than making a fresh start...although I was surprised by the maximum flash size limitation in the F7xx.

Having had poor experiences with two different processor families in two different eras from that other vendor, I'm happier and feel safer for production life stability with the STM32Fxx family. On the other hand, one sometimes has to take a specific part path to hit a required performance level, although real application code testing is sometimes shows a different net result than what the listed specifications lead one to expect. 300MHz really isn't very fast for a Cortex-M7 core, but the speed/power trade-offs are dependent on which process size it is implemented with and vendor acceptable process cost and yield considerations.

More on topic, a HAL path seems to be a poor choice...at least as the only choice. The SPL was one of the things that I found positive about the STM32F family. I fear HAL based designs are leading newcomers down the path to code bloated poor performing embedded solutions, just as the world has come to accept for desktop environment applications. (A HAL does not have to be bloated and poor performing, as a decades old well known server class HAL shows, but they often are because it's less effort.)

I previously posted these remarks in the Keil forum .. but it's on-topic here.

I've used both NXP and ST ARM microcontrollers. I found ST's
Standard Peripheral Library a useful foundation and was able to
integrate it with Keil middleware without much trouble.

Now we have the HAL / CUBE as well as ARM's mbed and the Keil MDK
seems to have hitched its wagon to the ST HAL mess (For STM32 at
least). Why is that happening when Keil is an ARM company and ARM is
planning to release new improved mbed upon an unsuspecting world? (https://mbed.org/ ARM say ... creation and deployment of commercial, standards-based Internet of Things devices ... we're building the new operating system, software components, tools and ecosystem that will make this vision a reality.)

I chose to use ARM Cortex microcontrollers because I was attracted
by the processing power and the CMSIS software ... especially the DSP
functions.

I don't want to program everything at register level but I also
don't want the overhead and obfuscation of the HAL
implementation.

Rowley CrossWorks seems to be one of the only self-contained
software eco-systems left.

It's hard to know what mix of software tools / middleware to
choose - none really appeal. Regarding other manufacturers' parts - the STM32F series does seem to offer the most peripherals. That's important to me more than highest speed.