| Forum Home | ||||
| Press F1 | ||||
| Thread ID: 43911 | 2004-03-31 10:58:00 | USB to Serial Convertors | Billy T (70) | Press F1 |
| Post ID | Timestamp | Content | User | ||
| 226243 | 2004-04-01 03:01:00 | The handshaking is what I mentioned as "jumpering", Billy. I just went to Google to remind myself of the pinouts, so: for a 25 pin connector, link 4&5, 6&20 (and possibly 8 as well). That's (RTS to CTS) and (DSR to DTR [to CD]) . For a 9 pin connector: (7&8) and (6&4[&1]). That's assuming that the equipment uses software handshake. That leaves 2 & 3 for TxD and RxD or (3 & 2 ;-)) and 7 (or 5) for signal ground. | Graham L (2) | ||
| 226244 | 2004-04-01 03:33:00 | Expand? By the time IBM produced the PC, computers had been using RS232 for terminals for quite a few years . RS232 was made for data communications . . . before there were many computers . The standard caters for all sorts of things . . . various forms of hardware and software handshaking for character by character I/O . The RTS, CTS, DTR, DSR, CD are intended for modem control . The terminal connections to computers were usually through modems but even so, for a number of reasons, software handshake was easiest . Most practical systems used 3 wires to connect to the modems . Occasionally a console terminal (direct connected to the CPU box) would use RTS/CTS or DSR/DTR . This was fun . ;-) I've seen a book with several hundred pinouts for "RS232" cables, as various manufacturers read the standard . And improved it . IBM's designers seem to have read the RS232 standard . They decided that the IBM was a Data Set (a modem) rather than a Data Terminal ( a terminal) . (I think that it is that way . ;-)) They decided that they would pull DSR (dataset ready) high, and expect DTR (data terminal ready) to acknowledge that if something was there . They also used the CTS as an acknowledgement to RTS from the device . If the signals weren't there, the DOS handler for the serial ports wouldn't work . So simple people just connected the pins and used cheaper 3 wire cable . :D And/or wrote their own code to ignore the status bits . ]:) . The beauty of the RS232 is that it's hard to damage the interface chips with reasonable levels of abuse . You can short any of the lines to any others, connect two TxD lines together and drive them in opposite directions, with complete impunity . You won't communicate, but when you get the connectsions right, it will work . So you can make a plug produce the acknowledge signal to any prompt by connecting the two pins together . So CTS is raised by a receiver . . . it wants RTS from a sender to say it's there and ready . We connect the pins, and it's got the resoonse . ;-) . DSR is set and the receiver wants to see DTR . We connect the pins . Then the software waits for Ctrl/S -- Ctrl/Q (or some other combinations ) to say stop/go . Modern UARTs handle this nicely, because they have buffers, and can store characters . They tell the sender to stop, wwhen the buffer gets a but full . They tell the CPU when it has characters, and can tranfer a lot of characters in one go . (The original PC had the worst possible UART . . . no buffer at all . That's why the maximum practical speed on a PC was 9600 . The CPU was spending all its time reading characters one at a time . ) |
Graham L (2) | ||
| 226245 | 2004-04-01 05:51:00 | > > One thing was very clear from my research, the USB > > devices REQUIRE handshaking to work properly . > > So how do we ensure that handshaking takes place? Normaly it is transparent, the USB dongle will use it to regulate the dataflow from the connected serial device . In the driver it will emulate the handshaking to control the flow between the USB dongle and the PC . As far as I could tell the serial handsaking lines on the USB dongle where not controlable from the host application . > > I have now completed some fairly intensive research > and it appears that some users have achieved reliable > DOS connectivity with legacy devices using a dos > emulation box under the USB com port properties . > There is a distinct lack of "how to" involved and it > appears that some application-specific software may > have been written in one case to set up the > interface . The problem is the latancy introduced by the USB< > Serial process . In applications where they allow some genrous character time-outs, i . e . 1sec or more, you can usualy "fudge it" > > The problem is recognised and solutions appear to > exist, but I haven't located anything solid enough to > invest any more time on yet . It also appears that > there are only five or so manufacturers of USB to > Serial convertors and just about everything I found > looked like a house branded example of one of those 5 > except for DSE and Radio Shack . If you can set the time-outs in your applications you may be able to work around the issue . > > What I have discovered is that there are a > number of non RS232 compliant serial ports around, > some predating USB, with voltage swings as low as +/- > 5 volts instead of +/- 12 volts (or so they say) . > Only one brand of USB to serial adapter claims full > compliance with the RS232 spec so that looks like a > promising product to buy . Found that too, I toasted a few with 13volts!!! > > One of my instruments is very picky indeed about > interface conditions, so much so that it will not > work at all on my Libretto 50CT on batteries but > works every time on mains power . I had a similar > problem on my old 486 which had two cards and four > ports . It would only work reliably on one card and > there was a 75% failure rate on the other . > > By chance the compliant model is available from a > local retailer :D so I can try it and see, and return > it if it doesn't work . I guess I could even try it > in-store if they'll let me . > > Cheers > > Billy 8-{) > |
ugh1 (4204) | ||
| 1 2 3 | |||||