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

0 Members and 2 Guests are viewing this topic.

Offline krho

  • Regular Contributor
  • *
  • Posts: 60
  • Country: si
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #275 on: February 16, 2017, 03:25:26 AM »
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.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1415
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #276 on: February 16, 2017, 04:25:48 AM »
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: 733
  • Country: nl
  • What's this yipee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #277 on: February 16, 2017, 06:43:52 PM »
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.

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 3266
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #278 on: February 16, 2017, 06:57:26 PM »
(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: 1472
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #279 on: February 16, 2017, 07:29:00 PM »
- 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.
quadro copter flying, electronics, retro computing and other geeky things: https://www.youtube.com/user/frankbuss/
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 733
  • Country: nl
  • What's this yipee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #280 on: February 16, 2017, 07:42:58 PM »
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, 08:12:30 PM by obiwanjacobi »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1415
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #281 on: February 16, 2017, 08:54:21 PM »
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, 08:58:30 PM by janoc »
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 733
  • Country: nl
  • What's this yipee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #282 on: February 16, 2017, 09:01:58 PM »
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').

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1415
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #283 on: February 17, 2017, 02:58:28 AM »
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: 733
  • Country: nl
  • What's this yipee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #284 on: February 17, 2017, 03:21:52 AM »
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.

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1415
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #285 on: February 17, 2017, 11: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 #286 on: February 18, 2017, 03:01:58 AM »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf