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

[uc2013135191]

Posted on June 22, 2015 at 04:57

Hi everyone,

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?

[Tesla DeLorean]

Posted on June 24, 2015 at 18:57

Chaos suggests you have no control.

I'm not scared of programming micro-controllers at a register level. I prefer a thin abstraction so my code can get ported with minimal effort, and bit-level minutia doesn't get into my core code.Porting SPL functionality that I use to another chip/architecture also does not scare me.What worries me more is that this isn't a full Cortex-M7 implementation. Will have to see what the F7-DISCO delivers.

[tm3341]

Posted on June 26, 2015 at 00:22

I can say the same as clive1.

It's better then programming in register level than using HAL drivers. So many bugs, very bad optimization. So much code is executed which is not necessary all the time. I don't like this.

[grandvu]

Posted on June 30, 2015 at 06:15

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.

[Tesla DeLorean]

Posted on June 30, 2015 at 13:31

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.

[pmoore]

Posted on July 13, 2015 at 17:21

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.)

[John F.]

Posted on July 14, 2015 at 10:37

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.