STM32 HAL Macro functions

[sarun]

Hi everyone,

I’ve noticed that STM32 drivers make extensive use of macros, and I’m curious about the reasoning behind this. Is the primary motivation is to increase performance / improve maintainability / are there other factors involved?

[TDK]

Because they work and take up no memory. It's common in C and has the least headaches with implementation as you don't need to resolve symbols at the linker stage. Also will be the fastest.

[Andrew Neil]

(never mind)

[Andrew Neil]

---

@sarun wrote:

I’ve noticed that STM32 drivers make extensive use of macros, and I’m curious about the reasoning behind this

---

As @TDK said, it's pretty standard C practice.

Can you give an example, and say what alternative implementation(s) you would find less surprising?

PS:

Here you have someone asking for more macros:

https://community.st.com/t5/stm32cubeide-mcus/macro-for-different-dma-types/td-p/722443 

[sarun]

Being the fastest makes sense, but the majority of macros I’ve seen are used for initialization purposes. Is there really a need for such speed during initialization? What would happen if we converted these macros to regular functions or static inline functions instead?

[sarun]

Hey, I’m not complaining—I just want to understand the reasoning behind it. Nowadays, many are aiming for MISRA code qualification, so for a product as comprehensive as the HAL, why not take a more compliant approach? From what I understand, using macros in this way may violate MISRA guidelines.

As for alternatives, I’m considering the use of inline functions or regular functions. However, I believe the decision would depend on the performance requirements.

[Andrew Neil]

---

@sarun wrote:

 What would happen if we converted these macros to regular functions or static inline functions instead?

---

An issue with inline is that it's really just a hint to the compiler, so the result becomes is compiler dependant.

PS:

"inline does not force inlining; the compiler is free to choose not to inline the function at all, or only in some cases. Different compilers vary in how complex a function they can manage to inline"

https://en.wikipedia.org/wiki/Inline_function#Problems:~:text=inline%20does%20not%20force%20inlining%3B%20the%20compiler%20is%20free%20to%20choose%20not%20to%20inline%20the%20function%20at%20all%2C%20or%20only%20in%20some%20cases.%20Different%20compilers%20vary%20in%20how%20complex%20a%20function%20....

and other issues:

https://en.wikipedia.org/wiki/Inline_function#Problems

[TDK]

It could be done other ways. Need is difficult to define when the project involves a multitude of projects.

Every programmer has a different opinion. Better to use what exists than try to change everything you come across.

> What would happen if we converted these macros to regular functions or static inline functions instead?

At the least, execution would be slower and compile/link time would increase, while the functionality would remain the same.

[Pavel A.]

> As for alternatives, I’m considering the use of inline functions

This is what the "modern C++" school teaches, and a good idea generally. But a simple example:

#define FOO()  (*moo)

 If macro FOO is not used in the compilation unit and moo is not defined, there's no problem. But if FOO is defined as inline  it will compile and fail when moo is not defined (or has wrong type):

inline int FOO(void) { return *moo; }

[sarun]

Based on the data I’ve read, we have two main options: either stick with the macro or switch to normal functions, In the long run using inline functions seems to be the least preferred solution.