Author Topic: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?  (Read 49716 times)

0 Members and 3 Guests are viewing this topic.

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 567
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #75 on: February 20, 2016, 03:20:56 AM »
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.
Never trust a government that doesn't trust you.
 

Offline MobileWill

  • Regular Contributor
  • *
  • Posts: 58
  • Country: 00
    • Mobilewill Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #76 on: February 27, 2016, 07:59:21 AM »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2151
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #77 on: February 27, 2016, 02:31:55 PM »
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"...
 

Offline MobileWill

  • Regular Contributor
  • *
  • Posts: 58
  • Country: 00
    • Mobilewill Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #78 on: February 27, 2016, 02:44:27 PM »
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.
 

Offline mhelin

  • Contributor
  • Posts: 6
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #79 on: April 01, 2016, 06:18:03 PM »
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


 

Offline mhelin

  • Contributor
  • Posts: 6
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #80 on: April 01, 2016, 06:34:59 PM »
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?


 

Offline jeremy

  • Frequent Contributor
  • **
  • Posts: 695
  • Country: au
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #81 on: April 01, 2016, 07:42:46 PM »
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  :(
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 567
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #82 on: April 02, 2016, 02:20:29 AM »
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.
Never trust a government that doesn't trust you.
 

Offline savril

  • Regular Contributor
  • *
  • Posts: 60
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #83 on: April 02, 2016, 07:35:43 AM »
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.
 
The following users thanked this post: jnz

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3276
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #84 on: April 02, 2016, 08:25:18 AM »
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
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #85 on: April 02, 2016, 08:49:08 AM »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 567
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #86 on: April 02, 2016, 09:02:12 AM »
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.
Never trust a government that doesn't trust you.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2151
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #87 on: April 02, 2016, 04:24:57 PM »
Quote
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.

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

 
 

Offline Back2Volts

  • Supporter
  • ****
  • Posts: 314
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #88 on: April 03, 2016, 06:16:24 AM »
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
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3276
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #89 on: April 03, 2016, 07:38:29 AM »
Quote
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  :-//
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 272
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #90 on: April 03, 2016, 08:34:48 AM »
ST should buy ChibiOS HAL and work from there. It's clean, practical, efficient, correct and easily understandable.
 

Online technix

  • Super Contributor
  • ***
  • Posts: 1197
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #91 on: April 12, 2016, 10:40:09 PM »
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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #92 on: April 12, 2016, 11:05:02 PM »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Offline eck

  • Contributor
  • Posts: 15
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #93 on: April 12, 2016, 11:19:26 PM »
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.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 317
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #94 on: April 13, 2016, 12:53:20 AM »
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!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1424
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #95 on: April 13, 2016, 01:56:00 AM »
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.

 

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: se
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #96 on: April 13, 2016, 01:59:54 AM »
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..
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #97 on: April 13, 2016, 02:46:38 AM »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Online blueskull

  • Supporter
  • ****
  • Posts: 5610
  • Country: cn
  • Final year EE PhD
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #98 on: April 13, 2016, 06:47:37 AM »
I'm happy with STM32CubeMX for now. At least with MDKv5 and Nucleus. BTW, MDKv5 is free is you use only CM0 and CM0+ devices form ST -- ST has already paid for the license.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline epv

  • Newbie
  • Posts: 2
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #99 on: April 15, 2016, 05:59:58 AM »
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.
« Last Edit: April 15, 2016, 06:03:31 AM by epv »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf