Skip to content

Serial: Sending break condition #190

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

Open
dbrgn opened this issue Mar 6, 2020 · 3 comments
Open

Serial: Sending break condition #190

dbrgn opened this issue Mar 6, 2020 · 3 comments

Comments

@dbrgn
Copy link
Contributor

dbrgn commented Mar 6, 2020

It seems like an embedded-hal driver cannot issue a USART break condition using only the embedded-hal serial trait, right?

A break condition is signaled to the module by keeping the UART_RX pin
low for longer than the time to transmit a complete character. For example,
at the default baud rate of 57600 bps keeping the UART_RX pin low for 938
us is a valid break condition, whereas at 9600 bps this would be interpreted
as a 0x00 character. Thus, the break condition needs to be long enough
to still be interpreted as such at the baud rate that is currently in use.

Also, in Wikipedia: https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter#Break_condition

It seems that a HAL would have to reconfigure the pin as GPIO output pin, pull it low for a certain duration (depending on baudrate), then reconfigure it as serial pin again.

Would it make sense to add a BreakCondition trait to the serial module?

trait BreakCondition {
    type Error;
    fn send_break_condition(&mut self) -> nb::Result<(), Self::Error>;
}

(Edit: Updated to take &mut self instead of self)

@jonas-schievink
Copy link
Contributor

IMO taking self by value to work around limited HALs is not a good idea. HALs should consider implementing something like this API instead: stm32-rs/stm32l0xx-hal#74

@dbrgn
Copy link
Contributor Author

dbrgn commented Mar 6, 2020

@jonas-schievink good call, I updated the proposal.

@jonas-schievink
Copy link
Contributor

Okay, that wouldn't work with a nonblocking API I suppose

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants