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

0 Members and 1 Guest are viewing this topic.

Offline MTTopic starter

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: aq
Re: ST official anouncment of new low level API
« Reply #25 on: September 19, 2015, 03:19:14 pm »
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!
« Last Edit: October 01, 2015, 09:58:06 pm by MT »
 

Offline donotdespisethesnake

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

Offline Lukas

  • Frequent Contributor
  • **
  • Posts: 412
  • Country: de
    • carrotIndustries.net
Re: ST official anouncment of new low level API
« Reply #27 on: September 19, 2015, 03:44:14 pm »
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
Code: [Select]
GPIOA->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER5_1;

I'd be able to write
Code: [Select]
GPIOA->MODER |= GPIO_MODER_MODER5_AF;

Shouldn't be rocket science for ST do do that...
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: ST official anouncment of new low level API
« Reply #28 on: September 20, 2015, 11:19:03 am »
I think this is no rocket sience for you either. Just put a days work into it and you have what you need...
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: ST official anouncment of new low level API
« Reply #29 on: September 20, 2015, 11:50:04 am »
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).
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1151
  • Country: us
  • takin' it apart since the 70's
Re: ST official anouncment of new low level API
« Reply #30 on: September 20, 2015, 05:36:33 pm »
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.
 
The following users thanked this post: autobot

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: ST official anouncment of new low level API
« Reply #31 on: September 20, 2015, 07:17:04 pm »
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.
 

Offline autobot

  • Regular Contributor
  • *
  • Posts: 66
Re: ST official anouncment of new low level API
« Reply #32 on: September 21, 2015, 05:11:01 pm »
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.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: ST official anouncment of new low level API
« Reply #33 on: September 21, 2015, 05:33:09 pm »
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.

Offline Molenaar

  • Regular Contributor
  • *
  • Posts: 73
  • Country: nl
Re: ST official anouncment of new low level API
« Reply #34 on: October 01, 2015, 08:35:33 am »
How is the quality of the ST HAL compared to the code generated by TI's HALcoGEN? Or TI's driverlib?
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: nz
Re: ST official anouncment of new low level API
« Reply #35 on: October 01, 2015, 08:38:03 am »
We use the TI CC2540 HAL at work, it doesnt seem too bad.
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: ST official anouncment of new low level API
« Reply #36 on: April 01, 2016, 09:28:41 pm »
From stm32_embedded_software_offering.pdf
Low-layer APIs availability :
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: nz
Re: ST official anouncment of new low level API
« Reply #37 on: April 01, 2016, 11:51:20 pm »
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.
« Last Edit: April 01, 2016, 11:53:47 pm by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline autobot

  • Regular Contributor
  • *
  • Posts: 66
Re: ST official anouncment of new low level API
« Reply #38 on: April 02, 2016, 11:41:21 pm »
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 ?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: ST official anouncment of new low level API
« Reply #39 on: April 03, 2016, 06:26:32 am »
Quote
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."
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: ST official anouncment of new low level API
« Reply #40 on: April 03, 2016, 07:51:30 am »
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.
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 
The following users thanked this post: autobot

Offline autobot

  • Regular Contributor
  • *
  • Posts: 66
Re: ST official anouncment of new low level API
« Reply #41 on: April 03, 2016, 04:05:48 pm »
Quote
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/
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: ST official anouncment of new low level API
« Reply #42 on: April 03, 2016, 07:47:27 pm »
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).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf