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. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
