I am writing the explaination for HAL.

[Cl.1]

I arrange 3 main advantage for using the HAL rountines compared with direct memory access.

• HAL will faster than direct access.
• HAL will offer more easy to remember the function names.
• HAL will make the code more portable.

Is that three advantage is correct thus i able to continue my explaination for HAL.

Thanks anyone helip me in advance!

[Tesla DeLorean]

Pretty sure HAL is not fast and nimble​.

​

Code is relatively portable.

High level code and good abstraction can reduce development time.​

[berendi]

HAL is neither high level nor does it offer a good abstraction.

[berendi]

> HAL will faster than direct access.

No. Who told you that?

HAL functions themselves are accessing the memory mapped registers directly, there is no other way, but they check a few things in the handle structures before each access. This makes them a lot slower than a simple register access. See the result here.

> HAL will offer more easy to remember the function names

HAL function names might be easy to remember, but they are poorly documented. HAL documentation is most of the time a single sentence for each function or parameter, not really explaining what it is exactly doing.

On the other hand, registers and bitfields are extensively documented in the reference manual, with timing diagrams and step-by-step examples on how to use them.

> HAL will make the code more portable.

In some special cases. Otherwise HAL is not even always compatible with itself, the behaviour of functions are sometimes changed between releases. The register interface is guaranteed to remain stable throughout the lifecycle of the product, i.e. at least 10 years. There are no guarantees that HAL will be available next week, ST can abandon it any time like they did with the SPL library.

If you want to continue, you can find a few more "advantages" of using HAL here.

[waclawek.jan]

> I am writing the explaination for HAL.

Why?

JW

[Jack Peacock_2]

A HAL does help in portability. Maybe, sometimes, depending on how well it's designed and coded. For a large controller family with similar peripherals some level of abstraction does help when working across several series (in my case, L0, L1, L4, F7). The ST HAL however is not my first choice as an example to praise.

I still use the SPL API with my own libraries, to good effect. The abstraction is simpler and doesn't all those hidden "gotchas" embedded in the HAL interactions. The parameter checking does help in the initial debugging...everyone makes typo errors.

Easy to remember? That's subjective and not really all that relevant. Code reuse is a necessity in commercial programming. I rely on cut and paste more than function mnemonics. Maybe if this were assembly language the "easy to remember" might be significant (a good example is the old DEC VMS system calls). With C, no.

A HAL is a layer on top of direct register access. Think about it, how can it possibly be faster? and is that so important? On battery powered systems I often slow down to 4MHz and still have plenty of CPU cycles left. I'm not concerned about saving a few bus cycles with direct vs. abstraction layer.

This sounds like homework. Kinda sad to see what's taught in comp sci (or is this electrical engineering?) classrooms now. I suppose questioning fundamental assumptions (AKA critical thinking) isn't part of the curriculum any longer.

Jack Peacock

[Cl.1]

Thanks guys for reply me. I wrting the explaination for HAl which is because i going to writing a report about what i learn about STM32.

[Pavel A.]

This may be helpful for your homework: see the free intro chapter.

https://www.beningo.com/store/developing-reusable-firmware-a-practical-approach-to-apis-hals-and-drivers/

[waclawek.jan]

Well, the example on Page 14 tells a lot...

JW

[waclawek.jan]

> i going to writing a report about what i learn about STM32.

Well, then perhaps you should write about *your* experience with HAL.

So, you using HAL, did you find your code to run faster? Did you find you could port your code better? Did you remember function names easier?

Note, that correct answers require also a reference (e.g. "as compared with using registers directly").

JW

[Cl.1]

By using HAL i no need to find out the allocation of every pin thats why i though HAL is faster than direct access.

By using HAL I able to direct read, write and toggle that why is i think it is more easy to remeber the function.

​

Those are the reason are base from i "thoughts".

Thanks for your comments!

[berendi]

> By using HAL i no need to find out the allocation of every pin thats why i though HAL is faster than direct access.

There is no HAL function that helps to find out possible pin allocations.

There is a pinout editor in STM32CubeMX doing that. Of course the resulting pinout can be used in any program with or without HAL.

> By using HAL I able to direct read, write and toggle that why is i think it is more easy to remeber the function.

Calling HAL_GPIO_TogglePin results in calling one of two different, incompatible functions depending on the HAL version.

One of them can mess up unrelated pins when interrupted.

The other one messes up when more than one pin is toggled, which is explicitly allowed in the function documentation.

The only thing which is easy to remember about HAL functions is to avoid them whenever possible.