ST official anouncment of new low level API - Page 1
Forum section: electronics / general

author: MT
author_rank: Super Contributor
timestamp: September 17, 2015, 02:52:49 pm
content: As mentioned earlier is now official by ST , whether it will be yet another ST software/documentation disaster is still yet to bee seenafter 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.

author: mark03
author_rank: Frequent Contributor
timestamp: September 17, 2015, 03:45:42 pm
content: 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.

author: jnz
author_rank: Frequent Contributor
timestamp: September 17, 2015, 04:19:19 pm
content: Quote from: mark03 on September 17, 2015, 03:45:42 pmI 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).

author: Marco
author_rank: Super Contributor
timestamp: September 17, 2015, 05:32:41 pm
content: Quote from: MT on September 17, 2015, 02:52:49 pmLOL, there is someone there that thinks you can ever have anything but.

author: MT
author_rank: Super Contributor
timestamp: September 17, 2015, 05:44:29 pm
content: 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!I cant directly migrate a 103 project because ST have changed the 429 register definition names for a vast number of peripherals in the2011 definition file!

author: Len
author_rank: Frequent Contributor
timestamp: September 17, 2015, 05:48:46 pm
content: Quote from: jnz on September 17, 2015, 04:19:19 pmAccording toST's web pagethe Low Layer API can be used either with or instead of the HAL:QuoteThis 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.

author: nctnico
author_rank: Super Contributor
timestamp: September 17, 2015, 08:06:13 pm
content: Quote from: mark03 on September 17, 2015, 03:45:42 pmI 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.

author: ajb
author_rank: Super Contributor
timestamp: September 17, 2015, 08:47:31 pm
content: Quote from: Len on September 17, 2015, 05:48:46 pmThis 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.

author: nctnico
author_rank: Super Contributor
timestamp: September 17, 2015, 09:51:29 pm
content: 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.

author: MT
author_rank: Super Contributor
timestamp: September 17, 2015, 11:47:10 pm
content: 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.

author: Ribster
author_rank: Frequent Contributor
timestamp: September 18, 2015, 07:19:23 am
content: I can't seem to find it on their site. Could you give a hand as to where you found this ?

author: westfw
author_rank: Super Contributor
timestamp: September 18, 2015, 10:06:42 am
content: QuoteOh 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!

author: Kjelt
author_rank: Super Contributor
timestamp: September 18, 2015, 10:47:47 am
content: 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 problemsYeah 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.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 18, 2015, 01:07:14 pm
content: Quote from: Ribster on September 18, 2015, 07:19:23 amsame 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.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 18, 2015, 01:14:28 pm
content: Quote from: Len on September 17, 2015, 05:48:46 pmThis 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.

author: MT
author_rank: Super Contributor
timestamp: September 18, 2015, 01:43:15 pm
content: Quote from: Kjelt on September 18, 2015, 10:47:47 amYou 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!QuoteQuoteSee, you aswered your own allegation, a sign of a lazy coder who is scared to poke around in registersand 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!QuoteTime 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)..

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: September 18, 2015, 02:20:49 pm
content: The Low Level drivers are so far only in the CubeL4 packagehttp://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908"Uses CodeSonar", apparently.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 18, 2015, 03:26:33 pm
content: Quote from: donotdespisethesnake on September 18, 2015, 02:20:49 pmI 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.

author: mark03
author_rank: Frequent Contributor
timestamp: September 18, 2015, 03:29:17 pm
content: Quote from: Kjelt on September 18, 2015, 10:47:47 amIt'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,exceptthat 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.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 18, 2015, 03:36:51 pm
content: Quote from: MT on September 18, 2015, 01:43:15 pmI 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!

author: ajb
author_rank: Super Contributor
timestamp: September 18, 2015, 03:54:09 pm
content: Quote from: Kjelt on September 18, 2015, 10:47:47 amSure, 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 functionswithouttrying 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.

author: Tainer
author_rank: Contributor
timestamp: September 19, 2015, 12:07:18 pm
content: I'm surprised thatlibopencm3hasn't been mentioned yet. I think the best thing ST could do is to contribute to the project

author: ntfreak
author_rank: Contributor
timestamp: September 19, 2015, 12:31:23 pm
content: Quote from: Tainer on September 19, 2015, 12:07:18 pmI would imagine the LGPL licence is not helping libopencm3 with vendors or any commercial use.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: September 19, 2015, 01:23:32 pm
content: Quote from: Tainer on September 19, 2015, 12:07:18 pmWhat 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.

author: ntfreak
author_rank: Contributor
timestamp: September 19, 2015, 01:54:40 pm
content: Quote from: donotdespisethesnake on September 19, 2015, 01:23:32 pmIf I recall mbed uses an Apache licence rather than LGPL.

author: MT
author_rank: Super Contributor
timestamp: September 19, 2015, 03:19:14 pm
content: Quote from: bigdawg on September 18, 2015, 03:36:51 pmI 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 abstractingto death utterly simple things like systick who barely needs 3 register writes to be initialized, setup, and enabled and at thesame time they completely destroyed portability of code between devices by splitting up the systick definitions onto 3 differentfiles for one family of devices while for other devices continue to have systick neatly described in one file it is suposed to benamely the definition file. And that for a function that is part of the ARM package and not ST. Same goes for NVIC but im not100% 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 abstractionper see, it's the way STM creating and managing the whole gorilla i'm against! What's worst of all ST is loosing moneyby doing all those convoluted abstraction layers, and they don't realizing it , they believe they are "hipp" and modernand trendy! As Clive described just imagine all the people needed to wrestle with this gorilla that now weights200mega 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!

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: September 19, 2015, 03:25:36 pm
content: Quote from: ntfreak on September 19, 2015, 01:54:40 pmMost 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.

author: Lukas
author_rank: Frequent Contributor
timestamp: September 19, 2015, 03:44:14 pm
content: 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 writingCode:GPIOA->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER5_1;I'd be able to writeCode:GPIOA->MODER |= GPIO_MODER_MODER5_AF;Shouldn't be rocket science for ST do do that...

author: Ribster
author_rank: Frequent Contributor
timestamp: September 20, 2015, 11:19:03 am
content: I think this is no rocket sience for you either. Just put a days work into it and you have what you need...

author: obiwanjacobi
author_rank: Super Contributor
timestamp: September 20, 2015, 11:50:04 am
content: 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..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).

author: djacobow
author_rank: Super Contributor
timestamp: September 20, 2015, 05:36:33 pm
content: Quote from: obiwanjacobi on September 20, 2015, 11:50:04 amLet 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: September 20, 2015, 07:17:04 pm
content: 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.

author: autobot
author_rank: Regular Contributor
timestamp: September 21, 2015, 05:11:01 pm
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: September 21, 2015, 05:33:09 pm
content: Quote from: andyturk on September 20, 2015, 07:17:04 pmYesYou'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.

author: Molenaar
author_rank: Regular Contributor
timestamp: October 01, 2015, 08:35:33 am
content: How is the quality of the ST HAL compared to the code generated by TI's HALcoGEN? Or TI's driverlib?

author: Psi
author_rank: Super Contributor
timestamp: October 01, 2015, 08:38:03 am
content: We use the TI CC2540 HAL at work, it doesnt seem too bad.

author: marcopolo
author_rank: Regular Contributor
timestamp: April 01, 2016, 09:28:41 pm
content: From stm32_embedded_software_offering.pdfLow-layer APIs availability :

author: Psi
author_rank: Super Contributor
timestamp: April 01, 2016, 11:51:20 pm
content: 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 breathThe stm32cube ide to setup all the hardware and graphically show you clock settings is great. It just needs to generate simple code.

author: autobot
author_rank: Regular Contributor
timestamp: April 02, 2016, 11:41:21 pm
content: Quote from: djacobow on September 20, 2015, 05:36:33 pmThis is a great description of what's required from a good embedded library. Which manufacturer comes closest to this today ?

author: westfw
author_rank: Super Contributor
timestamp: April 03, 2016, 06:26:32 am
content: QuoteArduino? 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."

author: timb
author_rank: Super Contributor
timestamp: April 03, 2016, 07:51:30 am
content: 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.

author: autobot
author_rank: Regular Contributor
timestamp: April 03, 2016, 04:05:48 pm
content: Quote from: westfw on April 03, 2016, 06:26:32 amWesft, that's true the arduino does that. It might be even be possible to do it without a big performance hit, like the xpcc guys claim. But sadly, they only offer support for a few chips.http://xpcc.io/why-use-xpcc/

author: Brutte
author_rank: Frequent Contributor
timestamp: April 03, 2016, 07:47:27 pm
content: 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).