usb driver problem

[stephen barncard]

thanks Jerry, I started to explain this - been messing with UARTS since the
late 70s but you did a much better job.
The bottom line is that this stuff is a lot simpler these days with buffers
and most of these handshake lines are not needed today and the voltages
don't have to be +-12 volts which was a PIA. And I've never heard of oDSR
and oDTS either..

On 23 January 2011 00:50, Jerry J <jhj at jhj.com> wrote:

> 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
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  <http://www.google.com/profiles/sbarncar>