stm32f3xx-hal icon indicating copy to clipboard operation
stm32f3xx-hal copied to clipboard

Uart Flow Control

Open FlippievanDyk opened this issue 4 years ago • 3 comments

I have been looking at the serial implementation for some time now, and I wonder is there a plan to expand it to allow Hardware flow control? I am a rust novice, and have no experience working on the implementation side of an HAL.

In my mind, I could use the PAC to activate hardware flow control, and continue using the rest of the crate serial library provided normally. I am unsure if I might be missing something here or if this would cause other issues.

Alternativey, is someone already working on this, or does anyone have advice as to where to get started adding it to the HAL. I wouldn't want to go against the design principles, but the only example I found was in https://github.com/stm32-rs/stm32l4xx-hal. It has quite a few differences in structure, and would probably require refactoring throughout the rest of the implementation. Is there a way around this?

Sorry for the rambling nature of the issue, but I am not sure where to start.

Edit: I took a look at how the initialization of the function works, and I believe that if I set the Hardware Flow control in the relevant UART before starting the rest it will work correctly. I will edit again when I've confirmed this.

FlippievanDyk avatar Jul 31 '20 13:07 FlippievanDyk

Hello @FlippievanDyk ,

The Rust Embedded Book gives a nice illustration on what PACs and HALs are doing. Ideally, the HAL is abstracting on the PAC to control the hardware and you don't need to use the PAC at all.

I'm not sure what you mean by "hardware flow control", but if your goal is to simply get the uart running, check out the example on USB and the recent example on DMA and Serial.

Hope that helps.

strom-und-spiele avatar Aug 06 '20 09:08 strom-und-spiele

Hi @strom-und-spiele

Hardware flow control refers to the CTS and RTS pins. These are typically used to ensure that a high speed UART's buffer are ready to receive and ready to send. As you say, the HAL abstracts the hardware so that the PAC is not required. However, at present the HAL does not seem to be able to control those pins.

I have looked at the DMA example, and got it running, but my application is going to require the CTS/RTS pins to function properly. That said, I've looked at the library, and I have been able to set the uart up to my satisfaction, however it was hardcoded and not general at all. I need more experience with macros to make it easily useable.

I have multiple things to juggle at the moment, hopefully I can look at this properly soon.

FlippievanDyk avatar Aug 06 '20 09:08 FlippievanDyk

Thanks for clearing that up.

To summarize: the f3xx-hal is obfuscating the grouping of the pins in a huge macro. Whereas the l4xx-hal introduces a new trait and impl it for different pin groupings.

I also found my self implementing the RTS/CTS pins for an earlier application by hand. I guess the way it is implemented in l4xx has a better DX.

I'd suggest adding this to https://github.com/stm32-rs/stm32f3xx-hal/issues/122.

strom-und-spiele avatar Aug 06 '20 13:08 strom-und-spiele