<div dir="ltr"><div><div>> Yeah, although then you create a whole cottage industry of people on the</div><div>> mailing list arguing about which value they feel is best for completely</div><div>> ignorant reasons.</div><div><br></div><div>LOL. You're probably right. Sounds like the voice of experience.</div><div><br></div><div><br></div><div>> What we're talking about here is (apparently) some buggy serial hardware or</div><div>> drivers that bring their own characteristics.</div><div><br></div><div>A buggy dongle that sends characters too fast? Hmm. Maybe the serial dongle</div><div>isn't preserving application timing because of buffering? Now we're back to</div><div>lowering the latency timer. For example: the application sends a record, waits</div><div>for processing, and then sends another record. If the dongle/driver buffers</div><div>across two records, and then blasts out the entire block it could nullify the</div><div>record processing timeout. Lowering the latency timer might help with this as</div><div>it reduces buffering.</div><div><br></div><div>My experience was FTDI chipsets were most reliable in many ways. They responded</div><div>well to a change in the latency parameter I mentioned earlier. Prolific USB</div><div>dongles come in second to FTDI in my experience.</div><div><br></div><div>I'm fairly sure some of the USB dongle experience is its OS driver as much as</div><div>anything. The Linux Prolific driver has a quirk or two. I've had a lot of</div><div>problems with the generic Windows usbserial driver. It seemed to do a lot of</div><div>internal buffering that I couldn't tune out the usual way.</div><div><br></div><div><br></div><div>> The thing I want us to avoid is forcing all users of the driver to send one</div><div>> byte at a time with a lengthy delay just because some people have broken</div><div>> serial hardware.</div><div><br></div><div>I agree completely. That's one of the things I was trying to stress.</div></div><div><br></div><div><br></div><div>-Nathan</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 3:26 PM, Dan Smith <span dir="ltr"><<a href="mailto:dsmith@danplanet.com" target="_blank">dsmith@danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> I do like your idea of creating a throttled serial driver so long as<br>
> users can still opt out of it. Maybe they could even tune the<br>
> throttling with a parameter? This might help some HW without strewing<br>
> sleep() calls all over the place. I want the max speed I can use,<br>
> though. It takes too long to read/write some radios as it is. Don't<br>
> throttle everyone.<br>
<br>
</span>Yeah, although then you create a whole cottage industry of people on the<br>
mailing list arguing about which value they feel is best for completely<br>
ignorant reasons. Seems better to have the driver expose a value that<br>
should be used in compatibility mode, and if one isn't exposed,<br>
calculate a default based on the baudrate.<br>
<span class="gmail-"><br>
> Throttling baudrate completely might be a bad idea in some cases. What<br>
> if a radio needs a relatively high amount of time to "digest" a<br>
> packet/block/line of information? Maybe it reads an entire block, and<br>
> then commits it to EEPROM, for example. Or maybe it decrypts the block<br>
> (slowly). If the time needed to process a block is high compared to the<br>
> time between symbols, you wouldn't want to impose the block timeout on<br>
> each symbol, or the throughput would be much lower than needed; maybe<br>
> painfully so.<br>
<br>
</span>Right, but those are things we _should_ bake into the driver as they're<br>
characteristics of the radio itself. Indeed several drivers have this<br>
sort of thing and it's fine.<br>
<br>
What we're talking about here is (apparently) some buggy serial hardware<br>
or drivers that bring their own characteristics.<br>
<span class="gmail-"><br>
> My experience is most embedded devices don't use XON/XOFF. Even the<br>
> simplest microcontrollers can usually keep up with 9600 baud until they<br>
> try to do something like decryption or writing to EEPROM. Maybe I'm<br>
> wrong here - I've never written firmware for a radio.<br>
<br>
</span>Yeah, I don't think I've seen any that do software flow either, but with<br>
only two or three serial lines, it's the only way to provide back<br>
pressure. Clearly anything should be able to keep up with 9600 baud, but<br>
we do have some that can't although it's mostly at the record level and<br>
not just straight line speed. The thing I want us to avoid is forcing<br>
all users of the driver to send one byte at a time with a lengthy delay<br>
just because some people have broken serial hardware.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--Dan<br>
</font></span></blockquote></div><br></div></div>