usb driver problem

[Jerry J]

On Jan 22, 2011, at 9:37 PM, Thomas McGrath III wrote:

> The serialControlString seems to be the only way to set things for the serial port connection. Which of these might effect Buffering or cause the port to hang.
> 
> The possible settings are as follows:
> * BAUD=number: the port's baud rate
> * PARITY=N, O, or E: no parity, odd parity, or even parity
> * DATA=numberOfDataBits
> * STOP=numberOfStopBits
> * to=on or off: use timeouts
> * xon=on or off: software handshaking
> * odsr=on or off: (output) data set ready
> * octs=on or off: (output) clear to send
> * dtr=on or off: data terminal ready
> * rts=on or off: ready to sent
> * isdr=on or off: (input) data set ready

OK, here's a short RS232 primer. This is more than you want to know.

First, a bit of history. RS232 specified the voltages, pinout, and signal meanings for the connection between a teletype and a modem. Its STILL making life difficult for us. The spec is for a 25 pin connector. These days its usually a 9 pin or something entirely different.

The acronym for a terminal (teletype) is DTE (data terminal equipment).
The acronym for a modem is DCE (data communication equipment).
These things were slow and stupid. Besides the data lines (TxD and RxD), there are a bunch of hardware signals. 

DSR - Data Set Ready. This means the modem is powered up and connected.
DTR - Data Terminal Ready. The terminal is powered up and connected.
RTS - Request To Send. The terminal wants to send data
CTS - Clear To Send. The modem is ready to receive data

The intention was that DSR and DTR were normally true all the time in a good connection.
The intention was that RTS and CTS were used for hardware handshaking. Remember there were no buffers so there had to be some way to control flow. In reality modern implementations often completely misunderstand these meanings and may, for example require RTS and/or CTS to be true all the time and use only DTR for hardware handshaking. Or any other screwed up mix.

Usually these days, since we now have buffers, none of this hardware handshaking is used and you just have to get the lines that matter true. Your mileage may vary.

Since we have buffers, and computers behind them, the concept of software flow control comes in. This is what XON and XOFF are for. They are ASCII CHARACTERS, not control lines. So when one end or the other is about to fill its buffer, it sends an XOFF character. When its ready for more, it sends an XON. Either device can do this.

On the data lines, the transmitted signals work like this: 
When it all is ready, the line is idle (called space, as opposed to mark).
A start bit goes to mark.
Data bits are sent - marks or spaces (1 or 0). Usually there are 8 data bits.
One or more stop bits go to space. Usually 1. Possibly 1.5 or 2 (I've never seen these).
Then the receiver waits for another start bit.
The word space here refers to a voltage level, way different from an ASCII space character.

Parity is a rudimentary error checking scheme which is usually not used these days. If it is, here's what you need to know, assuming 8 data bits:
N - no parity. All 8 bit times are significant data
E - the parity bit (the eighth one) is 1 or 0 to make an even number of ones, including the first 7.
O - the parity bit is 1 or 0 to make an odd number of total ones in this "byte".

These days N,8,1 is the usual setting. No parity, 8 data bits, 1 stop bit.

Baud is short for bits per second. Bit times are the same for start, data and stop bits. 9600 baud means 9600 bits per second, so if everything is cooking along at maximum speed, there will be 960 characters sent per second (10 bits per character - start, 8 data, stop).

Oh, and there's the RI line (Ring Indicator) if somebody is calling the modem. Forget it. It was used to spin up the teletype motor.

Just to confuse you more, the specified voltage levels on TxD and RxD are +3V for space and -3V for mark (minimum). Volts up to +/- 25 are allowed. Thats right, 0 bit is +V and 1 bit is -V. These days lots of implementations cheat and use +5V and 0V instead. A full spec RS232 will not work with that.

While I'm at it, I should not forget the concept of a null modem. If two devices both act like terminals, the TxD line of one feeds the TxD line of the other (bad), the handshake lines are all crossed (bad), and it won't work. Likewise if two devices both act like modems. To make it work, an adapter or cable is wired to cross the data and handshake lines back to where the other device expects them. At least the TxD and RxD. Unfortunately many commercial null modems have a rather misguided or incomplete concept about the hardware handshake lines and may be wired in bizarre ways.

AAARRRGGGHHH !!!

Now for Arduino and LC, I have no more clues. Use timeouts. Maybe Arduino uses hardware handshake? Maybe software handshake? At least I hope this helps with the jargon.

Good luck,
Jerry Jensen