Why is UART_SetConfig () for the F4 family declared static?

[Lix Paulian]

Posted on July 12, 2017 at 21:23

Hi,

For the STM32F7xx family, the UART HAL library includes in its public API the function UART_SetConfig(), by which certain UART parameters can be modified at run-time, after the initial configuration (baud rate, parity, stop bits etc.) has been done. Why is this same function for the F4 family declared static?

I am working on some middleware that should be compatible with (almost) all ST32F families (as long as HAL is used), but this inconsistency is annoying. Or maybe there is another function to be used for changing UART parameters?

Lix

#uart #stm32fxxx

[Tilen MAJERLE]

Posted on July 14, 2017 at 11:42

Hello

Paulian.Lix_N

‌,

UART_SetConfig is private function for HAL interaction only. If you have to change parameters, please call HAL_UART_Init again with modified parameters or use macros from header to modify registers.

If you check header file from UART, you will see that function declaration is inUART_Private_Functionssection.

[Lix Paulian]

Posted on July 14, 2017 at 12:54

Hello Tilen,

Thank you for the answer. However, re-initializing all the parameters of the UART is not really an option when you want only to change the baud rate, or parity, etc. It's really a rather 'hard' configuration.

I noticed indeed, that while only the F4 UART library has the UART_SetConfig function declared as static, all other Fx families locate this function in the 'private' zone of the header file, although they are perfectly call-able from an application. It's only a matter of a comment line.

The other proposal, using the macros to change registers directly is too low level, then I would have to compute the baud rate too etc. in order to know what to set in the registers. The portability between the different Fx families would suffer.

On the other hand, the LL drivers have specific, documented and public APIs to change baud rate, parity and so on. I think this is the better way to go (e.g. for baud rate LL_USART_SetBaudRate). There should be no problem to mix HAL with LL calls.

[Lix Paulian]

Posted on July 14, 2017 at 13:25

Hmmm... after examining the HAL headers and source code again, at least for the F7 family, I am even more confused: the 

UART_SetConfig()

function is given as being exported (belonging to 'UART_Exported_Functions_Group3') in the 'stm32f7xx_hal_uart.c' file, but in the header file 'stm32f7xx_hal_uart.h' is listed as 'private'! So what should we make out of this?

But even ignoring these inconsistencies, I really wonder why should this function be hidden as 'private'?

Regards,

Lix

[Lix Paulian]

Posted on July 19, 2017 at 00:04

With the risk of being too insistent, may I ask someone from ST what harm would it do if the function 

UART_SetConfig()

would become part of the official, public UART API? There is actually no portable method in HAL to change the basic UART parameters (e.g. baud rate) at run-time, without re-initializing the whole system (which is brutal, especially when using DMA!).

Having this function public on all the STM32 line would be of great help. Currently the function is available on F0, F2, F3 and F7, albeit declared in comments as 'private', however in practice it is public. Only the F4 HAL is stricter and doesn't offer this function to the outside world.

[JojoS]

old subject, but I ran into the same trouble, so just for my records:

On a H7, Set_Config() is public, but changing BaudRate and OverSampling did not work. I found that a __HAL_UART_DISABLE() before and __HAL_UART_ENABLE() made it working.
But in the Init function, Set_Config is called also and the most work is done there. Additionally, Init calls HAL_UART_MspInit(), but only when the uart is not already initialized.
So it is better to call HAL_UART_Init() instead of UART_SetConfig(), it has no performance impact.