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 <stephenrevoluti...@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 <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> > > -- 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
