Open qwerty19106 opened 4 months ago
Availability is there a reason why Uart::Config no have fifo: bool field?
The reasoning was, there's very little reason to not want a FIFO. Having a FIFO is just better: it makes things faster, less likely to lose bytes if you have irq delays, etc. You might think if you don't enable the FIFO you don't have to worry about flushing etc, but that's not true. You still have a 1 word "FIFO" which is the DR itself, so you can still have problems if you don't flush correctly.
Possible blocking_flush should use TXFIFO Empty flag if FIFO is enabled.
If flush()
is returning before the fifo is empty with the current code then yes, definitely.
Why async flush() use blocking_flush? I think we should wait Transmission complete interrupt or TXFIFO empty interrupt
No one has implemented async flush yet, so it uses blocking flush for now, since it at least works even if not optimally. A PR fixing this would be welcome.
Now FIFO is always enabled for
usart_v4
.https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/src/usart/mod.rs#L1407
I use
Uart::new_half_duplex
on chipSTM32G030C8
(usart_v4
). I send ~16 bytes and then read to IDLE:But due to
w.set_fifoen(true);
I get ~7 bytes which send overuart.write
.Uart::Config
no havefifo: bool
field?blocking_flush
should useTXFIFO Empty
flag if FIFO is enabled.async flush()
useblocking_flush
? I think we should waitTransmission complete interrupt
orTXFIFO empty interrupt
https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/src/usart/mod.rs#L1564
I am ready to write PR about each point if it will clear how it should work.