Gene Heskett wrote:
On Wednesday 02 July 2008, Mikkel L. Ellertson wrote:
Gene Heskett wrote:
My old Garmin 12 (yeah, it has gray hair) has a very dumb serial
interface, so I have to use an adapter to make it usb.
And there are no intermittent connection problems?
Maybe Prolific has quietly fixed that bug in later issues. Mine are 5 or
6 years old, one I got from the shack, and another I got from Wallies a
year or so later. Both of them have been problems. I tried to use one to
connect to a ups, but every time it dropped the connection, the ups
monitor initiated a shut down about a second later. Several times a day.
That, and glancing over at the roadnav screen while in western Iowa, and
noted it showing me in downtown Indianapolis IN for 30 seconds just got to
be too much. I moved one of them to the heyu circuit, that gave heyu a
tummy ache & it would segfault & die. I asked Charles on the heyu list &
he said I wasn't the only one having trouble with pl2303's, and he was
telling folks to go get the FTDI devices as they seemed to Just Work(TM),
and they have, very well, as have the Atmel silicon in a pair of extension
cables I use.
By intermittent connection problems, do you mean that it would drop
characters? One problem I have run into is where the flow control
lines are not implemented. If the hardware and/or application are
set up to use hardware flow control, this can cause data loss. I
don't know if this is the case here.
Mikkel
In the case of roadnav, the serial speed is about 1/100th the usb speed, so
there should not even be a need for flow controls. AFAT pl2303 is concerned,
in my tests, trying to run a minicom terminal here, to a serial port on a
TRS-80 Color Computer 3, (aka a coco3) running nitros9, using a 9600 baud
connection rate, and Chuck Foresberg's rzsz to move files. With a pl2303 doing
that adaptation, I could type by hand from either end and see it perfectly.
Fire up a zmodem transfer, and the data got so scrambled that zmodem eventually
gave up on a 12 byte file! The rz implementation on the coco3 actually
checksums each character as rx'd into the total for a 128 byte packet, but this
restricts the coco3 to about 700cps.
I tried every flow control method, but with the coco3 acia chip only having a 1
byte buffer, and the coco3 was exerting the 7 wire protocol (with xon/xoff,
control is too slow) that I could see on an rs232 sniffer was working, but the
pl2303 was apparently ignoring. Conversely, a transfer from the coco3 to here
got scrambled even though this box takes naps between bytes received. I could
only come to the conclusion that the pl2303 was a $40 POS. Add in its poor
showing with heyu, roadnav and 2 different UPS's and any reasoning person will
reach the same conclusion.
Now I've moved an FTDI adapter to that circuit, and while there are errors that
make rz do resets & restarts on the larger files, it will eventually get the
file moved with no errors in the file. I think those are because I don't have
the 7 wire properly configured on the coco3, I believe it is here on this box
although stty's nemonics nomenclature is a bit foreign to me & the manpage
quite frankly, is all but worthless. A manpage should have demo cli examples
for eol translations and for the two 'std' flow mechanisms in common use. No,
instead it explains each option in excrutiating detail, taking up 4 or 5 pages,
which is info overload IMO to me.
Experts at rs232 protocols are, like me at 73, a dying breed, so there are few
to ask about it in this world, and I might get 1 or 2 fingers used counting
them in the coco3 world, very scarce and memories are fading. Since the coco3
& os9 (a mini unix) precede google by over a decade, googling is not the help
it could be.
Shades of the old Telebit Trailblazer running the serial at 230400 bps
to keep compressed data flowing and using RTS when the data you were
sending didn't compress enough.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
