Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uart Flow Control #128

Open
FlippievanDyk opened this issue Jul 31, 2020 · 3 comments
Open

Uart Flow Control #128

FlippievanDyk opened this issue Jul 31, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@FlippievanDyk
Copy link

FlippievanDyk commented Jul 31, 2020

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.

@strom-und-spiele
Copy link
Collaborator

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.

@FlippievanDyk
Copy link
Author

FlippievanDyk commented Aug 6, 2020

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.

@strom-und-spiele
Copy link
Collaborator

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 #122.

@Sh3Rm4n Sh3Rm4n added the enhancement New feature or request label Dec 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants