Author Topic: ST official anouncment of new low level API  (Read 13299 times)

0 Members and 1 Guest are viewing this topic.

Online MT

  • Frequent Contributor
  • **
  • Posts: 856
  • Country: fo
ST official anouncment of new low level API
« on: September 18, 2015, 12:52:49 am »
As mentioned earlier is now official by ST , whether it will be yet another ST software/documentation disaster is still yet to bee seen
after all it is still HAL and Cube, i quote from STM32 forum:


First, we apologize for this bug you are encountering. It will be fixed in next STM32CubeL1 V1.4.0 release planned e/o October.

As you may know it’s quite challenging to have bug free software, there are always few bugs not detected through the validation process. The root cause can be; the process is not followed as it should be, incomplete validation coverage …

However from ST we are engaged to reduce the number of bugs over time to reach this challenging bug free software. We are ensuring as well a regular maintenance of the different FW packages; either patch release to fix critical bugs, or full release to implement all the feedback we receive from our customers.

I will take this opportunity to share w/ you that we are introducing a new set of APIs, called Low Layer (LL), allowing performance and memory footprint optimization with register access level programming.

These LL APIs will be 1st introduced w/ STM32CubeL4 V1.1.0 to be available on ST web next week, deployment on all STM32 Series is ongoing with releases planned during 2016.
« Last Edit: September 18, 2015, 02:48:07 am by MT »
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 400
  • Country: us
Re: ST official anouncment of new low level API
« Reply #1 on: September 18, 2015, 01:45:42 am »
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.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 434
Re: ST official anouncment of new low level API
« Reply #2 on: September 18, 2015, 02:19:19 am »
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.

I sort of read this as "everyone out there is crazy.... except me"   ... It's computer science / engineering. Ask 10 people's opinions and you'll get 18 answers back. There just is no one way to do anything.

If you see everyone having similar issues to ST, 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 - that they're not just stupid, but maybe have an idea of what will and won't work for them.

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?

It seems odd to me that they get moving on HAL and change it up right away, but at least they're still working on it and haven't just tossed their hands in the air like some other suppliers (ehm, microchip).
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 3810
  • Country: nl
Re: ST official anouncment of new low level API
« Reply #3 on: September 18, 2015, 03:32:41 am »
"incomplete validation coverage …"

LOL, there is someone there that thinks you can ever have anything but.
 

Online MT

  • Frequent Contributor
  • **
  • Posts: 856
  • Country: fo
Re: ST official anouncment of new low level API
« Reply #4 on: September 18, 2015, 03:44:29 am »
Hooray! more fragmentation!

I just discovered that the latest F429 SPL lib dont compile! All i did was swapping the 2011 SPL for 2015! And that was the lib's alone!
And i don't even use SPL or HAL. I must be a complete fool! :o

I cant directly migrate a 103 project because ST have changed the 429 register definition names for a vast number of peripherals in the
2011 definition file! :scared:
« Last Edit: September 18, 2015, 03:50:22 am by MT »
 

Offline Len

  • Frequent Contributor
  • **
  • Posts: 515
  • Country: ca
Re: ST official anouncment of new low level API
« Reply #5 on: September 18, 2015, 03:48:46 am »
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?

According to ST's web page the Low Layer API can be used either with or instead of the HAL:
Quote
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 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.
« Last Edit: September 18, 2015, 09:18:50 am by Len »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15434
  • Country: nl
    • NCT Developments
Re: ST official anouncment of new low level API
« Reply #6 on: September 18, 2015, 06:06:13 am »
This is not really an ST problem, though; the same could be said for most vendor-supplied library code.
I always use vendor supplied code as an example for writing my own driver. The vendor provided code is usually buggy (demontrator level) and/or way too complicated (bloated) for what I want.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 1460
  • Country: us
Re: ST official anouncment of new low level API
« Reply #7 on: September 18, 2015, 06:47:31 am »
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.

This was exactly my experience with Atmel's ASF.  Want to shovel bytes between buffers and a UART?  No problem!  Oh, you need to do break detection?  Time to throw away the API and start poking registers.

Furthermore, the SAM parts have at least three different peripherals that can do asynch serial (SERCOMs, UARTs, and USARTs, and the latter two often appear together on the same chip), so you'd think they'd at least provide a consistent interface for all three, right?  Nope, each has its own set of API functions and configuration structs, so even with all of that abstraction you're STILL stuck manually porting between peripherals.

Really I think it would be best for everyone if the manufacturers just provided a simple, consistent, and WELL DOCUMENTED set of header files and maybe some useful helper functions for the simpler peripherals and focused their development efforts on providing solid easy-to-use stacks for the more complex things like USB and IP and so forth.  Hopefully what ST is working on now is more along those lines.  I've got my eye on one of their parts for a particular project coming up, so it would be nice to see a sane and actually useful API for it.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15434
  • Country: nl
    • NCT Developments
Re: ST official anouncment of new low level API
« Reply #8 on: September 18, 2015, 07:51:29 am »
For USB or IP you are better off looking at LUFA or Lwip. NXP for example forked LUFA to serve as their generic USB device/OTG/host stack.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online MT

  • Frequent Contributor
  • **
  • Posts: 856
  • Country: fo
Re: ST official anouncment of new low level API
« Reply #9 on: September 18, 2015, 09:47:10 am »
ST have now let the low level abstraction monster out of its cage!
It seams to be a complete dissaster, 200Mbyte zip, macro,static inline functions , yet another run of renamed register accesses. :scared: :palm:
« Last Edit: September 18, 2015, 10:02:31 am by MT »
 

Offline Ribster

  • Regular Contributor
  • *
  • Posts: 148
  • Country: be
  • Electronics enthousiast. Mostly on STM32
    • Robbe's Workshop
Re: ST official anouncment of new low level API
« Reply #10 on: September 18, 2015, 05:19:23 pm »
I can't seem to find it on their site. Could you give a hand as to where you found this ?
Veni Vidi Vagina - Ik kwam, en zag dat het kut was.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2709
  • Country: us
Re: ST official anouncment of new low level API
« Reply #11 on: September 18, 2015, 08:06:42 pm »
Quote
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
Oh sure; you can usually see the motivations: Support all features, no compiler dependencies, meets XXYZ coding standards, "object oriented", "abstracted API", common APIs for different chips, "doesn't depend on current device state", etc.   Most of them even sound pretty reasonable.   But by the time you combine them all together, with a few less-than-brilliant decisions thrown in, you wind up with something so bloated and difficult to document that no one wants to use it.

As an example, someone mentioned "break detection" on a UART.  I can see it now: SW buffer width increased to 16 bits so it can hold status bits as well as data! BREAK, parity, framing err, overrun, and shucks, it will hold the 9bit data some UARTs can support too!   that'll be great!  It's good for them, too; most uart drivers are really poor at error detection, which is bad programming practice!
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 4988
  • Country: nl
Re: ST official anouncment of new low level API
« Reply #12 on: September 18, 2015, 08:47:47 pm »
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  :D
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.
 

Offline bigdawg

  • Regular Contributor
  • *
  • Posts: 98
  • Country: us
Re: ST official anouncment of new low level API
« Reply #13 on: September 18, 2015, 11:07:14 pm »
I can't seem to find it on their site. Could you give a hand as to where you found this ?

same here. I would've thought that ST will put the links out more prominently since this is something many people might find useful. I have just switched to ST from atmel and NXP, and I already hate working with HAL to port my existing code.
 

Offline bigdawg

  • Regular Contributor
  • *
  • Posts: 98
  • Country: us
Re: ST official anouncment of new low level API
« Reply #14 on: September 18, 2015, 11:14:28 pm »

According to ST's web page the Low Layer API can be used either with or instead of the HAL:


This is something I would be very curious about. If I can use HAL along with a low layer API without running into any major bugs than that's a definite plus. for whatever reason, I feel like that might just be wishful thinking on my part, and doing it will be a major PITA.
 

Online MT

  • Frequent Contributor
  • **
  • Posts: 856
  • Country: fo
Re: ST official anouncment of new low level API
« Reply #15 on: September 18, 2015, 11:43:15 pm »
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.
You dont see westfw and other peoples  hard earned points? Comming here and complain about complaints!!
This thread is about complaining ST forcing people use their crap...yees even their definition files is crap which we is forced to use!  >:D
Quote
http://www.eevblog.com/forum/microcontrollers/st%27s-%28stm32cube%29-software-ecosystem-is-terrible-how-can-we-fix-it/
Quote
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  :D
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.
See, you aswered your own allegation, a sign of a lazy coder who is scared to poke around in registers
and actually learn underlying hardware instead want everything served on a silver plate and spoon feed!
So yes it is 2015 and we really really deserves utopia, its about time!

This is what guru Clive 1 says about it all Kjelt, and you better listen to guru Jan and guru Clive!

Quote
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.

Time to wake up from your fairygreen dream Kjelt and join us on the dark side!

(PS: im not angry or so, it's just self entertaintment, mostly i just sit and laught).. ;)
« Last Edit: September 20, 2015, 07:24:47 am by MT »
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 746
  • Country: gb
  • Embedded stuff
Re: ST official anouncment of new low level API
« Reply #16 on: September 19, 2015, 12:20:49 am »
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.
Bob
"All you said is just a bunch of opinions."
 

Offline bigdawg

  • Regular Contributor
  • *
  • Posts: 98
  • Country: us
Re: ST official anouncment of new low level API
« Reply #17 on: September 19, 2015, 01:26:33 am »
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.

I suspected that but thanks for the clarification. I was looking for low level drivers for STM32F4 and STM32F7 but I couldnt find anything new listed on their respective cube pages.
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 400
  • Country: us
Re: ST official anouncment of new low level API
« Reply #18 on: September 19, 2015, 01:29:17 am »
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  :D

It's nice to know the vendor libraries are useful for some.  I guess part of the complaining is a perfectionistic streak a lot of us have, an instinctive dislike of obviously sub-par solutions, when we know they could have been so much better, and probably with less effort on the vendor's part at that.

I guess if they want to waste their time on code which is so widely reviled (based on my informal poll of working embedded devs), I should not mind, except that there are other support areas just crying out for attention:  quality documentation, for example.  If you assess the quality of writing and clarity of exposition in any MCU reference manual today, and compare it with one from 20 years ago, it is shocking.  I find myself trying to parse sentences which are barely English on a regular basis now.  Terribly frustrating.  Just yesterday, in fact, I was trying to educate myself on a new STM32 peripheral, the DFSDM (digital filter for sigma-delta modulation), but the bad writing seriously hinders comprehension.
 

Offline bigdawg

  • Regular Contributor
  • *
  • Posts: 98
  • Country: us
Re: ST official anouncment of new low level API
« Reply #19 on: September 19, 2015, 01:36:51 am »

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!


I have to agree with the sentiments expressed by MT here. Sure, one can throw away the libraries and do everything from scratch but is that a good use of our time ? I am sure some of you guys on this forum have tons of experience and knowledge to avoid libraries completely and still write your code in a timely fashion but for other 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. My beef with STM is not that they dont provide libraries to do everything (thats impossible!); but they provide libraries to do a lot of things, and that none of those seem to work exactly as they have described, leading to countless hours being wasted trying to troubleshoot.

I would be very interested to know what kind of validation they have done on their HAL libraries.

Another thing which annoys me about their forums is there is one guy (clive1) who provides vast majority of useful answers and the ST employees seem to barely pull their weights. I am sorry, but this is quite contrary to what I have seen elsewhere. Ofcourse, I like the ST hardware, thats why I am going through all the trouble of making it work!
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 1460
  • Country: us
Re: ST official anouncment of new low level API
« Reply #20 on: September 19, 2015, 01:54:09 am »
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.

Sure, but when you have to dig through fifteen layers of abstraction to figure out what the library is actually doing at the hardware level, it's not a terribly great reference, especially if the only "documentation" for it is useless doxygen boilerplate.  Couple that with some of the really disappointing datasheets/reference guides that are out there and you do not have a good recipe for understanding.  A better reference would be some application examples showing the required register accesses with explanations of how and why the peripherals are configured for a given application.  This also gives you an immediate idea of what registers should have what values at each point in the program, which makes debugging vastly easier.  You could even wrap them up into a nice set of library functions without trying to abstract all sense out of the code and have something that is more compact, easier to understand, and takes less work for the manufacturers to produce, validate, and maintain.  From the user side, if your application fits into one of the boxes that the library's writers anticipated, then you can use it as is with no problem, just as some do now with the higher level libs--but if you need to alter or extend the library (or even start over from scratch), you'll have a much easier time of it with a low level library than a huge and endlessly abstracted library. 
« Last Edit: September 19, 2015, 01:56:10 am by ajb »
 

Offline Tainer

  • Contributor
  • Posts: 37
  • Country: 00
Re: ST official anouncment of new low level API
« Reply #21 on: September 19, 2015, 10:07:18 pm »
I'm surprised that libopencm3 hasn't been mentioned yet. I think the best thing ST could do is to contribute to the project :)
 

Offline ntfreak

  • Contributor
  • Posts: 12
  • Country: gb
Re: ST official anouncment of new low level API
« Reply #22 on: September 19, 2015, 10:31:23 pm »
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 would imagine the LGPL licence is not helping libopencm3 with vendors or any commercial use.
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 746
  • Country: gb
  • Embedded stuff
Re: ST official anouncment of new low level API
« Reply #23 on: September 19, 2015, 11:23:32 pm »
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.
Bob
"All you said is just a bunch of opinions."
 

Offline ntfreak

  • Contributor
  • Posts: 12
  • Country: gb
Re: ST official anouncment of new low level API
« Reply #24 on: September 19, 2015, 11:54:40 pm »
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.
If I recall mbed uses an Apache licence rather than LGPL.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf