4 ms·
In your read loop, when you get data, if it isn't a CR or a NL, change the rate and wait again. You probably don't need to cycle through them all, just the mos
by linsomniac 9y ago
In your read loop, when you get data, if it isn't a CR or a NL, change the rate and wait again. You probably don't need to cycle through them all, just the most common options like 9600, 19.2K, 115K... Depending on what you read and what speed you are at, you may be able to make more intelligent choices (a CR sent at 19.2K when you are on 9600 might look like this or that).
- mschuster91 9y agoHmm, that would be an interesting implementation idea, however the ProCurves seem to be doing this in hardware as your algorithm would require up to 6 CR presses in the worst case and the ProCurve always needs exactly two... and how do I get to modify the readline implementation of (I presume) the kernel?
- linsomniac 9y agoAre you SURE they do it in hardware and not switch software? I'd bet it's in software somewhere, but the question I was trying to answer was related to how to get Linux to do it. At 115.2K, you can probably do it in two CRs, if you look at the data you see. My recollection is that if you have a rate mismatch you often get garbage characters. Just simply the number of garbage characters you get could indicate where you need to change rates to. Like, if you get 10 characters try going to 9600, if you get 5 try going to 19.2K. Just simple timing of how long you get characters might be a good representation of the speed. I don't really have any serial gear or cables handy, or I'd probably try whipping a Python program together to see if I could do it.