0
\$\begingroup\$

I'm looking for an integrated circuit that can connect a lpc17xx (microcontroller) to the serial port on the back of a standard computer. The lpc17xx has a UART controller with 8 pins.
RXD
TXD
CTS
DCD
DSR
DTR
RI
RTS
I'd like to use them all. I figure if NXP decided to implement all those pins, not just RX and TX then they should be useful...anybody know why? Flow control?

The microcontroller runs at 3.3v volts and I wasn't able to find a max232 type part that has 8 channels at 3.3v.

I suppose I could just use RX and TX if there is really no difference, but if nothing else my circuit could look way cooler with more wires :P

thanks.

EDIT: Are they called drivers or transceivers?

\$\endgroup\$
3
  • \$\begingroup\$ Your not trolling for Olin are you? If he's awake you can expect a bite anytime :-). \$\endgroup\$
    – Russell McMahon ♦
    Jan 3, 2012 at 6:43
  • \$\begingroup\$ One downside of connecting so many pins to serial transceivers is that you loose the ability to use those pins for other purposes - if not assigned to a serial function they are general purpose I/Os, and may even have additional special function options. \$\endgroup\$
    – Chris Stratton
    Jan 3, 2012 at 15:32
  • \$\begingroup\$ You'd like to use them all? Like RI, that's Ring Indicator, when the phone connected to the modem rings? \$\endgroup\$
    – Federico Russo
    Aug 13, 2013 at 12:35

4 Answers 4

Reset to default
1
\$\begingroup\$

If you wish to use all eight signals, you can use MAX3243E. It is quite similar to MAX232 but it gives you 5 receivers (CD, RXD, DSR, CTS, RI) and 3 drivers (TXD, DTR, RTS).

  • RXD and TXD are data.
  • DSR, CTS, DTR and RTS are for flow control.
  • CD and RI are just indicators and generally almost never used (except for modems).
\$\endgroup\$
1
\$\begingroup\$

For hardware flow control you only require 4 signals - sent data, received data, send control and receive control.

As there are 2 different flavours of hardware flow control, it would appear that NXP have decided to be flexible and cover them both - it's up to you which you decide to implement:

  • DSR/DTR - Data Set Ready / Data Terminal Ready
  • CTS/RTS - Clear To send / Request To Send

Also, there are other signalling connections for raising alerts at either end:

  • RI - Ring Indicator - used by modems to indicate the presence of a ring tone
  • DCD - Data Carrier Detected - used by modems to indicate the presence of a data carrier - i.e., it is connected to the remote end.

So you can do hardware handshaking with just RXD/TXD and either CTS/RTS or DTR/DSR - you don't need to implement both. The others are only of any interest if you are connecting to a modem (or maybe emulating a modem - I don't know the direction of those signals on that chip).

\$\endgroup\$
1
\$\begingroup\$

The data is tranferred over RXD (receive) and TXD (transmit). RTS (request to send) and CTS (clear to send) are used for optional "hardware" flow control. I disagree with Majenko in that DSR/DTR are not used for flow control. Like the other remaining lines, these were used for old fashioned external modems. The extra lines would tell the computer when the phone was on/off the hook, whether it was ringing, whether the modem had "carrier", etc. Basically ignore all those lines.

RTS/CTS can be handy for flow control, but keep in mind they are only sparesely implemented by other devices. PCs can be made to use them if the software sets up the port that way. Unless the program you want to communicate specifically says it uses RTS/CTS or "hardware handshaking", you should assume it doesn't. That means it sends characters whenever it feels like.

Another issue to watch for with hardware handshaking is that just because you tell a PC to stop sending, it may still send up to 16 characters before it actually stops. Some implementations only cause the driver to stop sending characters to the UART hardware, which has a 16 byte buffer it will continue to empty. When talking to another PC this is no problem since the other side will have much more than a 16 byte input buffer. If you're on a small micro, you have to make sure you can tolerate that.

What I do is in the general case assume I have only a bi-directional stream of bytes without any out of band signalling like RTS/CTS. If I need to make sure the micro doesn't get overrun, I build that into the protocol. For example, the host may not be allowed to send a new command until some ACK is received for the previous. Lots of schemes are possible.

By assuming the only channel with the remote device is a bi-directional stream of bytes, it allows easier porting to other underlying connections. A future version of your product could then use TCP or USB or something else to communicate with only the lower layers of the software and firmware needing to change. A bi-directional stream of bytes is the lowest common protocol that just about any link can be counted on to support somehow. That's what TCP does natively, for example. With USB, you can reserve one bulk endpoint in the in and out directions and that's what you have.

\$\endgroup\$
2
  • \$\begingroup\$ There's strong merit to the universality of a "bi-directional stream of bytes" argument, but it's worth keeping in mind that TCP and USB each have some latency quirks which for certain types of short-message back and forth "conversation" between devices can result in far lower performance than a simple serial connection would have. If planning to go in one of those directions in the future, it's a good idea to test it early in the design process before the high level protocol has been fixed to insure that the protocol design is suitable for those channels as well. \$\endgroup\$
    – Chris Stratton
    Jan 3, 2012 at 15:37
  • \$\begingroup\$ @Chris: Yes, good point. RS-232 is pretty slow, but does have fast turnaround. Turnaround can be significantly lower with USB and TCP, with bulk transfer rates much higher. Also USB and TCP are inherently flow controlled, so you might push one bit of state to the higher levels to indicate whether flow control at that level needs to be performed. That's what I do in my PIC programmer protocol, for example. \$\endgroup\$
    – Olin Lathrop
    Jan 3, 2012 at 15:50
0
\$\begingroup\$

You don't need 8 pins, as you seem to be aware. But if you must do so, what's wrong with buying 2 x 4 channel IC.s

Also, fwiw, as they are direction relevant you need N of some and 8-N of the other.

RS232 to uC is well enough served by bipolar NPN, Resistor 10k maybe from Collector to Vdd or whatever, Rin from signal in to base. 100k base to ground.

If you have V- for RS232 out, hang pnp emitter off V+. Collector R to -12 or whatever. Drive base from controller. Base to V+ 100k. QED.

If you need -V you can use MAX232 type device to provide it.

\$\endgroup\$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.