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

0 Members and 1 Guest are viewing this topic.

Offline nazcalines

  • Contributor
  • Posts: 24
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #25 on: March 08, 2015, 04:46:50 am »
Quote
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...

I just switched from atmel to st... My background is in AVRs with WinAVR and then the Atmel Cortex M3 chips with Atmel Studio.  I find st's standard peripheral library to be quite good and there are loads of examples online (people's personal blogs, my.st.com).  I have not tried STM32Cube and hopefully will never need to.  The community around Atmel ARM is way behind, imo.  I also much prefer a minimal dev setup to Atmel's sluggish Studio IDE.  I've never used Arduino (AVR or ARM versions), so those might be better supported.

When I was researching ARM chips I went with Atmel because I was used to their documentation and thought it would be nice to not put any work into the tool chain.  It turns out I really dislike Atmel Studio (I run it in a VM, and it is soooo slow).  My only regret is that I didn't switch to st sooner.

There are also some minor details with stm32 I prefer, for example, the DAC outputs swings full range vs Atmel's and the power supply setup is simplified.
 

Offline Frank

  • Contributor
  • Posts: 15
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #26 on: March 08, 2015, 07:34:19 am »
Code: [Select]
__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}
Quote
I had to trawl through the whole project fixing them.

How did you "fix" it then? :)

I have the same doubt :)

Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

In fact, the old way that the library did the delay was wrong:

Code: [Select]
void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t timingdelay;
   
  timingdelay = HAL_GetTick() + Delay;
  while(HAL_GetTick() < timingdelay)
  {
  }
}
 

Offline NF6X

  • Supporter
  • ****
  • Posts: 195
  • Country: us
    • Mark's Green Pages
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #27 on: March 08, 2015, 08:30:14 am »
I view STM32FCube is more of a pile of evaluation code than something I'd expect to use as-is for serious projects. I've recently started a quick hack of a project using an STM32F051, and I've been using the STM32FCube stuff for it so far. It's not anything I'll be very proud of when it's done, and I don't think I'd use the HAL code as anything more than example code if my project was more demanding and/or I was getting paid to do it. :)

It wasn't easy, but I actually got STM32CubeMX working on my Mac along with a free open source toolchain. ST doesn't appear to advertise support for any platforms but Windows, but both the STM32FCubeMX installer are Java apps that can be run on the Mac by installing Java (don't forget to de-select the "Install Spyware Toolbarz!" option) and renaming the installer and the app it installs from *.exe to *.jar.

I'm using the toolchain provided by the arm-none-eabi-binutils and arm-none-eabi-gcc packages from MacPorts. The arm-none-eabi-gdb port is presently broken, but there's an unofficial patch to make it build. I've patched/installed it, but so far I've found it easier to debug with a couple of LEDs than to re-learn how to use gdb. It's rumored to be possible to get everything working under Eclipse, but I'm not especially fond of Eclipse so I haven't tried.

STM32CubeMX spit out an empty linker script for my project. Maybe it's because none of the toolchains it understands are installed, or maybe it's just buggy. I wrote my own linker script. I also found that the "only spit out referenced files" option prevented it from spitting out startup code. The combination of ST's startup code and gcc's libc resulted in an undefined reference to _init() which can be fixed by manually cramming an empty _init() function into the project code. I also had to write a Makefile for my project. I'm using texane's stlink utilities for flashing.

I spent many hours trying to figure out why the DAC wasn't working, only to figure that I needed to include another HAL code file to get the actual DAC support code, rather than just __weak stubs to the needed functions that prevented the linker from helpfully telling me that I was linking against thin air.  |O

Now I'm wrestling with keeping the DAC from jumping to the negative rail at the end of each prerecorded sound sample that my application needs to periodically spit out. I haven't figured out yet whether it's buggy HAL code, a limitation of how the DAC works in DMA mode, or PEBCAK. My application is un-demanding enough that I may just avoid the issue by pushing out single-sample conversions in a timer interrupt handler rather than using DMA.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #28 on: March 08, 2015, 09:39:56 am »
Only way to fix it is to give negative feedback on their forums and customer service so they might spnt more effort making something usefull.
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #29 on: March 08, 2015, 10:16:44 am »
Cube and HAL drivers are simply rubbish ... the only thing i find useful in cube is pin assignment for my application it save time when choosing peripheral pin and alternative function ... the code that generate is trash.

for the i2c, i experienced that busy bit problem days ago and simply my initialisation was wrong.
for the i2c in f4 it's totally fine , the f1 may cause problem , i used the f1 with ic eeprom no problem at all but true f1 may have a hardware problem, the source : a guy working for st.

you can't fix it , just use the standard library.

The example that you find with ST library may help , but the negative point about them is that all the example are linked together and linked to a hardware of a specific evaluation board , so you can't really open files for i2c example and read a stand alone application there is always some undefined word that you have to look for in others files ... really pain in the ass.

usually example given by forums like stm32f4-discovery.com are better and code work out of the box.

 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #30 on: March 08, 2015, 10:24:35 am »
Quote
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.

No they arent, F4 uses same I2C peripheral as F1 does. So does L1 and L4 I think.

I'd suggest to use ST CPAL library for I2C, instead of trying to write anything from scratch. You can't cover all the shit happening in that poor peripheral so CPAL was done for you to solve almost all problems with I2C exclusively. (but I admit the CPAL lib is pissfully complicated to understand and use aswell)

Simply there is no solution for the  crippled peripheral. You must be lucky if it works.
« Last Edit: April 24, 2015, 08:16:00 pm by Yansi »
 

Offline Narmaraktuk

  • Contributor
  • Posts: 20
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #31 on: March 08, 2015, 11:11:35 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?

Agreed in full. Cube is handy to look at pin assignments, and doing a java -jar STMCube.exe is a quaint way to support linux/mac users.

As to how can we fix it; my take is to walk away from ST's libs, and only use their hardware. I like libopencm3 a lot, this is a minimal open source library to get at the peripherals. Functions make sense, source can be quickly looked at (what register is tweaked why). A new project is only a Makefile, a stm32fx.ld depending on backend and a
Code: [Select]
git submodule add https://github.com/libopencm3/libopencm3.git away.

libopencm3 has "support" for efm32, lm3s, lm4f, lpc13xx, lpc17xx, lpc43xx, sam, stm32, vf6xx. I have not looked at others than stm32 at this point, but it is nice to know that other ppl are working on this. Naturally this library is not made by the manufacturers, and though I have not found any missing so far for stm, that might not hold for all backends.
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #32 on: March 08, 2015, 11:16:21 am »
I wouldn't trust any thirdparty multi-vendor library. That smell like a big trouble.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #33 on: March 08, 2015, 11:29:59 am »
Quote
Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

Absolutely correct.

That piece was specifically coded to avoid the roll-over. Many people use it without understanding that, and many people criticize it without understand it either.

Anyway, I am quite interested in the supposedly superior "fix".
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #34 on: March 08, 2015, 11:37:35 am »
Quote
Only way to fix it is to give negative feedback on their forums and customer service so they might spnt more effort making something usefull.

Or don't use their products at all -> that is the only one that ST (or any other company) cares about.
================================
https://dannyelectronics.wordpress.com/
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #35 on: March 08, 2015, 08:33:35 pm »
Quote
Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

Absolutely correct.

That piece was specifically coded to avoid the roll-over. Many people use it without understanding that, and many people criticize it without understand it either.

Anyway, I am quite interested in the supposedly superior "fix".

Ah, my bad. I mistook the good version for the faulty one  :-[

That will teach me to read more carefully...!
Bob
"All you said is just a bunch of opinions."
 

Offline Dago

  • Frequent Contributor
  • **
  • Posts: 659
  • Country: fi
    • Electronics blog about whatever I happen to build!
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #36 on: March 09, 2015, 07:12:46 am »
I agree with the OP. I haven't actually used the cube stuff specifically but just the ST headers (not sure how closely they are related) and they are just an inconsistent mess. Seemed like something made by a summer worker or something.

I wrote my own headers from scratch (made to resemble more recent Atmel headers like for the xmega series which are very well made) but I can't say that was a good solution either. You need to implement so much stuff. It also felt like the actual hardware is poorly designed, they have not thought about how the user will use the hardware and how you could design the hardware so that implementing code that would be easily modifiable or portable would be easy to make.

Good example were the comparators in the part I used, there was like 8 different comparators which had exactly one configuration register each. The only difference between those was which signals you could route to the comparators and which signals you could route out. So the logical solution would be to have identical configuration registers for all of them and then some (identical) routing blocks (with their own configuration) for the inputs and outputs and the connections could be easily be expressed as some kind of a chart on the datasheet? But nope, STs solution was to make 8 different configuration registers that are enough inconsistent between eachother that you just have to rewrite them for each of the comparators. And this was one of the smaller problems... Also all of the pins are laid out in the package like almost 100% randomly. Absolutely no sense in the way the pins are laid out. Parallel buses where like... none of the bits are adjacent to eachother etc.

I guess the problem is that there is no competition. At least I am not aware of any ARM-families that would be considerably better (in hardware design and in software side).
Come and check my projects at http://www.dgkelectronics.com ! I also tweet as https://twitter.com/DGKelectronics
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #37 on: March 09, 2015, 07:59:44 am »
I guess the problem is that there is no competition.
No in contrary to what many here think the core business of ST is silicon design, manufacturing and selling. Not writing support software for their silicon.
You can stand to differ and discuss the need to have supporting software but lets face it the businesses that buy a million STM32 a quarter from them write their own software anyway. They also have their private lifelines directly in the ST company to sort out problems (been there done that  ;) )
Only thing of ST what I do not understand is that they sell these incredible cheap discovery boards thereby attracting the hobbieist community while not being able to properly support that community. That I really do not understand, perhaps a futile attempt by some rookie product manager too sell even more without thinking.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #38 on: March 09, 2015, 08:03:03 am »
It just makes trying an ST device a no-brainer. I can order a £10 board without a moment's hesitation, but, say, a £100 board needs justification.

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #39 on: March 09, 2015, 08:18:12 am »
It just makes trying an ST device a no-brainer. I can order a £10 board without a moment's hesitation, but, say, a £100 board needs justification.
Oh from the buyers point of view I get it. But from ST point of view, they don't make money on their discovery boards. And they don't have the newbie easy starter software suite to accompany it. So  :-//
 

Offline Towger

  • Super Contributor
  • ***
  • Posts: 1645
  • Country: ie
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #40 on: March 09, 2015, 08:37:45 am »
And that newbie starter in ten years time becomes the designer of the million units a quarter product.  But the now designer does not use ST chips due to their previous experience with them.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #41 on: March 09, 2015, 08:43:39 am »
And that newbie starter in ten years time becomes the designer of the million units a quarter product.
Yeah but the newbie has gotten a real rotten startup experience with the ST chips so decided to switch to another manufacturer so the million parts will be for some other company  ;)
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #42 on: March 09, 2015, 08:47:05 am »
I DO use ST parts (commercially) because of my previous experience with them. The fact that the Discovery boards are cheap and readily available is a nice bonus.

In terms of development tools, CrossWorks for ARM is just US$150 for a hobby licence, so you can hardly complain that there are no inexpensive options available. Even the commercial licence is, at $1500, a great deal less than most alternatives.

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #43 on: March 09, 2015, 08:49:44 am »
You loose 90% of your target audience if the $10 board needs a $150 hobby license toolsuite  ;)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #44 on: March 09, 2015, 11:34:35 am »
-I guess the problem is that there is no competition. At least I am not aware of any ARM-families that would be considerably better (in hardware design and in software side).-

The -mass produced high end- vendors would be freescale and ti.

I don't quite understand your problem - if you specify the part it may help. In general setting up the project in most IDE is fairly easy and largely consistent. Tedious it is.

So part of the difficulty people encountered on those parts is user driven.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #45 on: March 09, 2015, 11:39:15 am »
And other times it's fad. A couple years ago, our experts here didn't know the i2c issues on some st parts. Now everyone has issues with st i2c modules, even on those st parts that don't exhibit i2c issues.
================================
https://dannyelectronics.wordpress.com/
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #46 on: March 09, 2015, 12:06:28 pm »
I have the same doubt :)

Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

In fact, the old way that the library did the delay was wrong:
You are right, I quoted the new code without thinking, because it is tricky to see that the new code is correct for any C compiler, because overflows are undefined with signed integers, but defined for unsigned integers, as described here. Good to see that they fixed it.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline NF6X

  • Supporter
  • ****
  • Posts: 195
  • Country: us
    • Mark's Green Pages
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #47 on: March 09, 2015, 02:15:29 pm »
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.  ::)
 

Offline Lukas

  • Frequent Contributor
  • **
  • Posts: 412
  • Country: de
    • carrotIndustries.net
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #48 on: March 09, 2015, 04:56:32 pm »
I guess ST autogenerates the register definition header files from the SVD XML document. SVD is a part of CMSIS describing which there are in a device. A while back I wrote a small application that parses the SVD and allows you to do point-and-klick register manipulation by connecting to openocd. When I find some time, I'll clean it up and put it on github.

SVD allows to specify enumerated values for bitfields. Unfortunately ST completely missed that one, so you've got to look up in the datasheet which value you've got to write in the bitfield. Atmel got it right...

Just to give you an idea how SVD looks like:

Code: [Select]
<register>
          <name>CMR1</name>
          <description>Channel Mode Register (channel = 1)</description>
          <addressOffset>0x00000044</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0x00000000</resetValue>
          <fields>
            <field>
              <name>TCCLKS</name>
              <description>Clock Selection</description>
              <bitOffset>0</bitOffset>
              <bitWidth>3</bitWidth>
              <access>read-write</access>
              <enumeratedValues>
                <enumeratedValue>
                  <name>TIMER_CLOCK1</name>
                  <description>Clock selected: TCLK1</description>
                  <value>0x0</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>TIMER_CLOCK2</name>
                  <description>Clock selected: TCLK2</description>
                  <value>0x1</value>
                </enumeratedValue>
 

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 #49 on: March 09, 2015, 05:11:24 pm »
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)

I love the smell of FR4 in the morning!
 
The following users thanked this post: technix, PureBasic


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf