Phil Elwell
Phil Elwell
Your results are consistent with FIFO overflow - when data is received while the UART RX FIFO is full the UART sets the overflow flag and drops the data. The...
The FIFO is in the UART hardware, so there is no possibility to increase its size. I'm not convinced that writing your own driver is going to help significantly -...
Note that flow control might help you if the sending device has some additional buffering beyond whatever UART FIFOs it might have - the problem for the receiving Pi isn't...
In fact it's better than that - the latency tolerance of a flow controlled system is based on the total size of the FIFOs on both sides (for the direction...
ttyAMA0 has a dedicated clock, so doesn't suffer from variable baud rates. What is the sending device? Do you have a ground connection between the two?
The clock of UART1 (which appears as ttyS0) is dependent on the VPU core clock. The firmware should prevent the core clock from changing if UART1 is enabled in the...
`(stty 9600 -echo -icrnl; cat)
I wonder if something else is holding the UART open. Try this: ``` $ sudo apt install lsof $ sudo stty -F /dev/ttyAMA0 9600 -echo -icrnl $ lsof /dev/ttyAMA0 ```
It's strange that ttyS0 is better than ttyAMA0 - in my experience the break detection (and therefore synchronisation) is better on ttyAMA0. It's also strange that you are the first...
> I'm sending 24 bytes every 8ms at 8Mbaud That's a higher baud rate than we've ever used. I'm kind of surprised the clock tree works. > the PL011 experiences...