Add support for USART hardware flow control - #269
Conversation
| pub fn disable_cts_throttling( | ||
| self, | ||
| ) -> (Tx<I, Enabled<W>, NoThrottle>, Function) { | ||
| interrupt::free(|_| { |
There was a problem hiding this comment.
Not sure if you're planning to change that later, but this currently isn't needed, since we're only changing the cfg register in the Usart enable function and in Tx stuff. I'd also prefer if users have the option to supply the cs separately, in case they know better (e.g. when using rtic) & not disabling interrupts via magic, but there are definitely cons to that approach as well.
There was a problem hiding this comment.
Even if we could do without a critical section here, I don't think we should, unless we're very sure the API is no longer going to change much. It's way too easy to make a change elsewhere and invalidate the assumptions made here.
Having the user supply the critical section token is an interesting idea. I'll look into it later. I'm a bit concerned how the move required by this API is going to interact with an interrupt::free closure at the call site, but I think it shouldn't be a problem.
This is necessary to support repeated enabling and disabling of that function. Otherwise the SWM function could not be returned again without runtime overhead.
They are no longer unused.
It is no longer unused.
|
Rebased on top of master. No changes were necessary. @david-sawatzke: I thought a bit about your suggestion to have the user pass the critical section token. I think that's definitely better, but it's one more thing that complicates the API and needs to be documented. I then considered to accept the token in an In the end, I took the easy way out and decided to leave it as is (you already approved it, after all). I would welcome a future improvement here, but think for now it is fine. The critical section is really short, so the impact is minimal anyway. |
2 participants
No description provided.