-
Notifications
You must be signed in to change notification settings - Fork 67
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
Comments
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. |
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. I have multiple things to juggle at the moment, hopefully I can look at this properly soon. |
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. |
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.
The text was updated successfully, but these errors were encountered: