You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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
Uh oh!
There was an error while loading. Please reload this page.
It seems like an embedded-hal driver cannot issue a USART break condition using only the embedded-hal serial trait, right?
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 theserial
module?(Edit: Updated to take
&mut self
instead ofself
)The text was updated successfully, but these errors were encountered: