HAL Library seems to not follow classic programming guidelines

[Werner Dähn]

Posted on June 09, 2018 at 15:42

I understand that programming enterprise software on a 8 core CPU with 4GHz and a simple STM32 MCU is different, nevertheless I would have added a few things to the HAL layer from the beginning:

1. All HAL Init calls check if there is a collision with other resources. I configure PA1 as GPIO, then I use UART1 which needs PA1, hence the UART config should return an error. Granted, CubeMX is supposed to help you with that in a graphical manner but it does not in case you assign pins dynamically. And even if, what's wrong with validating that in a debug compile firmware a second time? Wouldn't that help beginners significantly?
2. Programming a MCU is very hardware related. You need to open that gate to provide power to... by setting a register, switch the line to alternate pin by another register etc. From a HAL library I would expect to abstract exactly that. I want to enable UART1 on pin PA6, therefore the__HAL_RCC_GPIOA_CLK_ENABLE is called implicitly by the HAL_GPIO_Init function, the remap is called and the corresponding AF clock enabled and.... Things like that. Why should I remember every dependency if the HAL can do that for me?Another example: How many lines of code do you need to get an quadruple encoder (up/down counter) to work? Logically one call saying which pins to use and maybe choose the timer number. The counter specific X2 falling/X2 rising/X4 setting is needed also. Everything else can be derived from that information. Today you need 20-30 lines of code and if just one is wrong, you will not find out easily.
3. The implementation is often too basic. Most obvious in the UART part of HAL. You can do char polling, add a interrupt callback or DMA. Fine. But useless as in most cases you would use a ring buffer. No rocket science but since when is that requested and yet still not available out of the box? Another missing receiver method is when timing plays a role like with serial packets. Every 20ms I get a packet that starts with 0x01 and ends with 0xEF and lasts for up to 5ms.

Wouldn't such things help greatly to get started? And to debug? And make the user experience better? And lower frustrations? And cause proper error messages rather than simply not working?

Or am I missing something.

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[AVI-crak]

Posted on June 10, 2018 at 15:05

I'm not forcing you specifically to use my method. I can not demand, but I can perfectly sow panic, violence and insanity. I do it well.

The main goal is to give a new idea. From how much this idea will be successful and attractive - depends on its distribution. Yes, there is an appropriate section of this forum - but I'm not sure what I was answered by a living person.

It is useless to wait for solutions from domestic hamsters, obediently pushing the mouse in the CubeMX. They do not have their own thoughts, they do not even have their own desires. They need quickly and now - a completely justified approach among other things. But if you look at the messages of this forum: even pushing the buttons in the ready interface does not solve the problem of human error.

How should exactly look like cmsis - I do not know. It is necessary to conduct natural tests with several models of data representation. However, now I know for sure - you can not use &sharpdefine, you need to use static structures. With their help, you can avoid most errors associated with mutually exclusive use of constants, skipping the desired values, and using unnecessary ones.

I use dolls (blanks) - which I place directly in the most important sacred file. Example

https://community.st.com/external-link.jspa?url=https%3A%2F%2Fbitbucket.org%2FAVI-crak%2Fsystem_f746%2Fsrc%2Fdefault%2Fstm32f746xx.h

This example is not complete, I do not have time for a complete transformation.But the general meaning is simple: a higher-level workpiece is created, created specifically for one type of processor (unique). It does not have exact register values, but it has the exact sequence of their use !!! it is very important. Using the search tools of the software shell - I search for the declaration of the selected element of the array of registers, and I get to the saved doll (workpiece). I copy it completely, delete the unnecessary, fill in the necessary data with meaningful data.You may be surprised - but you do not have to look at the documentation for the chip !!!Can you tell me the same about HAL, LL, or cmsis? There it is impossible to write a new sink without an open reference book.

[AVI-crak]

Posted on June 10, 2018 at 15:34

Juha Aaltonen - Do you need a handy weapon with protection against misuse? This is not possible on a physical level.

To solve this problem, programming languages of a higher level than pure C were invented. There you can not make a physical mistake (more precisely, very difficult), but you can easily make a logical mistake. Your weapon will shoot properly, but without hitting the target. C ++, Go, and a whole bunch of younger programming languages - they all make logical mistakes, all without exception.

To solve such problems, a large project is assembled from an infinite number of small fragments. Each separate piece of code is checked, has no errors, and works exactly as described in the function header. Naturally - someone should make efforts to create small code. There are those who collect larger fragments from smaller fragments, and so on.

This is the reason - there are no ready-made small blocks from ST. There are tools, there is an instruction, there is a sand pit and a mine. You need to lead the sand yourself, melting steel and making reinforced concrete structures for your house.

Convenient truth?

[turboscrew]

Posted on June 10, 2018 at 15:49

I'm usually fine with assembly. Or C if the SW is to be bigger. If there are lots of participants writing the code, I'd recommend Ada. I wouldn't use any interpreted languages - not even with bytecode interpreters.

I wrote this:

https://github.com/turboscrew/rpi_stub

because I didn't have any means of bare metal SW debugging. It's my 'blinky' in the ARM world...

I didn't write all of it myself - I included 'stdint.h'... :D

[henry.dick]

Posted on June 10, 2018 at 16:46

'

Can you tell me the same about HAL, LL, or cmsis? There it is impossible to write a new sink without an open reference book.'

the fact that something cannot be fitted through your particular approach nicely doesn't make that something bad. you have to first establish for everyone that your approach is good. and then we can go from there.

[henry.dick]

Posted on June 10, 2018 at 16:47

'

However, I am surprised by people who take these libraries and make a standard on them.'

i'm not, as I have yet to see something making a standard on them. 

unless of course you use the word 'standard' in some unique ways.

[AVI-crak]

Posted on June 11, 2018 at 05:28

you have to first establish for everyone that your approach is good. and then we can go from there.

I've already heard such a proposal - do it first, and then we'll see.

I did it for myself, and was pleased. The new one appears in accordance with personal requirements, when I personally have to read the documentation once again. At this point the issue with the problem block is closed once and for all. The next project using this periphery does not require reading the documentation.This does not mean that I remember or learned part of the periphery, I do not need this. I just made a doll (the full standard template for copying into the project) for this part of the periphery. In a day I will forget all these bizarre names of registers, it will be enough for me that the whole block works as expected.

These are the smallest bricks of which a large building is being built. And I do not care how many quality certificates my tool has. The main thing is that the finished product has a working state.

[eBirdman]

Posted on June 14, 2018 at 18:24

to Juha Aaltonen and to all who sees the advantage of the low level programming.....

Just a couple of days ago I had to add reading the raw input from an incremental encoder. Now I have those GPIO pins used for both GPIO inputs and inputs to timer in encoder mode. Good that HAL didn't check for 'conflicts'. And yes, our company wants us to use HAL. I'd do fine without any libraries and frameworks.

Your example is misused - this is not an example of something to be checked by HAL for a conflict - there is no possibility of conflict. Branching of a single output to many inputs is not a conflict (subject to amperage allowed).

Correctly written HAL abstraction library is the way of the future and even today, given intelligent implementation (there are such implementations outside of ST).

I started my first embedded development back in 1978...... it was Assembly language programing bits of the Intel 8080 registers... I did not trust even the first appearance of the cross compiler with it's toolchain running on IBM - I thought this is not the way to do embedded micro-processor... I wanted a full control of every programmed bit ..........

Looking back at all my projects in two continents and dozen of companies, I will tell you now -

Intelligent HAL library in the future will completely obliterate any notion of the low level register-based programming... this future is already here but you don;t know it yet because those HAL-software tools are in their infancy,   but for you to understand this view you need the same what made me to change my mind - 40 years .... holly number

[turboscrew]

Posted on June 14, 2018 at 18:47

Hmm, you started almost 10 years before me...

One thing that's hard to do nicely with HAL is clock reconfigurations when the system is regularly put to sleep on RTC timer only to save battery.

HAL routines 'have always' milliseconds to waste waiting things to come up/shut down one by one.

Also partial reconfiguration of peripherals on-the-fly is often messy.

And third, HAL is BIG.

[eBirdman]

Posted on June 14, 2018 at 19:21

I'll let you laugh by sharing my 'proofs' 40 years ago that using 'C' cross compiler to program embedded processor is no good - one must do it in Assembler : here we go

1.  program derived from C language cannot be compact enough to fit in a limited on-board memory (and I was proud having developed in 1978 my first few KByte dynamic RAM fully synchronized with embedded CPU over the Intel's Multi-Bus - that RAM was filled to the neck with Assembler written code - there was no space for the overhead of the cross compiler:)
2.  C language cannot 'know' all the intrinsic peculiarities of the Intel CPU at the same level as I (the developer) knew. Indeed the cross compiler was not as good in using CPU registers....
3. Debugging 'C' produced code was not no good and no easy - even though I developed my own in-circuit emulator but it was only good when following the Assembler code - not possible to follow 'C' code during the test....

That above is a very limited list - there was more.... aren't those reasons sound ? How much would you accomplish today if the technology were stuck in my mentality 40 years ago?

Many things changed since then as you now know .... not only technology...  there is also a personal aspect - I was young and knowing at the time that there was nobody within a radius of 1000 km around me who knew as much of the digital embedded CPU, gave rise to the boosted ego (my on-going high tech experience surely must be superior than anything else...... young age is the utmost ego which subsides over the years)

Now, in 21st century, it is even funny to need to convince other developers that they should focus on their goal product, not spend time on dealing with the chip internal register' bits.... not all companies these days came to understand this - the competition in making the truly advanced software development tools (HAL is the key) only started... watch around ...........

[eBirdman]

Posted on June 14, 2018 at 19:27

Do you realize that your grievances have all to do with a particular implementation of HAL library, not with idea of HAL as it suppose to be ?  This (like everything else in life) has it's benefit for you - sooner or later, when you get in your hands a truly intelligent HAL library you will feel BLESSED