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

0 Members and 1 Guest are viewing this topic.

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #250 on: June 14, 2016, 10:28:15 am »
Quote
The reaction was you have to do that every time again per processor which is still valid.

It depends on how the person integrated the library into his code.

I use SPL in my code but looking at it you wouldn't know at all that SPL is used and the same user code works on different chips from ST and even with other vendors libraries. For example, to send a byte over spi, I always use spi_write(), regardless of platforms, or even if there is no spi hardware on a chip. On a PiC, that can be done via registers, or via plib; On a LM3S, that can be done via stellarisware; On a STM, different versions of SPL....

If ST changes its SPL, I just need to deal with the middleware and my user code remains the same.

Obviously, it can get more complex and less portable when fancier features are dealt with but that's the general idea.

That's pretty much true, in terms of how libraries are incorporated.
================================
https://dannyelectronics.wordpress.com/
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #251 on: June 14, 2016, 11:21:04 am »
That is indeed how we in our company do it also, the SPL for different ST uC's and even other manufacturers HAL's are again abstracted to a company standard API (platform).
Takes some time but when finished a joy to work with and you can choose from different vendors and or uC series.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #252 on: June 14, 2016, 09:55:38 pm »
That's not surprising. Coding approaches are a compromise, many times between hardware and software costs. On a limited mcu, you may want to squeeze out every last bit of processor cycles or RAM byte. You often  sacrifice readability, portability or readability in order to get the code to fit in a particular budget.

For bigger chips, getting more performance isn't as interesting, and software costs matter more and more so you use more and more structured approaches. You abstract and sacrifice performance. And hardware to minimize software costs.

Personally I view layering as a bug plus. It allows me to produce a robust produce within a short period of time, and charge a lot of money for that.
================================
https://dannyelectronics.wordpress.com/
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #253 on: June 20, 2016, 06:04:34 pm »
I am new to this....

I had to go through and choose between Freescale (now NXP) and ST.

At first, I was 100% on Freescale. Their IDE made everything *almost* easy.

When I first tried ST Micro (year ago), the whole flow was a cluster. It was just mounds of documentation that lead no where and the CubeMX barely worked. It felt like getting a LED to blink was a non trivial task. Also, it seemed like using the HAL was pretty difficult, but using the standard library was even worse.  And then trying to get it working with Atollic.....aw man (it basically a paid version of Eclipse!).With freescale, I was able to get the HAL or the standard lib blinking a light easily (although, their IDE needed to updated a few times).

Fast Forward to today, ST did something. The whole GUI works well now and they seemed to neaten up where to get documentation. I still think the standard library is easier on the Freescale for some reason, but the GUI makes up for it so I do not need to use the standard library. Also, last I tried, you could not use PE with those Freescale Freedom boards (tried 6 months ago and it did not work, so they could have fixed it now).
 

Online Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #254 on: June 20, 2016, 06:19:08 pm »
I had to go through and choose between Freescale (now NXP) and ST.

Using a tool chain not tied to a particular vendor certainly helps.

For commercial use, I'd recommend Keil or IAR--they both support almost all Cortex-M vendors and have a consistent interface to all of them.

For hobbyist use, I suggest using Eclipse/CDT/GCC to build your own tool chain. It's vendor independent and works well with most Cortex-M parts (as long as you can find .h header files).
Complexity is the number-one enemy of high-quality code.
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #255 on: June 20, 2016, 06:39:46 pm »
I had to go through and choose between Freescale (now NXP) and ST.

Using a tool chain not tied to a particular vendor certainly helps.

For commercial use, I'd recommend Keil or IAR--they both support almost all Cortex-M vendors and have a consistent interface to all of them.

For hobbyist use, I suggest using Eclipse/CDT/GCC to build your own tool chain. It's vendor independent and works well with most Cortex-M parts (as long as you can find .h header files).

That was the other big plus....

Programmer for ST - $20.
Programmer for Freescale - at least $250 unless you buy some cheap Chinese knock off.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #256 on: June 20, 2016, 08:47:35 pm »
Programmer for ST - $20.
Programmer for Freescale - at least $250 unless you buy some cheap Chinese knock off.

Doesn't Freescale support standard JTAG/SWD? If it does, you should be able to use a generic JTAG/SWD dongle + OpenOCD instead of shelling out for the official programmer. ST's micros certainly can be programmed and debugged like that, no need for ST Link.

 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #257 on: June 24, 2016, 01:44:47 am »
This is interesting....

I was trying to get PWM to work with my micro....

The compare register function for the PWM value is from a macro....

Also, it is not in there user manual/API...I had to find it online.

I am sort of tempted to make my own library....
 

Offline Gibson486

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #258 on: June 24, 2016, 01:50:53 am »
Programmer for ST - $20.
Programmer for Freescale - at least $250 unless you buy some cheap Chinese knock off.

Doesn't Freescale support standard JTAG/SWD? If it does, you should be able to use a generic JTAG/SWD dongle + OpenOCD instead of shelling out for the official programmer. ST's micros certainly can be programmed and debugged like that, no need for ST Link.

Very true, but that is freescale's fault for not telling me. ;)
 

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #259 on: February 10, 2017, 06:18:30 pm »
I am working with 8 and 16bits MCUs write now and I want to start with ARM, but I don't now where to start  :-//
One solution is mikroc for ARM , but its crap , and the ide its horrible if you write big projects.
 

Offline TinkeringSteve

  • Frequent Contributor
  • **
  • Posts: 289
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #260 on: February 10, 2017, 07:37:42 pm »
Hey picdev,

one very affordable way to have a modern IDE and do ARM cortex M debugging is:
- use (e.g. the community edition of)  Visual Studio 2013 / 2015
- spend 70,- EUR on the non-commercial license of the VisualGDB plugin

I have done projects with ST stuff and got some impressions from the Kinetis branch of NXP.
(can't comment on the native NXP stuff (they did cortex M stuff before buying kinetis I think)

The Kinetis devboard + libraries I used seemed less of a hassle to get to work (more than just toglging a pin) than the ST stuff, and many people agree the ST libs are bad.
But the Kinetis libs were also not quite perfect, it's probably also not a high prio project at NXP / former Kinetis, similar to ST.
But... when using just CMSIS (register definitions etc) and the reference manual of an MCU, ST stuff works fine.

OR: if strictly non-commercial, and you'd like a library, perhaps http://libopencm3.org/ could be a nice alternative .

I like ST's nucleo and discovery dev boards, debugger is already on those. Connect USB and you're done. (others are doing it this way too these days). I like the discovery more, while nucleo is geared towards arduino shield compatability, the discovery have the direct MCU pin names written besides the header pins instead stupid arduino pin names which I don't care about ;)

If you did pic before, maybe start with a smaller MCU. E.g. the stm32f100 discovery, or stm32f0 discovery. The larger ones like F4 or L4 can be even more overwhelming.
 
The following users thanked this post: picdev

Offline mrm2007

  • Contributor
  • Posts: 33
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #261 on: February 10, 2017, 08:09:28 pm »
I am working with 8 and 16bits MCUs write now and I want to start with ARM, but I don't now where to start  :-//
One solution is mikroc for ARM , but its crap , and the ide its horrible if you write big projects.

Hi,

 If you want to start with ARM, i can recommend this setup :

 IDE/Compiler : embitz : https://embitz.org , FREE IDE , based on Code-Blocks, compiler is GCC-ARM Embedded with debug capabilities.

 Board : STM32 Discovery or Nucleo board. Cheap and with installed ST-Link Programmer/Debugger on-board.

 
The following users thanked this post: picdev

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #262 on: February 10, 2017, 10:00:14 pm »
I am working with 8 and 16bits MCUs write now and I want to start with ARM, but I don't now where to start  :-//
One solution is mikroc for ARM , but its crap , and the ide its horrible if you write big projects.

For starting you could use the Keil uVision IDE, which I tried for some time now. It is free for up to 32 kB binary size, with which you can do a lot. An example: A 10 voices polyphonic synthesizer with MIDI-in and I2S realtime out to the audio DAC at 48 kHz/24 bit on the Discovery board, and ADSR volume envelope, all calculated in float, needs 15 kB, hardware setup code created with CubeMX. It supports ST-Link, works with no problems with my STM32F4 Discovery kit with the integrated ST-Link, and there are many tutorials how to use the IDE.

PS: after removing all the CubeMX code-bloat and optimizing it a bit, the binary size was 2 kB for my synthesizer, with the same functionality. Would be nice if the code generator would at least create better and more optimized code, and not all these run-time algorithms just to set some fixed register values, this makes no sense.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: picdev

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #263 on: February 11, 2017, 09:07:34 am »
Thank for your suggestions , libopen its nice suggestion, because you can have an alternative from Hal library.
I am not going to use SPL ,I think that is useless because it Doesnt support newer MSUs
Also I dont like code generators , microchip also now has code generator instead of libraries  :-- :palm:
« Last Edit: February 11, 2017, 09:12:45 am by picdev »
 

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #264 on: February 11, 2017, 09:35:04 pm »
I start  reading mastering stm32
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #265 on: February 12, 2017, 12:51:29 pm »
I have recently had to use an STM32 model which is not supported by old SPL and I was forced to use CubeMX. For my development I use EmBitz IDE.

If you want to use a completly free IDE (EmBitz) which doesn't totally suck (like Atollic Truestudio does) and uses CubeMX for code generation, and the re-generation of hardware config files in Cube still works, it can be done and is perfectly usable.

Obviously, if you're aiming at achieving maximum performance or doing something unusual with any peripheral you'll need to write code on your own.

I think I'm gonna do a tutorial on how to mix CubeMX and EmBitz, because I see many people bringing the topic up.

Btw. I think that Cube implementation of freertos sucks. It's much better to use vanilla FreeRTOS installation base on sources available from their website.
I love the smell of FR4 in the morning!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #266 on: February 12, 2017, 01:00:37 pm »
Thank for your suggestions , libopen its nice suggestion, because you can have an alternative from Hal library.
I am not going to use SPL ,I think that is useless because it Doesnt support newer MSUs
Also I dont like code generators , microchip also now has code generator instead of libraries  :-- :palm:

I can only recommend libopencm3. Between that and ChibiOS you don't need to touch HAL nor SPL at all. Just be aware of the licenses of both - it may or may not be suitable for your project.

 

Offline krho

  • Regular Contributor
  • *
  • Posts: 222
  • Country: si
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #267 on: February 12, 2017, 05:18:25 pm »
Is there a library for STM32F4 that has a permissive licensing or at least an linking exception. It's nice that there is a lot of GPLed ones but are completely useless for anything but home usage or school use.

I did a quck test a few days ago with STM's HAL and Os compiled binary with freertos+fatfs + sdio i2c and USB msc driver was 114k... and before trying I thought I could do a bootloader (IAP) with it. Will try without freertos but IMO it won't go below 100k. And I was all optimistic and thought that it will fit into the 32k with couple of kB to spare.
« Last Edit: February 12, 2017, 05:24:10 pm by krho »
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #268 on: February 12, 2017, 05:36:51 pm »
Is there a library for STM32F4 that has a permissive licensing or at least an linking exception. It's nice that there is a lot of GPLed ones but are completely useless for anything but home usage or school use.

I just noticed that mbed has support for a board with an STM32F4:

https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

I have used mbed for another microcontroller (LPC series) and it is a really nice and clean C++ framework, as easy to use as an Arduino, but more powerful and extensible (e.g. for implementing your own USB device you can derive from C++ classes and just redefine the necessary methods like for the device descriptor and the endpoint data transfer). Haven't tried it for the STM32F4 platform, but it is not difficult to create support for a similar board. When I tried it there was no support for the special version of my microcontroller, but I could create a new configuration with a different linker settings (other flash and SRAM configuration). And it is all on github, you can install it locally and don't need to use the online service, but it is nice and easy to use, too, if you do.

PS: most of mbed is Apache 2 license, similar to BSD.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #269 on: February 12, 2017, 08:48:38 pm »
Is there a library for STM32F4 that has a permissive licensing or at least an linking exception. It's nice that there is a lot of GPLed ones but are completely useless for anything but home usage or school use.
I did a quck test a few days ago with STM's HAL and Os compiled binary with freertos+fatfs + sdio i2c and USB msc driver was 114k... and before trying I thought I could do a bootloader (IAP) with it. Will try without freertos but IMO it won't go below 100k. And I was all optimistic and thought that it will fit into the 32k with couple of kB to spare.
RTOS is only around 10k no idea where you are burning the other 100k, how big is the fatfs?
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #270 on: February 13, 2017, 10:46:48 am »
I just noticed that mbed has support for a board with an STM32F4:

https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

I have used mbed for another microcontroller (LPC series) and it is a really nice and clean C++ framework, as easy to use as an Arduino, but more powerful and extensible

Be very very careful here. mBed works great on the LPC series because that one is the best supported (the original mBed boards were LPC1768 based). However STM32 support is spotty at best, so before deciding to invest the time and effort in mBed, do verify that the features you need are actually supported on the hw you are planning to use!

In my experience on STM32 the support was often in name only - aka it compiles and you can do some really basic stuff like twiddling an I/O pin. More complex peripherals like USB are often not supported at all or only on some chips and not others, for no apparent reason and with no known roadmap when they could be supported. Or only very limited support is available, missing most of the features of the hw (timers are a typical example), so if you want to use it you have to resort to register programming - all the while paying the mBed/STM32 HAL (which is what mBed uses on STM32) "bloat & bug" tax.

If you are working with NXP LPC series, mBed can be a great option but I would hesitate to recommend it for any other hw platform.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6278
  • Country: ca
  • Non-expert
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #271 on: February 14, 2017, 10:38:23 pm »
RTOS is only around 10k no idea where you are burning the other 100k, how big is the fatfs?
Fatfs about 10kB for basic implementation.
SDMMC 10kB as well.

100kB is not unreasonable as that is what I am taking (HAL, fatfs, sd, i2c, uart, etc.). But I have not bothered to look to optimize as the uc has plenty of flash.
Maybe he can post the memory listing.
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #272 on: February 15, 2017, 08:31:51 am »
RTOS is only around 10k no idea where you are burning the other 100k, how big is the fatfs?
Fatfs about 10kB for basic implementation.
SDMMC 10kB as well.

100kB is not unreasonable as that is what I am taking (HAL, fatfs, sd, i2c, uart, etc.). But I have not bothered to look to optimize as the uc has plenty of flash.
Maybe he can post the memory listing.
I wonder if this is the debug size eg the optimizer is off than I understand.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #273 on: February 15, 2017, 01:26:38 pm »
I finally am taking my first hands-on steps in the ARM domain (blinky led for the win :-+) using a cheap STM32F103C8 ebay board.

Roaming the interweb for some coding relief I found Kvasir: http://kvasir.io/
It is a bit old-ish but still has some recent commits...

I like this! It is not a full solution - seems to only cover the registers and fields etc - but it's on the right track.
Does anybody know any other meta-programming libraries that make good use of the modern C++ features (and templates)?
« Last Edit: February 15, 2017, 01:40:41 pm by obiwanjacobi »
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline krho

  • Regular Contributor
  • *
  • Posts: 222
  • Country: si
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #274 on: February 15, 2017, 04:25:26 pm »
Like I said Its Os aka optimize for size.
And Like I said. I was hoping to use this IAP (except frertos this one was added just because). And was hoping this would fit into 32k.
Hell nuttx is with all that drivers and some more! is that size and it's fully fledged OS.

And I still haven't find the time to check the sizes of modules sorry other things have higher priority. Maybe I'll find some time on friday.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf