usb driver problem

Sun Jan 23 02:13:57 EST 2011

Also in the 80's I used this hardware device that  worked well for my tape
copy project at A&M studios  the CY233 intelligent controller
chip<http://www.controlchips.com/cy233.htm>
.

On 23 January 2011 01:11, stephen barncard
<stephenREVOLUTION2 at barncard.com>wrote:

> 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>
>
>

-- 

Stephen Barncard
San Francisco Ca. USA

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