UART or USART in Cube libraries ?

[Pavel A.]

So even newer STM32s still have both of UARTs and USARTs.

My question is about how they are going to be supported in Cube libraries.

Am dealing with H7x3 recently, and noticed that the UART example actually is for USART - as the serial connector on the eval. board is indeed USART1.

https://github.com/STMicroelectronics/STM32CubeH7/blob/e261d820b398846a94f22f4aeb32d86c29546efb/Projects/STM32H743I-EVAL/Examples/UART/UART_HyperTerminal_IT/Inc/main.h#L33

I've played with the example as is, and it works. Then out of curiosity I've changed all uses of "UART" lib API there to USART (added hal_uart.c, ...uart_ex.c to the project...) and RX interrupt no longer works. Output works well.

It does not get any singe RX interrupt.

In my real project both UARTs and USARTs will be needed.

What we have in the HAL drivers?

stm32h7xx_ll_usart.h is there, but no ll_uart.h/.c

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Inc/

And same in STML4 library.

Is this simply omission or the developers intend to unify UART and USART in one module?

So that only USART will remain as superset?

I plan to use LL drivers instead of "HAL" of course, but still learning differences of "low level" details of the newer U(S)ARTs compared to these of F4 and F0, so still need working examples, even if they demonstrate HAL libs.

Regards,

-- pa

[S.Ma]

There are different IP generations, or versions for each peripheral.

This information is unfortunatly not disclosed, yet not secret, you need to compare in the ref man of different STM32 to identify it.

USART, LPUART, UART are different IPs (and silicon size = cost)

As far as I get it, UART don't have clock gen, don't have HW flow control and other specific protocols in place.

Didn't dig in the complex H7, I recall the USART now got HW FIFOs as new generation IP.

Same for SPI, first gen was crude, second gen was introduced a FIFO and more variable bit length, third gen got true shift register behaviour for daisy chain mod.

Maybe the UART and USART mismatch in generation which widen the gap in SW compatibility and encapsulation?

[Tilen MAJERLE]

Differences between UART and USART hardware IP are described in reference manual, see snapshot:

USART has additional option to support synchronous communication with clock generation.

You can use HAL UART module for all UART or USARTs when these are NOT used in synchronous mode. Otherwise, you need to use HAL USART module.

So for you, unless you use synchronous mode [with clock], you can use HAL UART module with all 8 U[S]ARTs in the project. All have option for HW flow control.

Hope it is clear.

Tilen

[waclawek.jan]

In other words, all UART stuff in Cube is entirely superfluous.

JW

[Pavel A.]

> In other words, all UART stuff in Cube is entirely superfluous.

This is why I wanted to convert the demo to USART API.

If ST wants one "higher level" API suitable for UARTs USARTs and LPUARTs - then OK, let's call it UART.

This should be documented somewhere. At least in the example code.

-- pa

[Pavel A.]

Thank you Tilen for explanation. I was looking for more gradual transition from HAL API (where only UART seems to be working) to USART (where only USART .h file is provided but not UART).

There were some bumpers on the way.

To start , take just the init code:

UartHandle.Instance    = USARTx;
 UartHandle.Init.BaudRate  = 9600;
 UartHandle.Init.WordLength = UART_WORDLENGTH_8B;
 UartHandle.Init.StopBits  = UART_STOPBITS_1;
 UartHandle.Init.Parity   = UART_PARITY_NONE;
 UartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE;
 UartHandle.Init.Mode    = UART_MODE_TX_RX;
 UartHandle.Init.OverSampling = UART_OVERSAMPLING_16;
 HAL_UART_Init(&UartHandle);

I naively changed it to :

UartHandle.Instance    = USARTx;
 UartHandle.Init.BaudRate  = 9600;
 UartHandle.Init.WordLength = USART_WORDLENGTH_8B;
 UartHandle.Init.StopBits  = USART_STOPBITS_1;
 UartHandle.Init.Parity   = USART_PARITY_NONE;
 UartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE; //<<< ERROR
 UartHandle.Init.Mode    = USART_MODE_TX_RX; 
 UartHandle.Init.OverSampling = USART_OVERSAMPLING_16; //<<<ERROR
 HAL_USART_Init(&UartHandle);

Bummer! the USART init struct that should be superset of all, does not have HwFlowCtl and OverSampling fields - though these features exist in USART IP.

More to this, I will need some AdvFeatureInit bits - but this is also unavailable in USART API.

Another hitch - I don't have cross cable for the serial port, so jumpered it to the onboard ST-LINK v3 VCP.

Then the UART examples don't work at all.

Found that only PARITY=NONE works with this setup. Either EVEN or ODD print gibberish or nothing.

Most examples have PARITY=ODD

Could be error in the ST-LINK v3 on the eval. board ?

Thanks,

Pavel A.

[Piranha]

If even the reference manual for these peripherals has only one unified section USART and presents UART as an USART without some features, then obviously the driver should also be one unified and named USART.

[Amel NASRI · Accepted solution]

Hello @Pavel A.​ ,

The HAL drivers are intended to features. As described in the reference manual, the USART peripheral has 4 different modes: Asynchronous, Synchronous, Irda and SmartCard.

That is why we have 4 HAL drivers:

• HAL_UART (to handle asynchronous communications)
• HAL USART
• HAL_IRDA
• HAL_SMARTCARD

Generally, we have an LL driver per peripheral chapter on the reference manual as the same registers are used to configure the various modes.

This explains why there is only 1 LL driver and 4 HAL drivers, all related to USART peripheral.

This is said, having only one LL_USART driver doesn't mean that we will add an LL_UART or we will merge HAL_UART and HAL_USART.

-Amel

[Pavel A.]

Ok I understand the features argument. But still think that each distinct IP module should have its custom LL driver, unless some IPs are very close and can be unified,