Implementing Interrupt driven Stream UART Rx Handling with STM32CubeMX drivers

[Kent Swan]

Posted on January 09, 2018 at 17:38The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Andrew Neil]

Posted on January 09, 2018 at 23:03

This looks to be a blog post rather than a question ?

[Bogdan Golab]

Posted on January 09, 2018 at 23:12

Maybe we should maintain special section with basic information / advise / faq to avoid basic questions and collect good practices...

[Kent Swan]

Posted on January 09, 2018 at 23:54

Not sure on this because I couldn't find any place where well documented issues could be easily submitted to the HAL/CUBE development teams. The main issue is getting around incomplete and problematic library implementations of which I've found a few. 

[Pavel A.]

Posted on January 10, 2018 at 01:57

Maybe just use LL UART driver instead of HAL. I've also started with HAL everywhere, but quickly come to understand why more experienced folks here prefer LL drivers. Simple beats complicated.

-- pa

[Kent Swan]

Posted on January 10, 2018 at 19:09

Wouldn't it be better if the HAL drivers were evolved to properly handle the modalities needed for everyday work for instance:

a. block transfer IS NOT the expected normal historical use form of a UART/USART async serial port.  The standard normal historical form of an aysnc port once configured supports continuous asynchronous stream flow in both directions until disabled.  The per character interrupt call back supports this.  The supported buffering allows both fifo and block burst transfers without compromising the sleep modes of the processor.  My conclusion that this missing functionality should be a normal UART/USART option for the driver with its own predictable call back functionality.  Please note that the tweak/fix of this post was implemented only for the L4 processors though it applies to all STM32 versions. A general update would correct the libraries for all STM32 models.

b. On a related missing functionality, the USB CDC driver lacks a transmit complete callback (eg peripheral to host direction).  This forces polling of the txStatus which prevents the proper handling of interrupt transfers from a transmit queue.  This missing functionality should be added to all relevant STM32 HAL library implementations.

c. I have be unable to locate a callback when USB Charger determination functionality is enabled on the STM32L series processors.  The lack of this prevents us from adapting our charging circuitry for normal vs high rate charging.

Perhaps this entire reply should be moved into the forum as a question.

Kent

[Tesla DeLorean]

Posted on January 10, 2018 at 21:19

>>Wouldn't it be better if the HAL drivers were evolved to properly handle the modalities needed for everyday work for instance

It would have been better if someone had thought through practical use cases before they coded it, but they didn't.

I think we've end up with a ridiculous level of abstraction and interplay for something that can be handled cleanly in an IRQHandler

[Kent Swan]

Posted on January 11, 2018 at 20:29

I have to totally agree.  The key factor here is the ability the application programmer to implement a specific processing behavior to underlying and correct device drivers and their ISR's by instantiating the appropriate __weak attributed callbacks.  This assures that the base driver operates in a predictable manner in the unextended mode.  Further the behavior of drivers from the perspective of the application programmer should be consistent (ie transfer completion vs intermediate data ready) .

Overall I cannot fault the theory and base implementation of CubeMX's fundamental approach. The driver faults, as you've noted are basically incomplete implementations based on failure to properly consider the normal use cases.  Additional faults are related to the libraries not implementing a clean mutex atomic HAL locking function.at the driver level that can be used with or without the RTOS.

[David Pekin]

Posted on February 03, 2018 at 00:56

Thanks Kent & Clive.  I've run into the same issue trying to get a quick development head start using the sample programs as a starting point.  (The I2C sample is the same in that it transfers fixed size blocks back and forth.)  Now, I'm starting to work on implementing a serial handler and came upon your post.  The sample I've started with is the UART_TwoBoards_ComDMA example for the STM32F722ZE Nucleo board which has the fixed size limitations. 

I have a fairly tight main loop in my application and I'm wondering how difficult it would be to manually check the UART handle's RX status every time N times around the loop and simply transfer whatever bytes that are in the RX buffer into my own ring buffer for processing after a full command is received. Simplistically speaking,  I'd like to start the UART receive when the system comes up and never terminate or touch it, except to pull received characters from it.  The sample code's transmit function works fine for me since I'll have a package of known size to send.  

Any thoughts or pointers?  Also, your method may work for what I need.  I need to study it a bit more before making a decision on what way to proceed.

Thanks,

[Tesla DeLorean]

Posted on February 03, 2018 at 02:07

>>

I'm wondering how difficult it would be to manually check the UART handle's RX status every time N times around the loop..

Really easy, infact reading the register and testing the bit is probably as quick as counting the iteration each time it loops around.

if (USART_GPS->ISR & USART_ISR_RXNE) // Received character?

{ char rx = (char)(USART_GPS->RDR & 0xFF);

...

}

https://community.st.com/0D50X00009XkVxKSAV