> Use a different protocol or hardware implementation as having to be > forced to ensure that UART flows actually work that fast is going to be > very difficult for you to guarantee. Just think, how do you know that > once the UART gets your byte, that it will not just sit around and wait > before it actually sends it out (hint, there is no such guarantee). Thing is the timings are tunable and protocol is tolerant to message loss. Tighter timings give me better latency, but higher loss. So it's about tradeoffs and finding the sweetspot. Actually i've already implemented this in userspace using N_TTY and it works. But i am experimenting with the timings and i would like to see how tight i can get by implementing this as custom ldsic instead of using N_TTY ldisc. Just trying to squeeze couple extra microseconds out of this. Originally this was running on microcontrollers and since those run realtime OS, i was easily able to achieve 10x lower latency than with N_TTY. I don't expect Linux with usb-serial dongle to perform same as realtime OS with integrated UART peripheral, but i am pretty sure i can get to being 5x slower instead of 10x slower when compared to uC... I am not very experienced with interrupt contexts of high precision timers and similar stuff, so i would be happy to learn how to handle such situations in general. Not just for sake of this experiment i am doing. T.
