Re: Is blocking I/O possible with 3-wire RS232?
Re: Is blocking I/O possible with 3-wire RS232?
- Subject: Re: Is blocking I/O possible with 3-wire RS232?
- From: Stephen Hoffman <email@hidden>
- Date: Tue, 5 Jan 2010 16:00:11 -0500
On Tue, 5 Jan 2010 09:49:34 -0500, Michael Ellis <email@hidden> writes:
> So, my fundamental question is this: "Is there a way to configure a serial port to disregard the DSR input altogether and still have it perform blocking I/O?"
Digital Equipment Corporation (DEC) boxes and VT-series terminals have used XON and XOFF in-band flow control for eons (DC1 and DC3, respectively), and one of the usual approach for a controller that required DSR/DTR hardware flow control or modem control was to wire the serial connector to feed a false signal into the controller. To jumper signal pins. Off the top and from some very dim memory and presuming DB25 connector pinouts, pins 2 and 3 are transmit and receive and wired either straight-through or crossover depending on the requirements, pins 4 and 5 are jumpered inside the connector, and (if you had enough wires for the end-to-end connection) 6, 8 and 20 were bridged within the connectors and with one wire between the two connectors. (Check that against EIA-232, too.)
Three signal wires (rx, tx, gnd) would work with XON/XOFF in-band flow control, so long as you're not running full binary data down the serial line. I'm aware of a whole lot of serial wiring with four signal wires, and DEC sold a wiring system (DECconnect) based on 6-wire EIA-423 (DEC-423) wiring scheme and modified modular jacks (MMJs).
With in-band flow-control, the size of your read buffer will be sized to and tied to how fast your code can issue an XOFF down the serial line, too. Your write speeds need not get too far ahead of the receiver, too, as you can need to shut off transmit very quickly lest data be lost. With some of these devices, you could dispense with XON/XOFF entirely, as some of the intelligent (cough, dumb, cough) controllers counted characters.
A more recent solution tends to be a terminal server or analogous; to dedicate some hardware to deal with this serial stuff, and to avoid having the host have to deal with XON and XOFF. The host then connects to the hardware via a network path. This might be an Arduino or otherwise, or an IP terminal server.
As for the Mac OS X I/O path here, I'll leave that to others.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden