2017-02-02 02:40 AM
The ST HAL should make programming STM32 microcontrollers easier. After all, it is a 'Hardware Abstraction Layer'. It provides an interface to the user, so he doesn't need to manipulate the hardware registers directly.
An abstraction layer is called 'leaky' when its interface isn't sufficient, such that the user needs to dig deeper into the low-level stuff. The failure of an abstraction layer generally has two causes:
(1) Bugs
I didn't bumb into bugs in the ST HAL. It looks like the code is of good quality and well-maintained.
(2) Lacking documentation
This is definitely the weakest point of the ST HAL. The documentation is so brief that I end up doing this:
>> Study the whole (related) chapters in the 'Reference Manual' of the chip
>> Open the functions of the ST HAL and read their code, study how the actual registers are manipulated
The lacking documentation forces the user to dig into the low-level stuff. This makes the abstraction very 'leaky', up to the point that I start to question its benefits.
Dear STMicro - please consider more investments into the HAL docs.
#hal #hal-driver #cubemx-stm32-hal2017-02-02 04:54 AM
Hi
Mulier.Kristof
,Thank you very much for yourfeedbackand interest on HAL solution
'Lacking documentation': with any HAL firmware package a set of user manuals isprovided
to give adetailed description of each peripheral driver .Could you please give to us example of missing information on HAL documentation, this may help usto understand well your expectation ?
Itis always required to review errata sheet, datasheet and reference manual in order touse efficiently your device.
-Nesrine-
2017-02-02 06:51 AM
Hi
ELMHIRI.Syrine
,Thank you very much for your quick reply :)
My latest problem relates to setting up the Timer peripheral on my STM32F767ZI device. I wanted to use the HAL, so I downloaded the following HAL documentation for the STM32F7xx family:
Chapter 60 is about the 'HAL TIM Generic Driver'. It basically lists out all the HAL functions and structures, but it doesn't explain how the Timer peripheral works. There is only one page (p 890) explaining very short 'How to use this driver'. But that is definitely not enough to start using it.
So I fall back on the STM32f7xx Reference Manual:
The reference manual is very well written. It explains the timer module in very deep detail. After reading the reference manual, I can dig into the HAL code myself and reverse-engineer how it works.I have no issue with this personally - I like understanding how things work down to the bottom.
However, my employer hoped that the ST HAL would enable me to put the big Reference Manual aside and get things done quicker thanks to the HAL abstractions. But I miss the docs..
After reading your answer, I realized I didn't check all the application notes. I just found out the existence of the following document:
This application note is quite big - 73 pages. I scroll through it now to get a feeling of what sort of information it contains. It refers indeed to the HAL, but most of its explanations are also on the register-level (see page 30, 31, 36, 37, ...). Perhaps it can be compared somewhat to the Reference Manual?
2017-02-02 06:57 AM
>> Study the whole (related) chapters in the 'Reference Manual' of the chip
>> Open the functions of the ST HAL and read their code, study how the actual registers are manipulated
I'm not sure this is a deficiency. It's the type of thing you need to do otherwise you get a generation of coders that think watering plants with electrolytes is a good thing.
2017-02-02 08:06 AM
Thank you
Turvey.Clive.002
I agree with you. Call me crazy, but I like reading datasheets and reference manuals. It comforts me to understand how things work down to the bottom.
My employer tends to disagree, because thecompany - in fact our clients - want quick results. You know, long-term vs short-term interests ... ;)
2017-02-02 08:39 AM
Isn't the main idea in clicking-up the bulk of application in CubeMX? That's what I though is the promise of 'quick results' IMO.
Of course, this limits you to a few cathegories of applications, but that's what 'quick results' is all about, anyway.
You may quote me.
JW
2017-02-02 08:53 AM
I'm not sure
Waclawek.Jan
,With CubeMX you can get some HAL code, but this doesn't mean you understand what's going on. So you're stuck when you want to change things...
2017-02-02 11:02 AM
That's exactly it. Understanding requires time - 'quick results' precludes understanding.
In my vocabulary, 'hardware abstraction' sounds just like 'I don't want to know what's happening in the hardware, just give me a simple uniform API'. Doesn't that sound as the exact opposite of understanding?
Unless your application fits into the categories which can be clicked in CubeMX, or which can be tweaked from the existing examples, or which can be generated using mbed (ST incarnation of which is built upon Cube), there's no 'quick solution'.
My personal view, arguable.
JW
2017-02-02 08:25 PM
The problem is that when you need to read a huge manual to be able to use an API... means that something went wrong designing the API.
Also, the approach using structs as containers for the parameters of a function is questionable, it doesn't add more clarity and is just waste of memory. It may be helpful if the programmer writes the struct in ROM but anyway that is not a functionality devoted to an HAL API.
In particular, the situation of Cortex-M microcontrollers it is becoming paradoxical.
On one side ARM updates, upgrades and complicates CMSIS adding much more 'standard API' (as RTOS API) in a bottom-up fashion and on the other side ST and the other silicon vendors write the 'silicon vendor part' of CMSIS. The result is that this (wrong) interface prevents the use of a common API that may be usable with the same interface by any Cortex-Mx MCU.
Seems that ARM did a good job about instruction set scalability but not so much about CMSIS API scalability.Think what means changing an HAL API in this context as happened with the last ST libraries (after Cube-MX).
The result is that to write SW we need to learn CMSIS and the libraries APIs and to debug at the lowest level the MCU datasheet. At the end, the situation now is worse than without the 'standard' CMSIS and APIs.
2017-02-09 02:09 AM
I agree it is lacking while perhaps not so much in content, even though there are improvements to be made there as well. Having to search 3 or 4 different PDF docs to find complete information for doing one task is unnecessarily involved. Much of this industry seems to be stuck in 1990, publishing data and notes in PDF documents which IMO is the wrong way forward. I also expressed this opinion in the 2017
post (page 4, only 1 Like!?!?) about ST making an online, indexed help file/reference manual available. One with embedded links in the text that will let me access related information effortlessly. This would make the vast amount of available information much more easy to navigate.As an example, look at ARM's online documentation. This is a good example how it should be done: