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