cancel
Showing results for 
Search instead for 
Did you mean: 

Another question about HAL_UART_Receive_IT

diverger
Associate III
Posted on April 18, 2018 at 15:01

Recently, I've encountered problems with 'HAL_UART_Receive_IT()'. So I go here for solutions. I see several suggestions to put another 'HAL_UART_Receive_IT()' in  'HAL_UART_RxCpltCallback()', but they didn't give which version of cube library they are using. So, I want to know the current status of this function in ST's cube library. Is this solution or 'trick' still necessary? The library I'm using is STM32Cube FW_F4 V1.21.0.

BTW: Hope that anyone who see this question can add the library version or other informations useful to your questions when asking. Because your question may reveal a *bug* in the library, and ST is continuously updating the versions of their library, so the bug exist today may don't exist tomorrow. These may help others with similar problems. And it's better if ST can provide a bug report system.

#uart
1 REPLY 1
Posted on April 18, 2018 at 16:55

The USART implementation in HAL is a bit of a cluster, honestly I'd just stay away from ST's interrupt implementation entirely here, but to each their own.

The reason to put the next interrupt enable in the callback is so you don't miss the next byte, assuming that the data is a continuous stream. The callback is called in interrupt context, so should be short and to the point, not faffing about for multiple byte times parsing and processing, or yielding to other tasks.

>>

so the bug exist today may don't exist tomorrow.

In general I'd be making sure I thoroughly understood the third party code I was pulling in, its interaction with itself and the code I've written, and its behaviour and expectations in the time-domain.

One needs to be cautious about pulling in new code just because it is the latest release.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..