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

[v]

When I find some time, I'll clean it up and put it on github.

That would be awesome! Please let me know when you do.

[FrankBuss]

When I find some time, I'll clean it up and put it on github.

That would be awesome! Please let me know when you do.

I did something similar for my Kerberos project. The file regs.xml is the description and regs.py generates the VHDL code, the assembler inc files and the C header files from it. (see regs.h, regs.inc and main.vhd). But it needs some more features and cleanup.

Is SVD an industry standard and easy to use for own projects? I thought BSDL would be the standard way to describe registers and pins, but never found the time to learn how it works.

[diyaudio]

MPLAB never hits breakpoints correctly, seriously WTF. when will this mess end?

[Lukas]

Is SVD an industry standard and easy to use for own projects? I thought BSDL would be the standard way to describe registers and pins, but never found the time to learn how it works.

SVD is defined by ARM, so you may call it industry standard for ARM µCs. SVD is fairly reasonable self-explaining XML, I managed to implement my SVD register manipulator without looking at any sort of spec or documentation.

[westfw]

I don't think that ST understands C-level software, which is pretty bad considering that they're writing documentation and libraries in C these days.   Consider the fractional divisor for the USART, documented as: baud = Fck/(16*BRRGEN)
Excellent, I say to myself.  Shift to create the fixed-point fraction, divide, done.  BRRGEN = FCK/baud;  That's ... almost elegant the way the 16 multipliers cancel out!

But the documentation goes on to explain how it SHOULD be done.  In great detail:

Example 2:
To program USARTDIV = 0d25.62
This leads to:
DIV_Fraction = 16*0d0.62 = 0d9.92
The nearest real number is 0d10 = 0xA
DIV_Mantissa = mantissa (0d25.620) = 0d25 = 0x19
Then, USART_BRR = 0x19A hence USARTDIV = 0d25.625
Example 3:
To program USARTDIV = 0d50.99
This leads to:
DIV_Fraction = 16*0d0.99 = 0d15.84
The nearest real number is 0d16 = 0x10 => overflow of DIV_frac[3:0] => carry must be added up to the mantissa
DIV_Mantissa = mantissa (0d50.990 + carry) = 0d51 = 0x33 Then, USART_BRR = 0x330 hence USARTDIV = 0d51.000

WTF?  Surely the people who wrote the standard peripheral library noticed that it was simpler than that?   Nope (this is the STP library):

Code: [Select]

  /* Determine the integer part */
  if ((USARTx->CR1 & CR1_OVER8_Set) != 0)
  {
    /* Integer part computing in case Oversampling mode is 8 Samples */
    integerdivider = ((25 * apbclock) / (2 * (USART_InitStruct->USART_BaudRate)));   
  }
  else /* if ((USARTx->CR1 & CR1_OVER8_Set) == 0) */
  {
    /* Integer part computing in case Oversampling mode is 16 Samples */
    integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));   
  }
  tmpreg = (integerdivider / 100) << 4;

  /* Determine the fractional part */
  fractionaldivider = integerdivider - (100 * (tmpreg >> 4));

  /* Implement the fractional part in the register */
  if ((USARTx->CR1 & CR1_OVER8_Set) != 0)
  {
    tmpreg |= ((((fractionaldivider * 8) + 50) / 100)) & ((uint8_t)0x07);
  }
  else /* if ((USARTx->CR1 & CR1_OVER8_Set) == 0) */
  {
    tmpreg |= ((((fractionaldivider * 16) + 50) / 100)) & ((uint8_t)0x0F);
  }
 
  /* Write to USART BRR */
  USARTx->BRR = (uint16_t)tmpreg;

Wow.  That was so convoluted that I lost confidence in my own simple code.  So I wrote a test program to confirm that it produced the same results as the STP code.  Yep.   Wow.

It got a little prettier in the Cube HAL driver.    Now it's all put in a macro, instead:

Code: [Select]

/* stm32f1xx_hal_usart.c  */
    husart->Instance->BRR = USART_BRR(HAL_RCC_GetPCLK1Freq(), husart->Init.BaudRate);
It looks nice and clean.  But the macro is still calculating fraction and integer parts separately:

Code: [Select]

/* stm32f1xx_hal_usart.h */
#define USART_DIV(__PCLK__, __BAUD__)                (((__PCLK__)*25)/(4*(__BAUD__)))
#define USART_DIVMANT(__PCLK__, __BAUD__)            (USART_DIV((__PCLK__), (__BAUD__))/100)
#define USART_DIVFRAQ(__PCLK__, __BAUD__)            (((USART_DIV((__PCLK__), (__BAUD__)) - (USART_DIVMANT((__PCLK__), (__BAUD__)) * 100)) * 16 + 50) / 100)
#define USART_BRR(__PCLK__, __BAUD__)                ((USART_DIVMANT((__PCLK__), (__BAUD__)) << 4)|(USART_DIVFRAQ((__PCLK__), (__BAUD__)) & 0x0F))
Those are NOT likely to be calculations that resolve to constants at compile time, given the layers of abstraction and indirection that appear to be standard for using these libraries.

So... just "wow."   There goes my confidence in libraries from ST.  It's not like I hunted through massive amounts of code looking for a bad example - the USART is about the third peripheral to deal with in the blink, hello-world progression.  (and then there's the reference back to that first peripheral - the rcc.  They derive, programaticaly and at significant expense, the clock frequency to divide.  I dunno.  That's not the way I would do things if I was writing the code.  Not close.  Bigger, slower, more obscure, harder to understand, and ... without obvious benefits.   Sigh.)

[baoshi]

You loose 90% of your target audience if the $10 board needs a $150 hobby license toolsuite 

They could address that by adding support for plain Makefile based projects for gcc to STM32CubeMX (and I wish that they would). But then, based on how their headers are written, I bet it would be a ghastly mess that would make automake-generated makefiles look simple by comparison. 

I made one.
http://www.ba0sh1.com/stm32cubemx-gcc-makefile/

[dannyf]

I don't quite understand why anyone would want to waste time on Cube.

[baoshi]

I don't quite understand why anyone would want to waste time on Cube.

Right. It helps me to understand how bad it is

[kalhana]

Cube sucks. The only thing i find it useful for is planning pin usage in a processor.

I keep a policy of not using anyone elses code, only using my own. I have made exceptions from this for really atrocious stuff (USB, TCP, Modbus...) where i focused on getting somebody elses shit to work, but in general I only use my own code. I do use helper libraries like the ST's SPL, but only after i review the code line by line. I work from plain register definitons if need be. Save the "one code fits all" stuff for linux users with GHz's and GB's.

I have learned this while working with Mircochip's pic24f library, which gave me a week of hair-pulling because the library was not compatible with the mcu I was using (despite it claiming to be)... and the mcu had an extra configuration bit.

As for general quality:
ST: very good silicon, good documentation, SPL is ok, CUBE is shit
Atmel: silicon is ok, documentation is generally ok although sometimes lacking (mostly manageable after examining the examples provided), IDE is shit, or rather adapted to MCU use in a shitty way (no 'binary' display in debug mode? - come on!)
NXP: good silicon, good documentation, crappy policy towards low volume users, hobbyists and open source crowd (eg. they won't disclose the debugger protocol to OpenOCD people)
TI: good silicon, good documentation, ok libraries, but chips are expensive and they do not cover the lower range too well
Microchip: silicon=mostly shit, documentation os ok, compilers and IDE are shit. $40 genuine debugger is an example to show to other manufacturers
Freescale, Silabs/EnergyMicro, Cypress: can't say, I've never had much practical experience with them (i serious project I mean, I dabbled a bit with some low-end devboard)

Definitely agree with you about the STMCube. It's such a mess. I started with the STM32 back in 2009 when there was none of this complexity with massive levels of code abstraction. I still prefer to go down to register level custom code when it comes to STM32 and its peripherals.
I got a shock when I first installed Cube and the horrible code that it generated.   
I think I'm sticking to register level coding.

On the other hand, TI Hercules series MCUs have an excellent graphical code generator (HALCOGEN). That's a good example of how ST should have done it. HALCOGEN generates very clean code and very easy to follow, pretty much all the registers are assigned hard values when you click the generate code button rather than the MCU doing 20 lines of code to find 1 register's value.

I just wish that TI made M3/M4/M7 CPUs that had similar performance to what ST and NXP offer (fast clock speeds) aimed at multimedia type devices in addition to the industrial/automotive controller types that they currently do. And if they implemented HALCOGEN for M3/M4/M7, that would be awesome!
 

[JohnnyBerg]

I don't quite understand why anyone would want to waste time on Cube.

As pointed out before, it is handy for figuring out pins when designing a board.

I have never used the software before. As it turns out, Cube is not implemented for the F1 series 

[v]

The Cube looks like it has involved huge amount of work, and as @JohnnyBerg has mentioned it is great for board design.

It is such a shame that the code generation is so poor.

If you look in `Program Files (x86)/STMicroelectronics/STM32Cube/STM32CubeMX/db` you can find hundreds of XML files including: MCU pin mappings, all configuration options for peripherals for each different MCU, and all the file templates (`.ftl`) used to generate the code.

Collecting all the data in these XML files is awesome. If someone wanted to make a better Cube, all the data required is there.

[NVIC]

I have never used the software before. As it turns out, Cube is not implemented for the F1 series 

It exists.  Link at bottom of the page. 
http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF260820?icmp=pf260820_pron_pr_feb2015&sc=stm32cubef1-pr

[hamdi.tn]

I have never used the software before. As it turns out, Cube is not implemented for the F1 series

They added F1 series recently

[yuantuh]

I generated sw4stm32 project for stm32f427 (144 pins) prototype board using STMCubeMX 4.7.0 and imported it to Eclipse, working straightaway. Absolutely it is a great tool. So far I tested SDRAM (64MB), Ethernet (RMII), USB host (MSC using two pins), USB device (VCP using two pins), SDIO (1 bit), USART1, 2, 3, SPI 1, 3, 4, 5, I2C3, CAN1, and many EXTIs using generated HAL library. USART 6 and SPI6 are not tested due to no chip in it. All are working fine with minor HAL code modifications.

It is strange to say HAL is terrible. I am confident that ST will enhance and improve HAL in the future. Also sw4stm32 will be integrated into Eclipse better and better. Currently sw4stm32 project under Eclipse has some broken problems when changing properties, but it can easily be fixed by modifying the .cproject/.project files.

I used to write code for PIC8/16/24/32, MSP430, MC16, SAM7, ARM9 chips by accessing registers directly. Now it seems STMCubeMX and HAL make my life much easier.

The wonderful thing is that STMCubeMX can help me to figure out much more peripherals to be used.
 

[Ribster]

I tried the open STM32 stuff, but i find it not easy. From a perspective of an OS X user.
They support linux, maybe the toolchain is better there.
My experience with the GNU ARM eclipse plugin is much much better.
http://sourceforge.net/projects/gnuarmeclipse/

[Joerg]

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

Yes, I do :-) ... very much so indeed !! Actually I went through the same hell at the same time ... and now I'm back in it again :-(.

I'm into embedded development since the 1980s ... went through all of it, Intel, Motorola, Ti, Pic, ATmega, ... you name it. Thought nothing about it when I saw that a client had used the Stm32F4 for something which I needed to take and extend ... made the schematic, made the board, got it back and ... bang, hit my head in that unbelievable mess. For me the worst part ist that the internet is full of information and a lot of it is outdated but you don't know which part ... Everybody and his dog make their own stuff and it's all combined in every which way, IDEs, compilers, libraries, ... it never ends. The more I read about the possibilities the more confused I become. It's like Linux - instead of all people working by one consistent plan to achieve a single truly great product everybody does his own wrecked partial solution. I hate it (the STM stuff, not Linux as that started as a "hobby" so it has the right to develop however it wants to). I got a chance to work on something "more important" for half a year but now I'm back and wonder again what to use ... unbelievable. If there is a truly good solution which doesn't cost an arm and a leg ... let's hear it :-) ... I need to communicate with 3 chips over SPI at high speed, handle some ADC stuff in parallel and some RS485 too ... my main problem at the moment is the chip select of the SPI as that has to "flank" at the right bit at ~20MHz because these sensor chips otherwise can't talk straight. I thought that /CS (or /SS as they call it) had hardware support - which is true, but not for the usual case, only when the controller is the slave ... right ...

[richardman]

my main problem at the moment is the chip select of the SPI as that has to "flank" at the right bit at ~20MHz because these sensor chips otherwise can't talk straight. I thought that /CS (or /SS as they call it) had hardware support - which is true, but not for the usual case, only when the controller is the slave ... right ...

Joerg, not entirely sure of your application, but you can use software slave management (which is what we use in the JumpStart API, for maximum flexibility in terms what pins to do), and you should be able to clock the GPIO pin as fast as you like. Certainly, ST claims up to 50 MHz (has not tried it myself).

// EDIT: Do you really mean CS at 20 MHz? How fast are you running the SPI?

[Ribster]

Joerg,

I think you need to make the /CS purely software based and use DMA.
The half transfer complete / transfer complete interrupts will let you know when the DMA is done, and then you can change the /CS.
Hope it helps..

Greetings

[autobot]

How can  we fix it ?

Today, many large companies don't care much about such libraries - because it's more efficient to write from scratch - and at their volumes - it makes sense. Sadly they hold all the power in the market. we just eat their leftovers 

But if it was as efficient to use higher level libraries , while remaining as efficient - it would be great for those companies - faster time to market is very valuable. If it was possible - those big companies would pressure ST and others on their libraries , and we would get better libraries.

That's one thing. The second thing is , unlike the situation with TI's good tools(halcogen) - which don't push the market towards tools , because TI sells chips for more money because of the tools/libraries - we need high quality tools to be availble to many companies. , so we need to make it much easier than today to build those tools.

Well it's actually possible to build extremely efficient libraries relatively easily - using compile-time compute (using c++11 's constexpr keyword). Here's a blog post with an example:

http://blog.xpcc.io/2015/06/08/computing-and-asserting-baudrate-settings-at-compile-time/

Using such advanced c++ and a few other tricks, a german robotic club , written , as a side effort - an extremely efficient mcu library for a variety of mcu's. it's called xpcc:

example of efficiency:
http://comments.gmane.org/gmane.comp.hardware.arm.cortex.xpcc.devel/16

site:xpcc.io

So relatively easy to write , very efficient tools/techniques are possible. What's needed in extent (not sure) is to raise awareness ,and maybe port the technique to where it would be most effective to push vendors, etc.

Sounds reasonable ?

[c4757p]

Well it's actually possible to build extremely efficient libraries relatively easily - using compile-time compute (using c++11 's constexpr keyword). Here's a blog post with an example:

http://blog.xpcc.io/2015/06/08/computing-and-asserting-baudrate-settings-at-compile-time/

Using such advanced c++

C++ is not even required and this is nothing new

It just takes skilled developers (who tend to get better jobs than writing ST's HAL ) and time (which bean-counters don't want to pay for) to write non-bloated libraries that aren't total shite.

[Joerg]

my main problem at the moment is the chip select of the SPI as that has to "flank" at the right bit at ~20MHz because these sensor chips otherwise can't talk straight. I thought that /CS (or /SS as they call it) had hardware support - which is true, but not for the usual case, only when the controller is the slave ... right ...

Joerg, not entirely sure of your application, but you can use software slave management (which is what we use in the JumpStart API, for maximum flexibility in terms what pins to do), and you should be able to clock the GPIO pin as fast as you like. Certainly, ST claims up to 50 MHz (has not tried it myself).

// EDIT: Do you really mean CS at 20 MHz? How fast are you running the SPI?

Thank you Richard and also Ribster,

yes, I guess I have to "bit-bang" that line ... Problem is that when I designed the board I only read the spec of the STM32 and they describe the SPI as having hardware support for the NSS ... so my whole plan about how much the chip would be busy with that task is now in doubt ... I really have many things to do in "real time" (its a racing telemetry application) and it's battery driven. I thought I could just set up there two channels, connect them to the DMA and be done ... now the processor has to da that but then that will increase the jitter of other stuff and some of that is highly time critical. Sorry about the 20 MHz ... these sensor chips run slower, but must be timed exactly in sync - the 3rd SPI has to run like hell @ maximum speed ... I'll see what I can get in reality. Right now I still struggle with the darn tools :-) ... Thought we live in the digital millenium and all but my speed would not have been much less had I just started to write assembly the first day I got confronted with all this and made m own symbols for the register addresses ... or at least that's how it feels at the momen :-) ...

[FrankBuss]

But if it was as efficient to use higher level libraries , while remaining as efficient - it would be great for those companies - faster time to market is very valuable. If it was possible - those big companies would pressure ST and others on their libraries , and we would get better libraries.

I really like the mbed library, because it is very object oriented and easy to use. STM32Cube and other graphical code generation tools help you to create the initial boilerplate code and to manage the modules on a chip and the GPIO pins, but if using the serial module is just a one liner for a class-instantiation (with sensible default initialization), you don't need such tools. embed is already ported to a lot of platforms, see here. Besides the online IDE you can download it for offline compilation, too.

It might not be as fast as possible (I don't think it uses C++11 features for compile-time baud rate rate devider generation and the like), but with modern chips some overhead doesn't matter, if it greatly simplifies programming. And it has a lot of additional high-level stuff for reading sensor etc., too.

[Ribster]

so my whole plan about how much the chip would be busy with that task is now in doubt ... I really have many things to do in "real time" (its a racing telemetry application) and it's battery driven. I thought I could just set up there two channels, connect them to the DMA and be done ... now the processor has to da that but then that will increase the jitter of other stuff and some of that is highly time critical.

I don't think it is an issue here..
Use timers. Let those timers interrupt the CPU at a fixed rate.
If you make sure that this timer has the highest interrupt priority, it will be reliable.
At each interrupt, do the necessary telemetry stuff, and poll the sensors if necessary.
This also has the advantage that you get an exact timestamp of sampling. This can be valuable for logging.

A seperate timer interrupt that handles the sensor readout over SPI via DMA is possible as well.
I don't see any issues as to what you want to do, just make sure you prioritize the right things and all will be okay.
Good luck!

[geno86]

I have spent hours of frustration with the STM32 Cube like most people here. My solution may seem a little crazy, but it works.

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.

The ARM Cortex M4 is a really good series of chips. Very powerful. But sometimes its easier and faster to reinvent the wheel than use someone elses code with 100 bandaids.

 

[gnasirator]

I do quite like the Cube. Works flawlessly for me. I'm using Atollic TrueStudio Free together with it and a discovery board as programmer. Works a treat and is cheap.