[chirp_devel] [PATCH] [New Model] Add Support for Retevis RT23 Radio

[Dan Smith]

> I do like your idea of creating a throttled serial driver so long as
> users can still opt out of it.  Maybe they could even tune the
> throttling with a parameter?  This might help some HW without strewing
> sleep() calls all over the place.  I want the max speed I can use,
> though.  It takes too long to read/write some radios as it is.  Don't
> throttle everyone.

Yeah, although then you create a whole cottage industry of people on the
mailing list arguing about which value they feel is best for completely
ignorant reasons. Seems better to have the driver expose a value that
should be used in compatibility mode, and if one isn't exposed,
calculate a default based on the baudrate.

> Throttling baudrate completely might be a bad idea in some cases.  What
> if a radio needs a relatively high amount of time to "digest" a
> packet/block/line of information?  Maybe it reads an entire block, and
> then commits it to EEPROM, for example.  Or maybe it decrypts the block
> (slowly).  If the time needed to process a block is high compared to the
> time between symbols, you wouldn't want to impose the block timeout on
> each symbol, or the throughput would be much lower than needed; maybe
> painfully so.

Right, but those are things we _should_ bake into the driver as they're
characteristics of the radio itself. Indeed several drivers have this
sort of thing and it's fine.

What we're talking about here is (apparently) some buggy serial hardware
or drivers that bring their own characteristics.

> My experience is most embedded devices don't use XON/XOFF.  Even the
> simplest microcontrollers can usually keep up with 9600 baud until they
> try to do something like decryption or writing to EEPROM.  Maybe I'm
> wrong here - I've never written firmware for a radio.

Yeah, I don't think I've seen any that do software flow either, but with
only two or three serial lines, it's the only way to provide back
pressure. Clearly anything should be able to keep up with 9600 baud, but
we do have some that can't although it's mostly at the record level and
not just straight line speed. The thing I want us to avoid is forcing
all users of the driver to send one byte at a time with a lengthy delay
just because some people have broken serial hardware.

--Dan