EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: MT on September 17, 2015, 02:52:49 pm
-
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.
-
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.
-
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).
-
"incomplete validation coverage …"
LOL, there is someone there that thinks you can ever have anything but.
-
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:
-
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 (http://www.st.com/web/catalog/tools/FM146/CL2167/SC2004/PF261908) the Low Layer API can be used either with or instead of the HAL:
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.
-
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.
-
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.
-
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.
-
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:
-
I can't seem to find it on their site. Could you give a hand as to where you found this ?
-
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!
-
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.
-
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.
-
According to ST's web page (http://www.st.com/web/catalog/tools/FM146/CL2167/SC2004/PF261908) 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.
-
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
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 :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!
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).. ;)
-
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 (http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908) "Uses CodeSonar", apparently.
-
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 (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.
-
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.
-
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!
-
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.
-
I'm surprised that libopencm3 (http://libopencm3.org/wiki/Main_Page) hasn't been mentioned yet. I think the best thing ST could do is to contribute to the project :)
-
I'm surprised that libopencm3 (http://libopencm3.org/wiki/Main_Page) 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.
-
I'm surprised that libopencm3 (http://libopencm3.org/wiki/Main_Page) 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.
-
I'm surprised that libopencm3 (http://libopencm3.org/wiki/Main_Page) 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.
-
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.
I dont se the point of this abstraction madness where a lib user has to do a call to a library just to wiggle a pin! Or abstracting
to death utterly simple things like systick who barely needs 3 register writes to be initialized, setup, and enabled and at the
same time they completely destroyed portability of code between devices by splitting up the systick definitions onto 3 different
files for one family of devices while for other devices continue to have systick neatly described in one file it is suposed to be
namely the definition file. And that for a function that is part of the ARM package and not ST. Same goes for NVIC but im not
100% sure on that one.(disclaimer if im all wrong).
Btw, systick is faster then NVIC because you have automatic reset of isr flag! ;)
I dont mind one thick definition file nor many smal ones as long as they are written well. Im not against libraries or abstraction
per see, it's the way STM creating and managing the whole gorilla i'm against! What's worst of all ST is loosing money
by doing all those convoluted abstraction layers, and they don't realizing it , they believe they are "hipp" and modern
and trendy! As Clive described just imagine all the people needed to wrestle with this gorilla that now weights
200mega tonnes and in 5 years time when even more devices is added will weight 800Mtonnes +!
Everything boils down to bad management!
However there is one very god thing about this 200megaton abstracted low level gorilla. As it grows STM have to put on larger Flash and SRAM memories on the devices to compensate for the ever expanding bloat it creates. Something we on the dark side is quite pleased about! So yes, i have changed my mind, this new lib is actually great! Hohumm!
-
If I recall mbed uses an Apache licence rather than LGPL.
Most of the mbed client side stuff is Apache, although there are some proprietary drivers. Mbed have been and still are quite fuzzy when it comes to what "Open Source" means. The idea with mbed now seems to be they give the mbed IoT client side, "free", and will charge for use of IoT server side software.
What is puzzling though is the restrictive licenses vendors use, e.g. ST's laughably entitled "ST Liberty License" - "must not use with other manufacturer's devices". When queried, ST rep said this was because "they get a lot of counterfeits". However, when it comes to mbed, they seem to happy to give essentially the same thing under very permissive license.
Of course, the Holy Grail of an API which is efficiently implemented over a wide range of devices will never happen, regardless of licensing or commercial interest. There will always be a compromise between efficiency and portability.
In my experience, hardware vendors are always lousy at providing software. I would prefer vendors to get the silicon right first, then provide a basic set of register definitions and low level functions. Let customers and third parties who know what they are doing provide software solutions.
-
Instead of churning out yet another API of questionable quality and usefulness, they could revamp their header/SVD files to include register field enumerations.
So instead of writing
GPIOA->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER5_1;
I'd be able to write
GPIOA->MODER |= GPIO_MODER_MODER5_AF;
Shouldn't be rocket science for ST do do that...
-
I think this is no rocket sience for you either. Just put a days work into it and you have what you need...
-
Im not familiar with ST tools or frameworks but what I read is common to all software development, me think.
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.
Then there is (especially in IT software development) the hype-factor and the accompanying roller coaster. (http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp).
With embedded-programmers it seems that any form of abstraction is viewed as an unnecessary added complexity and indirection. Maybe that is because in resource-restricted processor environments, there simply is no room for the overhead and thus they never learned to think in those terms.
Being an IT-developer myself, I think I understand the reasoning but I also see the advantages of abstraction, although abstraction has different restrictions on different 'levels'. However, I think it can be done but I am not naive to think that it will be perfect in v1.0. Every 'new' viewpoint takes time to mature and to thoroughly understand.
Note: It is not my intention to disrespect anybody. We all had our -different- journey and that is fine. These are just my observations and not to be interpreted as absolute truth (if such a thing exists).
-
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.
-
I think all OEM HALs suffer from the same problem: they're designed to expose the entire feature set of the hardware. The OEM firmware folks have to implement wrappers for all the interrupts, DMA behaviors, etc. It's particularly obvious in PWM implementations because those peripherals can be used in so many different ways (e.g., for reading rotary encoders, simple PWM, motor control, etc.). My point of view--as someone implementing an embedded application--is that when all I need is an RGB LED (with three simple PWM channels), I don't want to wade through the OEM API that's designed to handle every possible use. I just want to blink the damn LED!
Fortunately, the people who write mcu datasheets seem to much better at documenting their work than the OEM firmware teams. I.e., if I crack open the datasheet for the most gnarly peripheral with dozens of registers, it's still going to be documented well enough to figure out what has to happen. It often turns out that banging registers directly is an easier way to add functionality.
Rolling your own peripheral implementation is even more important if you've got a non-OEM RTOS in the design because then you're probably having to do special things in interrupt handlers. Suppose you're writing a block of bytes in some serial format (e.g., I2C, UART, SPI) and you need to block the calling thread until the transfer is complete. Those OEM HALs usually don't have the kind of hooks you'll need to pull that off. Sometimes the OEM will offer their own RTOS (with HAL support), but that's a much bigger commitment to your embedded architecture.
Summary:
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.
-
I think ChibiOs has a HAL that one could use separately , that solves at least some of the point djacobow talks about in his post.
-
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.
Yes :-+
You've hit the nail on the head here. ST's HAL is indeed nothing more than an obfuscation layer between the device's registers - which for the most part are clear and easily understood - and the code. It doesn't make common functions any easier to set up than poking registers directly, and certainly doesn't relieve any need to read and understand the device's reference manual.
The manual, thankfully, is pretty decent IMHO.
-
How is the quality of the ST HAL compared to the code generated by TI's HALcoGEN? Or TI's driverlib?
-
We use the TI CC2540 HAL at work, it doesnt seem too bad.
-
From stm32_embedded_software_offering.pdf
Low-layer APIs availability :
-
Personally i think a lot of people just want stmcube to generate register level code.
To make it simple to init and change hardware peripheral modes without having to study the datasheet for 2 hours.
Im hoping the new low level api will allow this without adding tonns of unnessesary crap. but im not holding my breath
The stm32cube ide to setup all the hardware and graphically show you clock settings is great. It just needs to generate simple code.
-
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.
This is a great description of what's required from a good embedded library. Which manufacturer comes closest to this today ?
-
Which 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."
-
FWIW, TI's DriverLib is usually pretty good. At least on the MSP430 and more mature TivaC parts I've used. MSP432 was a bit rough last time I looked, but that wasn't on final silicon, soo... Their MSPWare and TivaWare packages are also generally very good.
One huge advantage is a lot of the parts actually have the DriverLib stuff in ROM, so using that abstraction doesn't take up additional memory space. You can set it up so that, at build time, it checks to see if the target has the library in ROM; if so it calls the function from there; if not it compiles and executes it from memory. You can even override the ROM code for specific functions if you want; useful if the ROM based library has a bug that's fixed in a newer version of the DriverLib.
-
Which 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."
Wesft, that's true the arduino does that. It might be even be possible to do it without a big performance hit, like the xpcc[1] guys claim. But sadly, they only offer support for a few chips.
[1]http://xpcc.io/why-use-xpcc/
-
I'd like to point out the core difference in between a hardware abstraction layer (HAL) and peripheral library (PL):
Within OS, HAL provides mechanisms for mutual exclusion and reentrancy of code.
That is not the case with PL.
So comparing advantages of some HAL implementation w.r.t. different implementation of PL is kind of playing with apples and oranges.
The new LL library is just a PL and is not suitable for OS environment as the user would have to add that mutual exclusion layer / reentrancy manually (PITA).