ST's (STM32Cube) software ecosystem is terrible - how can we fix it?

[Sal Ammoniac]

I wrote all the hardware drivers and a lot of the upper level software myself. I used the reference manual, datasheet, and the Cube as a guide. For the past couple of years it seems to work well. I got many peripherals on the STM32F4 working, and relatively quickly. For the most part, do what the reference manual says, look at the Cube as a guide on how to go about it.

This. 

Most vendor libraries are bloated and bug-ridden and not worth using for anything except perhaps a simple application. I always write my own low-level drivers at the register level and only include the functionality I actually need rather than implementing everything the chip supports like the vendor libraries do.

[MobileWill]

I am working on a STM32 project and dumped CubeMX for ChibiOS. It has its own HAL, support for many STM32 micros and others, and many examples. Sorry if someone mentioned it, I didn't read all the posts. A bit late to the party here. Its been smooth sailing since I dumped STM32CubeMX.

[westfw]

Does ChibiOS for XXX actually include things like peripheral drivers?  I would have expected "ChibiOS over CUBE" to be equivalent to "Unix instead of assembler"...

[MobileWill]

Does ChibiOS for XXX actually include things like peripheral drivers?  I would have expected "ChibiOS over CUBE" to be equivalent to "Unix instead of assembler"...

Yes! Has support for lots of stuff, even SDIO, and LTDC. Also uses DMA where possible.

[mhelin]

I have found CubeMX quite useful now as it's integrated to SW4STM (Eclipse), though I don't like the idea of adding own implementation between some special comment lines - it would be nice to have Java annotations in C to markup own code snippets. Regarding the snippets, there are the STM32 Snippets (library/interface) for L0 and F0 which allow for using direct register access (without HAL layers, though being able to co-exist with the HAL libraries). It would be nice to have the Snippets for F1 .. F7 families as well.

Snippets: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1898/PF260157

[mhelin]

Actually I don't know if all HAL implementations (for different families) are equal. For an example the STM32CubeL4 page (http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908) says:

"STM32Cube includes the STM32CubeMX which is a graphical software configuration tool that allows generating C initialization code using graphical wizards. It also comprises the STM32CubeL4 platform composed of the STM32Cube HAL and the Low Layer (LL) APIs, plus a consistent set of middleware components (RTOS, USB, FatFS, graphics and STM32 touch sensing). All embedded software utilities come with a full set of examples running on STMicroelectronics boards.

The STM32Cube HAL is an STM32 embedded software stack that ensures a maximized portability across STM32 portfolio, while the LL APIs make up a fast, light-weight, expert-oriented layer which is closer to the hardware than the HAL. HAL and LL APIs can be used simultaneously.

Both the HAL and LL APIs are production-ready and have been developed in compliance with MISRA-C guidelines and ISO/TS 16949. On top of that, ST specific validation processes add a deeper-level qualification.

STM32CubeL4 gathers in one single package all the generic embedded software components required to develop an application on STM32L4 microcontrollers. Following STM32Cube initiative, this set of components is highly portable, not only within STM32L4 series but also to other STM32 series. In addition, the Low Layer APIs provide an alternative, high-performance, low-footprint solution to the STM32CubeL4 HAL at the cost of portability and simplicity."

Maybe it's just that F4 family is missing the LL API?

[jeremy]

I've had bad experiences with the library since the very first discovery board, and when you still had to compile your own gcc to get hard float support. Dropping to the register level makes it better (as others have mentioned)

On the other hand, the TI Tiva devices are absolutely excellent, with a great library and great documentation. But the trade off there is the price 

[Sal Ammoniac]

The Freescale Kinetis devices used to have good documentation. Now it reads like it was written by someone for whom English is a second or third language.

[savril]

Actually I don't know if all HAL implementations (for different families) are equal. For an example the STM32CubeL4 page (http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908) says:

...
Maybe it's just that F4 family is missing the LL API?

This document from ST show the roadmap (p. 12) : http://www.st.com/st-web-ui/static/active/en/resource/sales_and_marketing/presentation/product_presentation/stm32_embedded_software_offering.pdf
So LL is scheduled for January 2017.

[Kjelt]

The Freescale Kinetis devices used to have good documentation. Now it reads like it was written by someone for whom English is a second or third language.

Very well possible since they have been bought by nxp

[dannyf]

So LL is scheduled for January 2017.

What they don't understand is that if they don't stick to ONE library, people will not invest in their code thus their chips. No one in his/her right mind will use a library knowing that it is going to be gone, or be changed out soon.

ST's problem from day one has been its incompetent software developers.

[Sal Ammoniac]

The Freescale Kinetis devices used to have good documentation. Now it reads like it was written by someone for whom English is a second or third language.

Very well possible since they have been bought by nxp

The first language I had in mind is Chinese, not Dutch.

[westfw]

What they don't understand is that if they don't stick to ONE library, people will not invest in their code thus their chips. No one in his/her right mind will use a library knowing that it is going to be gone, or be changed out soon.

Amen!  It's not even clear that one of the earlier libraries couldn't be fixed, rather than replaced.

ST's problem from day one has been its incompetent software developers.

I dunno.  ONE bad library can be blamed on incompetent/inexperienced (intern?) developers.  By the time you get to four or five different poor sets of libraries, it might be time to move the blame to management.  (Is there any sign that ST has been listening to the nature of complaints from the users?)

And where is the OSSW community?  You'd think that by now at least some of the "problems" (initial chip/peripheral configuration, say) would have been solved by some snazzy chip-agnostic code generator...

 

[Back2Volts]

tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same? How can we fix it?

Send a link to this thread to ST public relations

[Kjelt]

So LL is scheduled for January 2017.

What they don't understand is that if they don't stick to ONE library, people will not invest in their code thus their chips. No one in his/her right mind will use a library knowing that it is going to be gone, or be changed out soon.

I tend to agree with you however reading their library philosophy (if you may call it that) it looks like:
- the (old) peripheral libraries were not very good and incompatible with newer ones so strike those, they are there only for backward compatibility.
- the Cube HAL libraries are intended for (non embedded) SW engineers without HW (register) knowledge, API in C++ OO style. It is in progress but if you ask me that project is overambitious, in the sense that through a GUI you can autocally create all the code including third party (bloat)middleware and it should work? That would be great if they can pull it off, from what I read in this thread they are not succeeding. Maybe one day...
- the Cube LL libraries are the next gen of the old peripheral libraries more intended for embedded SW C programmers and are compatible with the Cube HAL libraries.
It looks like they have some sort of plan, not to phase out anything before a new replacement is there, but dunno if the quality is bad people will not invest to start with 

[Koen]

ST should buy ChibiOS HAL and work from there. It's clean, practical, efficient, correct and easily understandable.

[technix]

If you feel adventurous you can throw the STM32Cube software itself out of the window, keeping its libraries and headers, but use your own IDE and toolchain.

When I researched the WCH CH563 chips their libraries are Keil-only, using their proprietary format. I borrowed a friend's Keil installation to transcompile all their libraries into GCC-compatible ELF format (with optimization cranked to max,) and on my own computer (OS X, not even compatible with Keil) I set up clang/LLVM (GCC-compatible) and OpenOCD as my own development toolchain.

[dannyf]

"Reply #90   by Koen on 03 Apr, 2016 08:34
ST should buy ChibiOS HAL and work from there. It's clean, "

Probably not.

The proven solution in this space is freescales PE.

RTE from Keil is pretty good but too new at this point . but is does provide a cross platform solution.

[eck]

The proven solution in this space is freescales PE.

... which seems to be on the way out as KSDK 2.0 isn't supporting PE anymore.

[jnz]

I guess the real crime I'm seeing is that despite their new LL being far simpler than the HAL, they have some versions that are out this month and some that will be out in 2017 :/

It's just a mild difference in headers and some work arounds for each chip - what could possibly take so long!?

Why would anyone use the LL lib for the L4 chips if it doesn't exist yet for the chips people actually buy like the F1/F2/F4!? Damn ST... Get it together!

[janoc]

I just gave up on Cube/HAL and only using Cube to for pin planning and perhaps calculation of the some of the register values (like clock dividers).

For the rest - it is either ChibiOS or libopencm3  (http://libopencm3.org/) when I don't need the RTOS. Especially the latter has a fairly small footprint. A bonus is that there are tons of examples that just work out of the box, even for complex things like USB.

[stmdude]

Regarding the LL libs..

There's no way in a very warm place I'll even attempt to use that.
If it's just the lower parts of the HAL, it _will_ suck, as the HAL was, by far, the buggiest vendor-library I've had the misfortune of trying to use in production..

I'll keep using StdPeriph for all the chips that it works on, and bang on the hardware directly for the chips where it doesn't..
Sure StdPeriph isn't ideal (functionality differs between STM32 chip families), but it does work.

I really like working with the STM32 chips (heck, see my nick on the forum), but somehow I find myself using them less and less these days.. They simply don't fit my designs any more. And, it's not because of software. There's no integrated RF connectivity, very high cost, and can't go low enough in power-consumption (for most of the STM32s).

The designs where I used to use the STM32s in were projects where you needed a beefy MCU to drive a display or similar. However, for the price of (for example) an STM32F429, I can easily get a Cortex-A7+RAM+PMIC these days..  Sure, larger footprint, but usually not an issue if you have a design with a display in it.

For low-power stuff, with small footprint, ST is at least one generation behind people like Silicon Labs EFM32, Nordic Semi and Dialog. Nordic and Dialog even have built-in radios...  And, they're still cheaper than the low-power variants of STM32s..

[dannyf]

"Damn ST... Get it together!"

That can be hard to do. I think St is rub by a nxp guy in disguise. Otherwise how do you explain their I cohrent software strategy? And a website that makes it impossible to use.

As to criticizing at software, be careful here. I got banned for simply pointing the apparent struggles some ST software developers had communicating to a wireless module over spi - check out that thread for your self. After that I wonder no more why St software sucks big time.

As to stdperipheral libs, I continue to use then to get thing up and running - I find them generally free of bugs. But I do rewrite my own when time permits.

Cube and Hal? I wouldn't touch it. I figured that when stdperipheral no longer works for my chip, I just go to rte.

[epv]

I registered just to whine here about it, too. I do like the java app for setting up pin assignments, clocks, and initialization stuff. I don't like the buggy code and hideously overcomplicated APIs that obfuscate basic functions and that you have to use in ways nobody would ever actually use a peripheral.

The stm32f1 USART stuff is espcially awful. And if you try to write code for the USB peripheral on a computer with a case sensitive filesystem, you discover that Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.c inexplicably uses an all uppercase filename for one include file, which happens nowhere else. I guess someone's caps lock key got stuck on.

I spent a few hours banging my head against i2c on f103 last night, and it still won't even toggle the clock line in master mode. I'll probably end up just writing a bitbanged version and not use the hardware. I assume the f103 has bogus i2c stuff that needs workarounds and the HAL libraries do it wrong, or something?
Anyway, sigh. I'm thinking about moving to other hw.

[dannyf]

banging my head against i2c on f103 last night, and it still won't even toggle the clock line in master mode.

That has been a very well known problem on some STM32/8 parts. The stock STM i2c examples do not work on those parts.

However, the datasheet is ABSOLUTELY right: if you code to the datasheet, it will work. The problem is that the ST StdPeriph library developers did not follow their own datasheets on those parts,