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

[v]

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

Here is my war story...

PS. I am new to embedded dev coming fresh from web-frontend/backend/iOS. Feel free to point out obvious rookie mistakes!

3 weeks ago I was tasked with porting custom firmware (developed with the Standard Peripheral library - now replaced by the HAL/Cube) from an custom STM32F407 board, to a new custom board with the STM32F411CEU chip. The program simply dumped data from the IMU and GPS onto an SD card when a button was pressed.

Everything went *relatively* smoothly apart from the fact that the GPS unit on 2 separate devices was destroyed. You can imagine how difficult that was to work out, but hey - welcome to embedded dev! Our office whiteboard is now covered in ESD warnings and every morning when I get out of bed I put on my ESD band around my ankle - lesson #1 .

Then I needed to pull the IMU data from the I2C2. Sounds simple, right?. I told my colleagues it would be less than a day of work. The I2C1 worked perfectly on a Nucleo board, but I2C2 did not work on either board. After a long process of debugging, probing, endless Googling, scouring forums I concluded that the I2C2 was broken. Lots of people had reported problems. I tried nearly everything, and each time I would try something I found that the darn BUSY_FLAG was set. The general sentiment seems to be that the I2C bus on STMFx series was very broken. I only recently heard about the infamous CPAL library, which seems to have been created because ST messed up so badly. But nowhere do they tell you. I came across the CPAL in a single Stack Overflow post where somewhere mentioned this library they had used long ago but could not remember the name. I had a [Wisdom of the Ancients](http://xkcd.com/979/) moment. This comic pretty much sums up my entire three weeks programming STM32. I found myself constantly wishing I could read German with so many Google journeys leading to [http://www.mikrocontroller.net/forum]. I even considered asking my friend's Polish girlfriend to translate a forum for me because I saw a couple of interesting keywords in English popping out of a search result snippet.

I then verified that the I2C2 worked with the new HAL drivers from the Cube in a blank project. With no way to fix it, no other pins available to use other I2C peripherals, I had to move to the HAL drivers. I initially tried to just replace the I2C with the HAL I2C. After many hours of fixing compile errors, it did not work. Same BUSY_FLAG problem. Then I tried replacing the entire Standard Peripheral folder of drivers, and everything else. This was an insane amount of work and I eventually had to give up. So many wacky configurations, etc.

So now I was staring down the barrel of an entire rewrite of a perfectly working, well-tested codebase (the code and drivers were battle-tested many times in industrial projects), all because of a single I2C bus not working. I thought - OK, the HAL drivers will have bug-fixes moving forward, have support for my MCU (STM32F411CEU, which is not supported by StdPeriph), this rewrite would probably have been neccessary anyway. And every page on the ST website prophesizing that "the Cube" is the way of the future and I should migrate.

I was quite excited about the prospects of the Cube. Supposedly it would let me configure all my pins, check conflicts, generate code for all my protocols (a checkbox for DMA - woohoo!), FreeRTOS, USB virtual com, etc. I budgeted three days to port the code.

Holy fuck was I wrong. I have never used such poor quality software in my life. Nothing works out of the box at all. The examples don't cover any of the actual ways you would use the drivers. A virtual com example only available for the STMF429 chip, and only as a USART to VCP bridge. FreeRTOS integration not even a 1/4 finished - but with no note to the user that it is not implemented. USART examples for polling, interrupt driven and dma, but only for a contrived example of sending messages back and forth between two boards. I must have tried all the examples and nothing worked. The generated code is messy with pin configurations strewn all over the place, starting your project off with nice spaghetti code before you write a single line.

I would be so much better off *without* the cube.

Every single perhiperal was a *huge* battle with so many little bug fixes, workarounds, and hacks to the Cube's generated code along the way. When I finally got the USART working, it was by removing a the enormous interrupt routine that the Cube had generated which was causing over-run errors.

When I look back on the codebase I now have, it feels like the aftermath of a warzone. So many bandaids, patches, configuration settings that *just* work. I have a code base which I do not dare to change a line without flashing to the device and checking everything still works.

Icing on the cake for ST is if you look at the back of an STM32F4 Discovery kit ($15 USD - oo so cheap!) it mentions four "Development Toolchains": Altium Tasking, Atollic TrueSTUDIO, IAR EWARM, Keil MDK-ARM. Minimum price: $3000. Wow. What a joke.

After this experience I would never use STM32 for a new project again. Atmel looks like where its at. Big long datasheets, a free IDE (visual studio based!), cross platform support, a nice library with 1000s of examples, an ecosystem to share code, etc, etc. I am aware that it might seem like the grass is always greener, but when you are in a landfill the greeness of the grass is less of a concern.

So...am I alone? And how can we fix it?

STM32 make cheap, powerful chips, and have a lot of smart developers in their ecosystem, but I think the Cube has too much momentum right now (and is in too many powerpoint slides) to prevent it from collpasing in on itself and forming a singularity.

I have some ideas about how to fix this ecosystem which I will outline later.

[JohnnyBerg]

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

I do

How can we fix it?

You can't.

The story gets worse if you start looking for updates for the libraries. The version hell implemented

[AndyC_772]

You've come to pretty much the same conclusion I did about the libraries; they're little more than an obfuscation layer between application code and hardware.

I do use Cube to generate the start-up code that configures peripherals. And then, one device at a time, I comment it out and initialise the peripheral myself by poking its registers directly, until there's almost nothing of ST's code left.

You've not mentioned whether the I2C bug turned out to be faulty hardware (ie. a chip bug), or faulty software. I know there are people who steadfastly refuse to read the data sheet for the chip, and to check and program register values directly, and this is precisely why I'm not one of them. You absolutely do need to know what the underlying hardware is doing, and using a library only makes this more difficult.

It's not like, say, a graphics card, which is an extraordinarily complex device that's totally reliant on a high level API. With a device like that, you need functions to do things like draw a line, or a triangle, or whatever.

With I2C you're much closer to the hardware. You need to know what the state machine is doing, what conditions exist on the line, and which device is doing what... and I've yet to ever come across a more precise, efficient or reliable way to do this than to read the registers.

Once I figured this out, programming the STM32 got a whole lot easier.

[mikeselectricstuff]

IME driver/config libraries just add more scope for errors.
 For simple stuff like I2C, instead of spending  time learning and debugging other peoples' code, it's often quicker to just write your own code, which is specific to your needs, not some generic mess that tries (& fails) to do everything.
e.g.  a UART is a very simple peripheral but there are lots of different ways it can be used, it is hopeless for anyone to try writing a library to cover all possibilities.
Manufacturers try to push this crap as making things "easy". If they spent the same amount id time writing clear datasheets and error-free header files , and providing some tested example code as a base to work from, we'd all be a lot better off.
 

[JohnnyBerg]

For simple stuff like I2C, instead of spending  time learning and debugging other peoples' code, it's often quicker to just write your own code, which is specific to your needs, not some generic mess that tries (& fails) to do everything.

I agree.
However, for not such obvious stuff like USB or build in Ethernet, thinks get really nasty.

[dannyf]

ST's (STM32Cube) software ecosystem is terrible

I have been saying that for a long time. STM32Cube is essentially a half-assed attempt by ST at PE.

- how can we fix it?

by not using it.

The good old standard peripheral library is perfectly fine. Or go to the registers directly.

[v]

by not using it.
The good old standard peripheral library is perfectly fine. Or go to the registers directly.

I wish I didn't have to use it! I had such a battle-tested codebase before but the I2C thing and lack of support for STM32F411xE forced me to update. If the I2C had worked I would have never been stuck outside in this storm.

I regret not bit-banging the I2C 2 weeks ago.

You've not mentioned whether the I2C bug turned out to be faulty hardware (ie. a chip bug), or faulty software.

There is lots of errata surrounding I2C and it seems like its a problem on the silicon and they have implemented a collection of software workarounds. I only got it working a few days ago, and I'm still finding it hangs after multiple debugging sessions without disconnecting the board power.

IME driver/config libraries just add more scope for errors.

I see the benefits of working close to the hardware, but I do believe that if there was a well-defined high-level Arduino/mBed style library it would reduce the surface area for bugs and make it easier for them to test the library.

They could easily create a sample project which calls all the methods of these high level libraries and when something didn't work it would be obvious.

[JohnnyBerg]

The good old standard peripheral library is perfectly fine.

Hmm .. also had some bad experiences there, again with usb and ethernet
Also, a lot of different versions out there.

Or go to the registers directly.

Probably best, but it takes a lot of time. One must be really anxious (or being forced) to go that path.

[dannyf]

I regret not bit-banging the I2C 2 weeks ago.

F4's i2c is fine, both hardware and standard peripheral library drivers. The i2c issues are limited to F1 and STM8 - there the hardware is kind of fine, and the datasheet is fine, but the standard peripheral library drivers are incorrectly coded.

[v]

I regret not bit-banging the I2C 2 weeks ago.

F4's i2c is fine, both hardware and standard peripheral library drivers. The i2c issues are limited to F1 and STM8 - there the hardware is kind of fine, and the datasheet is fine, but the standard peripheral library drivers are incorrectly coded.

How do you know it is fine on the F4? And how do you know its limited to the F1 - do you have a link to an errata sheet?

If you have a Nucleo-F411RE, try and use I2C1 with the StdPeriph (it should work), then try use I2C2 and you will see the busy flag.

I've heard from many sources that there are problems, and experienced them myself so I have to disagree.

[nerdyHippy]

I think I've run into the same BUSY_FLAG issue that you have on a pair of 32F4 Discovery boards. I am using Cube and all its generated code, and one board simply refuses to reset the busy flag, so I2C comms never initiate. The other board works fine with the same code. Very odd, and rather irritating.

[dannyf]

The other board works fine with the same code.

that would confirm for you that the issue is NOT with the code.

[diyaudio]

STM32 make cheap, powerful chips, and have a lot of smart developers in their ecosystem, but I think the Cube has too much momentum right now (and is in too many powerpoint slides) to prevent it from collpasing in on itself and forming a singularity.

I have some ideas about how to fix this ecosystem which I will outline later.

 The same story applies to Microchip (even worse IMHO), None of these companies are prefect at their embedded software line or even close to it. Companies just spend effort customizing rewriting (and getting good C/C++ developers NOT summer interns) or buying software layers they need its called R&D and its integrated into the cost of a product. Small companies or hobbyist like us are left to dwell at the bottom of barrel.

Ti stuff looks promising...   

 
 
 

[v]

None of these companies are prefect at their embedded software line or even close to it.

Atmel looks like they are. Free VS based IDE. Arduino mindset. Big ecosystem. Good documentation. Does anyone have experience with Atmel, I'm thinking of switching, would love to hear if it is a good as it sounds...

[clive1]

The Atmel IDE is slow but the community is great and the lib is limited to bugs which are fixable within 15minutes.
Trick#1: TurnOff online spellcheck - saves much ressources.

ST has a good commercial support, the HAL & CUBE was the biggest misstake of their own ecosystem roadmap.

[kamtar]

Me too, im using atmel just because of VS IDE. Documentation is pretty good, lots of useful app notes,etc..

[dgtl]

I feel the same about STM32. The chips are nice, documentation is not the best and the code is terrible. I've done a number of projects with different STM32 chips recently and looked into their std periph lib, st cube, usb dev lib, lwip hal lib etc. So far, what I've encountered is terrible and I've had to write almost everything from scratch.

The embedded software development on microcontrollers is different than application programming on top of an os. For embedded programming, usually the task is controlling hardware (at least controlling the communicating interfaces) and although it may have multiple layers, the bottom layer of the software is quite hardware-related. The uC's are not so often used for generic data-processing that is hardware-independent. This makes it difficult to have generic HAL implementations and stable HAL API like OS'es can provide; the hardware is not abstracted away like on generic OS'es.

In such case, the HAL library can only be a collection of frequently used snippets to do common tasks. The programmer programs the HW, the library can only help the programmer. The HAL does not have to be something readly-made one-size-fits-all complete product. For me, the HAL library is most useful, if I can get some pieces that I need without writing them from scratch. If the functionality I need is something special and uses the HW in some clever way (ie some strange protocol-dependent implementation of DMA-based triple-buffered high-throughput or timing-critical communication), I'll write it myself anyway. But if I need to configure a GPIO or to perform a simple blocking SPI write etc, it would help to have a ready-made function, that is simple and does just that. I'll prefer multiple small functions that I can choose the ones that I need as opposed to a large configurable mess, that needs to be cut apart and put back together if something is not like I need.

For ST's case, the HAL is a monster by itselt. I need to understand the HW anyway. So I'll need to read the DS to figure out what needs to be configured in which way. But then I need to figure out, how to do it using the HAL. So there are 2 things to know instead of one now. The HAL takes register bits in variables, so there is just register API wrapped into HAL API. In case of simple interfaces like SPI/I2C/UART, the configuration of the peripheral for simple non-DMA operation is writing a couple of config registers. Filling out a huge struct, where most of the parameters do nothing in my case, is just not justified. I'd be much more happy when having some simple commonly used functions, ie for calculating and setting USART baud rate divider. I would appreciate, when the resulting code is written in a sane way so it would get optimized back to just a couple of register writes, not a huge amount of run-time calculating of already-known values that could be pre-calculated compile-time or a read-modify-write for every regiter bit changed. (I've seen runtime calculation of log2 to determine bit field offset in register from mask!) The complicated use cases can not be covered anyway, so leave them out or implement multiple copies of different approaches, I'll use what I need.

Even when leaving the HAL aside, the troubles are not over yet. Even the header file containing the register definitions is a mess. Most of the bit fields at nonzero offsets do not have their offsets defined. Then some HAL peripheral c/h files define them locally there. A lot of the enum-style bit fields do not have the options defined (ie if there is a bit field MODE, that has possible values of MODE_A, MODE_B etc, then these values should be defined as well. In ST's case, usually MODE_0, MODE_1 bits are defined, that is almost as useless as nothing at all). The USB controller register definition is a total mess. So even if I write all my code myself and do not use ST's std periph library or cube, I still need to keep local in-house copies of the header files that are improved; spreading all of those missing defines in a number of different source files in a lot of projects would just make a bigger mess.

There are some open-source alternatives to ST HAL library. For example, libopencm (was libopenstm32). Of course, they are licensed in such way, that may not be acceptable for commercial non-opensource projects. But if the open-source developers can re-use some common pieces of code and contribute them back, it will only benefit them. Without the vendor support, this will be limited to what was needed for some developers who cared to contribute their code back and the quality may vary in different places. I do not expect that it would help commercial developers nor that commercial code developers would contribute back a lot to such projects. So only ST can make our life easier; either they will or not.

The IDE and compiler wars should be kept separate of the HAL library issues. Different developers have different preferences. The ARM Cortex chips are giving us a great ecosystem of different tools, that can be operated on almost any vendor's chips. For most of the cases, the tools are quite equal; what really matters is what the developer is used to and feels most comfortable with. I like linux+eclipse+gcc, but for most of the major development tools, the result of the work is not that much limited by the tools, but by the engineer doing the work.

I've had my own issues with Atmel, that's why I converted to ST. At this moment, I would not go back.

[dannyf]

I feel the same about STM32.

I would venture to say that many of your comments are understandable, but probably attributed to the wrong party (ST).

You shouldn't think of an OEM library as something that your code interfaces with directly. As you pointed out, quite correctly, that those are simply versatile snippets - designed to be all-inclusive for all user applications. Because of that, they can be too scattered and too overwhelming - they are so many of them to learn and to remember. And in any given application, you are only using a small portion of the chip's and library's functionality so that kind of "capabilities" seems too much.

I would suggest that you consider the concept of "middleware": a layer of your code that performs some of the most frequently used functions in a way that you feel comfortable. Your code doesn't directly call the OEM library, instead, it calls the OEM library through the middleware.

Filling out a huge struct, where most of the parameters do nothing in my case, is just not justified. I'd be much more happy when having some simple commonly used functions, ie for calculating and setting USART baud rate divider.

For example, in this case, you can write a routine that calculates the baud rate and set up the usart for you in a way that you feel like it.

The beauty of this approach is that in the future, if you were to switch the underline libraries, from standard peripheral library to Cube, from calling registers directly to calling them through OEM libraries, or to even go from one processor to another processor, you can simply link in the appropriate middleware and your user code remains unchanged.

In my case, I can write a piece of code for STM32 for example on turbo C or Keil C51 and then compile it later on with the right middleware for CoIDE or Keil or IAR, using this approach.

To my code, the OEM libraries do not exist, even if my code eventually relies heavily on them.

[andyturk]

The Atmel IDE is slow but the community is great and the lib is limited to bugs which are fixable within 15minutes.
Trick#1: TurnOff online spellcheck - saves much ressources.

ST has a good commercial support, the HAL & CUBE was the biggest misstake of their own ecosystem roadmap.

Clive? *the* Clive from STM32 forums?

[JohnnyBerg]

Clive? *the* Clive from STM32 forums?

When Clive dies, ST ARM dies .. 

[FrankBuss]

Icing on the cake for ST is if you look at the back of an STM32F4 Discovery kit ($15 USD - oo so cheap!) it mentions four "Development Toolchains": Altium Tasking, Atollic TrueSTUDIO, IAR EWARM, Keil MDK-ARM. Minimum price: $3000. Wow. What a joke.

The free version of Atollic TrueSTUDIO has 32kB code limit, which is sufficient for simple projects.

But you are right, I had some problems with CubeMX, too. I started with the latest CubeMX version and tried to generate a project. It didn't work, ran into this problem. The answer didn't really help, but after starting TrueSTUIDO once (was a fresh installation) suddenly CubeMX worked. Maybe they need the TrueSTUDIO workspace or some settings, which is strange for a simple code generator.

Another problem was when I tried to save the project. It said something about "no drive c: found" (don't remember the exact wording). But after the TrueSTUDIO project files were generated, this problem disappered, too, or maybe it was some problem with spaces in filesnames.

Then I tried to open a customer CubeMX project which was created with an older version of CubeMX, to change the CPU type so that I could test it with my Discovery board. It didn't work. Lots of configuration warnings and errors, impossible to fix.

And the code quality of the HAL library is not good. Take a look at this function:

Code: [Select]

__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}

I guess that's the way it was implemented in Windows 98, which hangs after running 47.9 days.

When I tested my Discovery board first some years ago, I used the STM32 standard peripherals library, a plain Makefile process and a GCC ARM cross compiler. Sure, you have to read the datasheet and do all the initialization yourself, but it worked without problems. No fat IDE and no code size limitations. If you are using Linux, then you can use some of the nice tutorials how to build your own cross compiler, and ready to use templates for your STM32 board, see for example this article.

But I have to admit, sometimes a big IDE and a debugger is nice. I tried Rowley CrossWorks (the free version has a 16k code size limit) and with ST/Link (integrated in my Discovery board) you can see realtime updates of variables while the program is running, single-step debugging it etc. At least single-step debugging is possible with Eclipse and gdb, too, but needs some work to install and configure all the required software. CrossWorks works out of the box.

Does the Discovery board work with mbed? I used this framework for a LPC microcontrollers and the C++ class library makes it really easy to write programs for it. Code generators like CubeMX are terrible, compared to a well designed object oriented framework like mbed. Take a look at this code for a fully working example of a virtual USB COM port. All default initializations etc. are encapsulated in the classes and you can derive and overwrite your functions. This makes it even easy to develop your own USB device with it.

And you can install the mbed toolchain locally on your PC, too, no need to use their online project management and compile system, if you don't want your code get wet in the cloud (see this description how I did it for Windows).

[diyaudio]

Clive? *the* Clive from STM32 forums?

When Clive dies, ST ARM dies .. 

Clive deserves an award.

[dannyf]

I guess that's the way it was implemented in Windows 98, which hangs after running 47.9 days.

Such implementation isn't meant for long delays - there are far more efficient ways to do that.

The implementation is the right way for short delays - most programmers actually use it without understanding its virtue.

[donotdespisethesnake]

I guess that's the way it was implemented in Windows 98, which hangs after running 47.9 days.

Such implementation isn't meant for long delays - there are far more efficient ways to do that.

The implementation is the right way for short delays - most programmers actually use it without understanding its virtue.

Nevertheless it contains a nasty bug, definitely wrong way to write it even if it is supposed to be inefficient.

We had similar code in one of our projects, it caused mysterious timing errors. Since the same lines had been copied several times, I had to trawl through the whole project fixing them.

[dannyf]

I had to trawl through the whole project fixing them.

How did you "fix" it then?