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

0 Members and 1 Guest are viewing this topic.

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #275 on: February 15, 2017, 05:25:48 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)?

This is pretty neat! I haven't seen this library before.

If you are looking for C++ then there is https://github.com/andysworkshop/stm32plus
That one is pretty exhaustive, but be prepared for some C++ template voodoo.

 

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 #276 on: February 16, 2017, 07:43:52 am »
Thanx for the link. A quick look at its HD44780 (LCD) implementation reveals he didn't separate the protocol from the hardware connections. So I think my library is better  >:D

I read (and watched) more about the Kvasir library. It is gold! Perhaps I change my mind when I start working with it, but this guy knows his templates and has a good grasp of embedded programming problems (as far as I can tell) and knows how to build a public API too - in that you don't want to expose your users/devs to the hard-to-understand/learn stuff.
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #277 on: February 16, 2017, 07:57:26 am »
(as far as I can tell) and knows how to build a public API too - in that you don't want to expose your users/devs to the hard-to-understand/learn stuff.
My 18+ years of embedded programming experience tells me:
- sooner or later you encounter a problem where you do have to understand the stuff below the HAL, the "hard to understand stuff" as you call it. Read the datasheets and be done with it.
- C++ nice for larger (embedded) systems, not so nice if you have limited RAM in your system, C still rules.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #278 on: February 16, 2017, 08:29:00 am »
- C++ nice for larger (embedded) systems, not so nice if you have limited RAM in your system, C still rules.

That's wrong, a C++ program doesn't need more RAM. E.g. if you use objects, it would be the same as if you implement the same with structs in C. The only difference is that in C it is horrible to implement an object oriented system (I used to work on a system written in C, which had a macro named CLASS and other such things). But it is true that some standard C++ libraries are not optimized for embedded systems and if you use them, it might result in more RAM and ROM requirements compared to a C program which does the same, but which would require much more source code to be written by the application developer.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

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 #279 on: February 16, 2017, 08:42:58 am »
My 18+ years of embedded programming experience tells me:
- sooner or later you encounter a problem where you do have to understand the stuff below the HAL,
Perhaps, perhaps not. If so, you can always go deeper. Meanwhile, the one using a good library will be more productive earlier.
Also note that this particular library does not abstract the registers (afaics). It just makes sure you cannot do it wrong and the code generated is optimal.

the "hard to understand stuff" as you call it. Read the datasheets and be done with it.
- C++ nice for larger (embedded) systems, not so nice if you have limited RAM in your system, C still rules.
With the 'hard to understand stuff' I meant the C++ meta programming template stuff.  ;)

If you think C still rules, fine use that - and perhaps look into meta programming on the weekends.
Meanwhile I use what I think is best. I do not fancy discussing that again...
« Last Edit: February 16, 2017, 09:12:30 am by obiwanjacobi »
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #280 on: February 16, 2017, 09:54:21 am »
With the 'hard to understand stuff' I meant the C++ meta programming template stuff.  ;)

I am writing C++ for perhaps 15 years now and still find C++ templating a horrid kludge trying to plaster over the lack of proper macros in C/C++. I know how the template metaprogramming stuff works but I am avoiding that like a plague - it is the perfect way to produce "write-only" unmaintainable code, especially if you are not the only person dealing with it.

On the other hand, it still beats the half-assed generics in C# that look like C++ templates, but you can't do anything more advanced with them :(
« Last Edit: February 16, 2017, 09:58:30 am by janoc »
 

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 #281 on: February 16, 2017, 10:01:58 am »
On the other hand, it still beats the half-assed generics in C# that look like C++ templates

Templates != Generics. You cannot use your C++ template mindset and expect to understand generics...

When I first learned C I thought how on earth could someone understand this jibberish: as with anything, understanding the rules, logic and patterns behind it helps a lot.  ;D

The Kvaris library shields you from having to know or even see the template implementation (the 'hard to understand stuff').
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #282 on: February 16, 2017, 03:58:28 pm »
Templates != Generics. You cannot use your C++ template mindset and expect to understand generics...

Eh, no worries, I think I have a fairly good grasp of what the generics do and how they work. The problem is that they are so limited that many common situations cannot be done without duplicating code. Which kinda defeats the purpose. I am not speaking about any fancy metaprogramming, just completely bog standard generic code that needs to be polymorphic depending on the type passed.

For me it is one of the many stupid things in C# that are driving me up the wall (like compilation error because of a name clash if you define a variable outside of a scope and then redefine a local one inside of it -  :wtf:).

But I don't want to hijack the thread with rants on C# :)

The Kvaris library shields you from having to know or even see the template implementation (the 'hard to understand stuff').

Yes, it seems to be sensibly designed. Debugging that code could be "fun" though - as pretty much always with templates. Few if any debuggers handle them in somewhat sensible way.
 

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 #283 on: February 16, 2017, 04:21:52 pm »
Yes, it seems to be sensibly designed. Debugging that code could be "fun" though - as pretty much always with templates. Few if any debuggers handle them in somewhat sensible way.

You will not see most of it (my guess), that is the whole idea of figuring things out at compile time.
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #284 on: February 17, 2017, 12:41:38 am »
You will not see most of it (my guess), that is the whole idea of figuring things out at compile time.

Yes, of course - which is the entire problem because it is going to massively throw you off when single-stepping through code.
 

Offline WalkOver

  • Newbie
  • Posts: 1
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #285 on: February 17, 2017, 04:01:58 pm »
Hello picdev :)

Is it possible to have more info about mikroc pro ARM ?
You said it's crap but why ?

I worked a little with mikroc pro AVR and I found the IDE light but enough powerfull to me.

Im interested to have info from advanced users :)

Thank you.
 

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #286 on: May 18, 2017, 09:49:19 pm »
I am writing desktop application with java, and I came accros with this http://www.microej.com/resources/supported-platforms/
Is there any free development platform with java for stm32 ?
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #287 on: May 19, 2017, 09:39:07 am »
I am writing desktop application with java, and I came accros with this http://www.microej.com/resources/supported-platforms/
Is there any free development platform with java for stm32 ?

AFAIK, no.

I don't think I have seen Java offered for any micro whatsoever, it is just too much of a resource hog for the small chips. You may be able to get the Java SE/ME Embedded from Oracle, but that has to be licensed and I believe that works only on higher end SoCs, not microcontrollers.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #288 on: May 19, 2017, 09:50:59 am »
I've seen Java on a PIC16...  :palm:
Anyway, if you think java on an small mcu is a good idea, your software development permit should be revoked.
 
The following users thanked this post: Frank, PureBasic

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 502
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #289 on: May 19, 2017, 12:02:15 pm »
If you think using the language Java means running applications on the JVM, your software development permit should be revoked.

It's a language. It's plain-text. Anything can be made out of it. Including bare-metal firmwares for the STM32.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #290 on: May 19, 2017, 04:36:38 pm »
It's a language. It's plain-text. Anything can be made out of it. Including bare-metal firmwares for the STM32.
Really? Java? Got a link?
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 502
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #291 on: May 19, 2017, 04:41:17 pm »
picdev's link above is Java on STM32.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #292 on: May 19, 2017, 05:04:26 pm »
picdev's link above is Java on STM32.
From that very "2.0" (==information hiding) website:
Quote
MicroEJ OS Core provides a secure engine that can run multiple applications. It is based on an optimized – for performance – and compact – for footprint: down to 30 KB – Java virtual machine (JVM)
If they have something bare-metal, I was not able to find it.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 502
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #293 on: May 19, 2017, 08:11:03 pm »
Well, what do you think that is ?
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #294 on: May 19, 2017, 11:40:20 pm »
Well, what do you think that is ?
Running applications on the JVM.
So maybe my SW development permit should be revoked. Or theirs. :-//

Or I misunderstood your point:
Quote
If you think using the language Java means running applications on the JVM, your software development permit should be revoked.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline blkdev2

  • Newbie
  • Posts: 6
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #295 on: May 20, 2017, 08:23:06 am »
I am writing desktop application with java, and I came accros with this http://www.microej.com/resources/supported-platforms/
Is there any free development platform with java for stm32 ?
The .NET Micro Framework is pretty similar and appears to have a maintained port for STM32F4.

For other garbage collected OO languages take a look at MicroPython or the various JavaScript offerings. Java is just disastrously out of fashion these days, I'm afraid.

 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 502
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #296 on: May 20, 2017, 01:54:14 pm »
Yes, you misunderstood my point and misunderstood what their JVM is. It's marketed for current desktop/server developers. If your questions are serious, things are explained in http://developer.microej.com/index.php
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #297 on: May 21, 2017, 08:34:20 am »
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)
This is mostly true for me too, although I do accept the use of hardware header file, CMSIS basic headers and a third party C library (newlib.) Here is an example of what I am talking about.

Cube for me is only an interactive part selector and pin planner, occasionally a clock tree reference.

Vendor HAL is crap from my perspective (be it ASF, MCC or Harmony from Microchip or Cube from ST) so I am avoiding those as much as possible. A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.

In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #298 on: May 21, 2017, 08:47:02 pm »
A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

Any peripheral differs from vendor to vendor. So the layer above the peripheral  that handles the init and all the tweaks and quircks , flags and interrupt etc from that peripheral ,usually called the HAL is and will always be vendor specific.

Nothing is stopping you from writing a proprietary userHAL on top of the vendors HAL, but saying that all HALs from all vendors should be equal is waiting for utopia.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #299 on: May 22, 2017, 07:08:23 am »
A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

Any peripheral differs from vendor to vendor. So the layer above the peripheral  that handles the init and all the tweaks and quircks , flags and interrupt etc from that peripheral ,usually called the HAL is and will always be vendor specific.

Nothing is stopping you from writing a proprietary userHAL on top of the vendors HAL, but saying that all HALs from all vendors should be equal is waiting for utopia.
So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

In fact the sole point for me to bring up POSIX is because itself is too a HAL and have been used to abstract away platform differences on a good multitude of hardware platforms: the same POSIX API works on things from PC (Linux) to Mac (macOS) to embedded systems (uCLinux) to smartphones (iOS) to game consoles (OrbisOS.) What I am trying to say here is maybe we can try make some parts of POSIX API work on STM32 without an operating system kernel.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf