Very nice info. Thank you! -=>JB<=-
On Jan 22, 2011, at 10:50 PM, Jerry J 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 > _______________________________________________ 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
