2017-05-23 07:36 AM
I'm preparing to implement an STM32 project that does high-speed async serial communications, and needs to send and receive variable-length messages. My receive messages are characterized in that they are *always* continuous byte streams on the serial line, with no inter-byte gaps; when the RX serial line goes idle, the message is complete. Because the bit rate is high, I prefer to use DMA for TX/RX message handling. I've written code to do this task before, and I know exactly how to set up the USART, DMA, and interrupt handlers to do the job.
It would be great to use the CubeMX HAL's UART routines for this project, BUT they have an essential lack here: They don't provide handling for the UART_FLAG_IDLE interrupt flag in HAL_UART_IRQHandler(). This means that DMA receive operations using the HAL routines are limited to fixed-length messages, because there is no way to handle the RX idle interrupt that is generated when the last byte of a short message comes in.
I have three equally unappealing options in this case: 1) Continue rolling my own UART support code outside the HAL framework, replacing the hal_usart module for each new target MCU I write for, and creating an integration headache; 2) Hack a local copy of the hal_usart module to add the feature (again, for each target MCU I write for), creating maintenance headaches; or 3) give up on USART DMA receive operations, creating a potentially unacceptable performance bottleneck with all that USART polling or IRQ overhead.
A quick browse of these forums and others like StackOverflow tells me that a number of other developers have faced this same issue, so there's a decent chance this feature will be generally useful.
Here's the specific feature I'd like to see added to the hal_usart drivers:
With this addition, it should be possible to use the stock HAL routines to manage variable-length RX messages while preserving the efficiency advantages of DMA.
I'm going to try hacking a copy of the hal_usart driver to add this feature, and if it's wildly successful, I'll post it as an update for the curious.
#feature-request2018-09-11 10:28 PM
Any news on this feature?
2018-09-16 12:17 PM
This is a much needed feature, as well as a packet detection method like CR/LF detection or $ and *xx for GPS etc.
2018-09-16 01:21 PM
>> packet detection method like CR/LF detection or $ and *xx for GPS etc
No it doesn't, where do people learn how to code minimally simple tasks these days? You get an interrupt on every character, a high school kid should be able to code that state machine. SMH
2018-09-18 02:03 PM
:thumbs_up:
2018-11-08 10:26 PM
I also looking forward to this feature. Any news on this one?
2018-12-05 05:00 AM
+1 on this request. Although easy to implement the simplistic approach proposed above, it still may be a source of issues when upgrading HAL versions
2018-12-05 06:15 AM
You're always going to have issues upgrading HAL, even from ST releases, and especially if they entirely change the paradigm, see the "New" CAN for a prescient example.
I'm not sure of any project that can survive an 18-month dependency on a vendor vs a refactoring task that might take less than a day across a whole slew of HAL / parts for a clean/concise implementation. There are about 3 USART implementations across 11+ years of silicon. The HAL USART code is already a rats nest and bulky, robust software does not come from doubling down on that, and it's patently clear ST doesn't rigorously test all the code paths or do regression testing.
2018-12-05 06:29 AM
Thanks for the heads-up, I'll try to avoid upgrading HAL then :) Or at least do a full diff between versions to see how it impacts my application
2019-07-08 06:51 PM
I managed to get this working relatively painlessly within the STM32CubeMX/HAL framework (without changing the driver). Thanks to Tilen Majerle and Lix N. Paulian.
2019-10-04 10:32 AM
The STM32L4R5 also supports a 16-byte hardware FIFO that is completely ignored by CubeMX. This would not be needed if the serial port library supported the IDLE detect, or receiver timeout better.