From reading this it's clear (to me anyway) that their library quality will not improve until different people are involved in writing it, or managing the team, or more likely both. All the "process" in the world cannot fix misguided design, and the quality problems go far beyond fixing a list of bugs. You could make that code work perfectly and it would still be horrible. From this statement you can tell that he (probably a he) does not understand the real deficiencies: unhandled and pointless complexity and opacity.
This is not really an ST problem, though; the same could be said for most vendor-supplied library code. Smart people with good code hygiene practices are a prerequisite for improvement, one which AFAICT is rarely if ever met. Until that changes, expect more of the same.
"incomplete validation coverage …"
As to Low Layer.... I have no idea what this means. Are they replacing sections of CubeMx/Hal? Are they dividing up into two sections where Low Layer will be chip specific containing the have the defines and base code, and the HAL will apply the more complex peripheral handling to all devices equally as it's trying to do now?
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.
This is not really an ST problem, though; the same could be said for most vendor-supplied library code.
This shows one of the reasons I don't like these portability / abstraction layers (not just for MCUs but in lots of other situations). It always seems like you run into a roadblock where the abstraction layer either won't let you use a particular feature of a particular device, or makes it really inefficient. Almost always, it's better to write code for the specific device(s) that you will use, and just try to keep the platform-dependent code to a minimum.
maybe there is a calculated reason that in terms of an OE who has to support every conceivable project out there and handle the tech support for anything they release
I can't seem to find it on their site. Could you give a hand as to where you found this ?
According to ST's web page the Low Layer API can be used either with or instead of the HAL:
Why all the complaints. No one forces you to use it. You can use it as a reference to build your own or expand it for your own products.
https://www.eevblog.com/forum/microcontrollers/st%27s-%28stm32cube%29-software-ecosystem-is-terrible-how-can-we-fix-it/
I think it is better there are libraries provided than nothing at all like in the old days where hardware manufacturers
did not give a damn. We have tens of products in the market using the STM32 HAL without problems, well not many problems
Yeah we all would like utopia, perfect bug free hardware, every year updated ARM cores (instead of the 4 yr old versions)
and perfect bug free drivers and all we need to do is write the main(). Wake up.
Honestly I did try to reason with them, but didn't seem to get a lot of traction, at this point it's all going to have to collapse under it's own weight. Someone there is going to have to have some sort of epiphany, as the way things are going it's just going to get more unmaintainable. I'm going to join the Jan on the Dark Side, and tinker at the register level.
The Low Level drivers are so far only in the CubeL4 package http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908 "Uses CodeSonar", apparently.
Why all the complaints. No one forces you to use it. You can use it as a reference to build your own or expand it for your own products.
I think it is better there are libraries provided than nothing at all like in the old days where hardware manufacturers did not give a damn.
We have tens of products in the market using the STM32 HAL without problems, well not many problems
So yes it is 2015 and we really really deserves utopia, its about time!
This is what guru Clive 1 says about it all and Kjelt and you better listen to guru Jan and guru Clive!
Why all the complaints. No one forces you to use it. You can use it as a reference to build your own or expand it for your own products.
I think it is better there are libraries provided than nothing at all like in the old days where hardware manufacturers did not give a damn.
I'm surprised that libopencm3 hasn't been mentioned yet. I think the best thing ST could do is to contribute to the project
I'm surprised that libopencm3 hasn't been mentioned yet. I think the best thing ST could do is to contribute to the project
I'm surprised that libopencm3 hasn't been mentioned yet. I think the best thing ST could do is to contribute to the project
What about mbed? ST contribute to that, as do several other ARM vendors. The online compiler is a PITA, but you can build offline with several different IDEs.
folks like me who tinker with writing/editing code on when we have to, and whose core competency is in other fields; libraries are god-send. I would be very interested to know what kind of validation they have done on their HAL libraries.
If I recall mbed uses an Apache licence rather than LGPL.
GPIOA->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER5_1;
GPIOA->MODER |= GPIO_MODER_MODER5_AF;
One is trying to build something that is useful in their perspective, others are not used to that way of thinking and reject anything they do not know and/or understand. Having a questionable track record does not help. Having non-domain-experts do the programming does not help either.
1. OEM HALs suck universally.
2. MCU datasheets suck (a lot) less, so don't be afraid to study peripheral registers and bang them directly.
One is trying to build something that is useful in their perspective, others are not used to that way of thinking and reject anything they do not know and/or understand. Having a questionable track record does not help. Having non-domain-experts do the programming does not help either.
Let me be the first to say this criticism has little to do with users not understanding.
These criticisms of ST's library are not coming from a place of ignorance, or unfamiliarity or unwillingness to use abstractions. They are coming from a place of wanting to work at an abstracted level, being offered a library that makes promises and then fails to deliver. Every. Single. Time.
The ST HAL is just crap. Most of the functions it provides are nothing more than dumb wrappers around the register pokes. Usually, you have to fill a large struct full of members whose names are suspiciously similar to the registers they relate to, then you pass the struct to some mysterious function, which pokes the real registers with the values from the struct you filled out. What has that bought me? Is there some kind of error checking? No. Does the function make sure my choices are consistent with each other? No. Does the function wrap any checking for preconditions necessary for the peripheral to work, like the clocks being enabled or DMA being set up in advance? No. Is the setup for the function very simple for the most /common/ uses? Not usually. Does a return code help me understand why the peripheral is not behaving as expected? No. Finally, does this library allow me to get by without knowing the details of how that part actually works? That is, can I read the documentation for the *library* and *NOT* read the documentation for the part and expect to get by with that? This is the real test of an abstraction, and the answer is invariably no, too. Because when things don't go as you expected, you have to dig into those registers yourself to figure out what's what.
Resources are tight in embedded systems, but not as tight as they once were, and I think most embedded folks would be happy to pay the size and performance overhead of libraries IF they made their lives easier. And of course, in cases, where size and performance were critical, they would do the LL stuff themselves. But these libraries just don't make life much easier.
Which manufacturer comes closest to this today ?
QuoteWhich manufacturer comes closest to this today ?Arduino? Although, for such a small and limited subset of the typical capabilities of a microcontroller, and usually at such a performance hit, that professionals don't like it very much.
The whole "pin number" abstraction is brilliant, especially for beginners. And also terribly limiting :-(
But that's the "big thing" - most of the reset is "adequate" libraries for basic functionality, without flexibility.
Try to change the CPU clock, it probably doesn't work.
Add pullup and pulldown configurations and you're stuck in a mire of "how the AVR happened to do it is now a standard."