Re: STM32 backbone library

[markus]

That is an excellent question. After reading the statements more
carefully it seems ST reserves the right for none-portability:

"...
The HAL and LL are complementary and cover a wide range of applications 
requirements:
* The HAL offers high-level and feature-oriented APIs, with a
  high portability level. They hide the MCU and peripheral complexity
  to end-user.
* The LL offers low-level APIs at registers level, with
  better optimization but less portability. They require deep knowledge
  of the MCU and peripherals specifications.
..."

When they talk about family compatibility they continue to use terms
like "high" and either both APIs are mentioned or none at all (just
talking about STM32Cube in general).
The only time there seems to be a difference is in the global STM32Cube
introduction page:

"...
STM32Cube embedded software libraries, including:

The HAL hardware abstraction layer, enabling portability between different 
STM32 devices via standardized API calls
The Low-Layer (LL) APIs, a light-weight, optimized, expert oriented set of 
APIs designed for both performance and runtime efficiency
A collection of Middleware components, like RTOS, USB library, file system, 
TCP/IP stack, Touch sensing library or Graphic Library (depending on the MCU 
series)
..."

Personally I've never seen a difference or discrepancy - if there was
an applicable LL api it worked for all mcu's. But that might say more
about my experience with their devices than about the real portability
of the LL.


On Wed, 28 Mar 2018 06:50:35 -0300
Fabio Utzig  wrote:

> On Tue, Mar 27, 2018, at 3:45 PM, markus wrote:
> > Hey Miguel,
> > 
> > as you can tell - still causing trouble ;)
> > 
> > I should have mentioned that both APIs, LL (low level) and HAL (high
> > level) are provided by ST Microelectronics and are part of their
> > SDKs.
> > 
> > Although the LL API is called "low level" it is still portable
> > between the different STM32 processor families. The big advantage
> > is that it is stateless, doesn't require big data structures, and
> > allows finer control.  
> 
> Yes, feel free to use it! Btw, is there any explicit "contract" where
> it is mentioned that they will always be portable across different
> families?

Re: STM32 backbone library

[Fabio Utzig]

On Tue, Mar 27, 2018, at 3:45 PM, markus wrote:
> Hey Miguel,
> 
> as you can tell - still causing trouble ;)
> 
> I should have mentioned that both APIs, LL (low level) and HAL (high
> level) are provided by ST Microelectronics and are part of their SDKs.
> 
> Although the LL API is called "low level" it is still portable between
> the different STM32 processor families. The big advantage is that it is
> stateless, doesn't require big data structures, and allows finer
> control.

Yes, feel free to use it! Btw, is there any explicit "contract" where it is 
mentioned that they will always be portable across different families?

Re: STM32 backbone library

[markus]

Hey Miguel,

as you can tell - still causing trouble ;)

I should have mentioned that both APIs, LL (low level) and HAL (high
level) are provided by ST Microelectronics and are part of their SDKs.

Although the LL API is called "low level" it is still portable between
the different STM32 processor families. The big advantage is that it is
stateless, doesn't require big data structures, and allows finer
control.

HTH,
Markus


On Tue, 27 Mar 2018 17:54:47 +
Miguel Azevedo  wrote:

> Hey Markus!
> How are you doing?
> 
> Yes, In fact our Nordic drivers are a wraparound to the
> manufacturer's drivers. So what is happening is [mynewt
> driver]--->[nordic driver]--->[nordic hal]. Is this optimal?
> No, but it works because Nordic works out every workaround for any
> possible hw/hal bug.
> This allows us to have a driver which works for all nRF52xxx chips.
> I wouldn't oppose to have the same going on with STM(despite the fact
> that I don't know much about their hw/libs).
> I think a good person to ask this is Fabio Utzig, I believe he has
> some experience with these boards and he's aware of how STM hw works.
> :)
> 
> Best Regards,
> Miguel
> 
> 
> On Tue, Mar 27, 2018 at 5:27 PM, markus  wrote:
> > I have a PWM implementation for the STM32 (currently F3 & F7) but
> > I'm not happy with it - which is why there currently is no PR.
> >
> > Most of what I want to change is the use of the backend library,
> > using the LL api instead of HAL. All STM32 bindings I could find in
> > mynewt are based on the HAL library ...
> >
> > Is it acceptable to base a peripheral library on the LL api or is
> > that not something to be done in mynewt?
> >
> > Have fun,
> > Markus  
> 
> 
>