HAL_UART_Transmit BUG???

[MVill.6]

When using HAL_UART_Transmit you normally give a timeout.

If Transmission time exceeds Timeout the function exits with HAL_TIMEOUT.

There're two issues with this approach:

1) Timeout should be retriggerable i.e. if I transmit 20 bytes @ 9600Baud an put a timeout of 10 I expect a timeout not just after 10ms because my transmission takes longer but only if between two successive bytes there's a delay longer than timeout

2) All Interrupt bits are cleared. Why? Even RX for example. TX may fail (it shouldn' t )but why I should reinitialize the UART from the beginning.

Thanx

[Bob S]

Using a library means adapting to the mindset of the creators of that library. So it is with HAL, with all its benefits and limitations.

For (1), yes the timeout parameter is poorly documented in the function header and HAL documents ("timeout duration" is obvious yet still ambiguous and not at all helpful). But a quick look at the code (as you've already seen) is that ST chose to define "timeout" as "max time to send entire buffer". While that doesn't match your expectations, it is what it is. Adjust accordingly - if you do not have CTS/RTS enabled, just make the timeout HAL_MAX_DELAY and be done with it.

For (2) does sound a bit strange. I'll hazard a guess that the HAL designers presume if the polled tx (or rx) operation times out there is a fatal error with the UART or interface (if hardware handshake is enabled) so it terminates everything. And HAL is not designed to have polled RX and TX used simultaneously, so not an unreasonable assumption. And perhaps the thinking was that if someone is using polled TX they wouldn't be using IT/DMA RX. Or just lazy and didn't want separate "wait on flag" functions for RX and TX. But if you address (1) then this isn't an issue.

[S.Ma]

Timeout sometimes complexify simple things. Uart transmission has no reason to fail. Data to transmit should come from a sw fifo or equivalent in simple case.

[victagayun]

Can you time out for the whole data transmission instead? How long will it take you to receive all 20 bytes?

OR can you use DMA instead?

1. Configure and reset a flag before transmission
2. in DMA int (or callback), set the flag
3. Delay for 10mS (your timeout)
4. check the flag if set, else not transmitted

DMA also makes the transmission faster, the space between chars is at a minimum.

[MVill.6]

I agree with the fact that a TX without RTS/CTS can't fail anymore.

And I also agree that HAL developer should pay more attention when writing the routines.

It's true that HAL is just a reference but in many cases, when timing is not an issue

and time to market is the main constraint they could be very useful

[S.Ma]

Actually, uart is the one peripheral that calls for LL instead of HAL because my message packets are of unpredictable length (as consoles do) and HAL API are built with packet size passing parameter maybe to match a DMA HW operating mode rather than a byte interrupt simple implementation.

[Piranha]

The HAL vs LL choice is just terrible. There is no objective reason why a high level API would not be able to handle a stream interface. You can see an example in my post there:

https://community.st.com/s/question/0D53W00001RiIo1SAF/stm32f407-haluartexreceivetoidle-function-missing

The only reason why the HAL cannot do it, is because it's developers do not understand the necessity and are incapable of designing it.