Open mithro opened 7 years ago
I assume you mean on the Opsis board?
This will be improved (but not totally eliminated) by the FX2 code refactor at https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/149
We can't implement hardware flow control as the pins needed are not connected. Software flow control wouldn't fix the problem you are encountering either, as cat wouldn't use it.
The Debconf video team had this problem on the opsis boards. Our work-around was to send each character slower (using a python script if I recall)
im curious about 2 things.
the 'right' fix is to implement something that can consume the input faster than it is coming in, right?
how does baud rate affect this? is 115200 enforced, or how is that number relevant?
The best solution at the moment is to use hdmi2usbd as it also solves the problem of having multiple people connected to the serial port.
I understand we have a solution, but, I'd like an answer to my questions so that I have enough understanding to be able to talk intelligently to people who might be interested in working on it.
and I am just curious.
man cstream — direct data streams, with bandwidth limiting, FIFO, audio, duplication and extended reporting support.
printf "video_matrix connect pattern encoder\r" | cstream -t 60 -b 1 > /dev/ttyACM0 Connecting pattern to encoder
From @CarlFK on March 22, 2016 5:50
When I send characters too fast, most of them get dropped.
I think the problem was described as: there is no flow control.
Seems like there have been more than one work around.
Can this be fixed on the device side?
Copied from original issue: timvideos/HDMI2USB-litex-firmware#219