Arghhh! I Hate RS232 :)

[Ernest George]

Hi Folks!

I'm in the process of trying to add WiFi to a project and it turns out I need a RS232 converter such as a MAX232 chip.

The problem is I can't make heads or tails out of all the datasheets so that I can source the darn thing and add it into my circuit. As you may have guessed, I am not an electronics engineer.

The WiFi board I want to incorporate puts out UART 3.3v TTL
I need to convert that signal to old school RS-232 and run it elsewhere. That's all I need to do.

You'd think this would be simple but every datasheet seems designed to make this as difficult as possible. I found one device that I thought would work as it accepts TTL/CMOS inputs which, as I understand it, it what the chip needs to support on the input side. Unfortunately, the datasheet says that it generates +/- 5.5v for the RS-232 output voltage levels.

I thought RS-232 operated anywhere from +3 to +15 volts - or even higher. So, this causes me to question whether this chip is correct.

All I need is a single driver chip, preferably one that's automotive temperature rated that accepts UARt 3.vv TTL and outputs proper, old-school, RS-232. Can anyone cough up a good part number to use for that?

 

[KrisBlueNZ]

Maxim's MAX3232EEPE is a good choice, though genuine Maxim parts are not cheap: http://www.digikey.com/product-detail/en/MAX3232EEPE+/MAX3232EEPE+-ND/1512691 USD 6.29 for 1-up quantity. Data sheet at http://datasheets.maximintegrated.com/en/ds/MAX3222E-MAX3246E.pdf

This device can be powered from 3.0~5.5V and has two transmitters and two receivers. It requires four small capacitors to generate the RS-232 voltage levels.

A chip that uses ±5.5V voltage levels for its outputs falls within the RS-232 standard voltage range.

 

[Ernest George]

Good to see you Kris!

They aren't cheap, those little buggers. The problem with that one is that it's a through-hole device. I should have specified SM only in my post and preferably with an even wider temperature range. Even something like -55c to 125c would be ideal. I still can't make heads or tails out of most of those data sheets. The TI ones are even worse (for me anyway!).

Any other recommendations would be appreciated!

 

[KrisBlueNZ]

I assumed you wanted THT for ease of construction. But the MAX3232 is available in SMT, and Texas Instruments offer a version in -55~+125 °C temperature range: http://www.digikey.com/product-detail/en/MAX3232MDBREP/296-19873-1-ND/1120789. Still not cheap. Perhaps the TI data sheet will make more sense than the Maxim ones!

 

[Ernest George]

Aha!

I just checked something and the WiFi is only rated to -25c ~ 85c so there would be little point in exceeding that range which leads me to this one....which is WAY cheaper at 2.88 CAD

http://www.digikey.ca/product-detail/en/SN65C3232EDBR/296-20999-1-ND/1216961

Does that one accept UARt 3.3v TTL and output true RS-232 ?

 

[KrisBlueNZ]

Yes, but that's the SSOP package. There's a narrow SOIC version that's more compact: http://www.digikey.com/product-detail/en/SN65C3232EDR/296-21000-1-ND/1216962

 

[Ernest George]

Weird - the SOIC looks much smaller to me.The SSOP would probably be easier to place given the wide spaces between the leads.

Either way though, it looks like I can order something that will work!!

 

[Ernest George]

Kris...one more question if you're up to it?

As mentioned, the output on the WiFi has TX, RX & CTS/RTS lines. The device I'm ultimately sending the signal down to doesn't have CTS/RTS lines.

Would that matter? Is that a deal breaker?

 

[KrisBlueNZ]

It depends what flow control options are available on both ends of the link. The RS-232 standard is designed around communication between an end device like your circuit, which is called a DTE (data terminal equipment), and a device that provides a communication link, such as a modem, which is called a DCE (data communication equipment), which is your WiFi module. The RS-232 standard defines six main flow control signals. (See https://en.wikipedia.org/wiki/RS-232)

DTR: data terminal ready: DTE --> DCE. Active tells the DCE that the DTE is present.
DCD: data carrier detect: DTE <-- DCE. Active tells the DTE that the DCE has an active communication path.
DSR: data set ready: DTE <-- DCE. Active tells the DTE that the DCE is present and ready to accept commands or data (data for transmission should only be sent if CTS is also active).
RI: ring indicator: DTE <-- DCE. Active tells the DTE that the DCE is receiving an incoming connection request (for dial-up modems).
RTS: request to send: DTE --> DCE. Active tells the DCE that the DTE wishes to transmit data.
CTS: clear to send: DTE <-- DCE. Active tells the DTE that the DCE is ready to accept data.

These signals and their names are heavily tied to the model of a terminal (DTE) connected to a modem (DCE). Although the DCE has a way to tell the DTE whether it is ready to accept data (the CTS signal), the terminal is assumed to be always read to accept data, and doesn't have a way to tell the modem to stop sending data. (Back in the day, modems were dumb and couldn't store data until the DTE was ready to accept it.) So in that sense, the standard RS-232 names and usages are not symmetrical.

This became a problem when RS-232 was used as a generic interface between smart devices, which are not necessarily a terminal (or equivalent) and a modem, and where each end may need to tell the other end to stop transmitting because it can't accept any more data at the moment. In such interfaces, four of the RS-232 flow control signals (DTR, DCD, DSR and RI) were discarded because they weren't needed - other methods were used for these functions, such as the "RING" and "CONNECT" text strings for RI and DCD - and RTS and CTS were redefined:

RTS: DTE --> DCE. Active tells the DCE that the DTE is ready to accept data (new, changed meaning).
CTS: DTE <-- DCE. Active tells the DTE that the DCE is ready to accept data (the true original meaning).

So RTS/CTS flow control means that RTS and CTS are used as symmetrical flow control signals, to tell one device whether or not the other device is able to accept data. This system is also called "hardware flow control" because the flow control signals are electrical connections, rather than special control characters inserted into the data stream, as in XON/XOFF flow control, or the other option, no flow control at all.

Nowadays, flow control is not used so much, because the devices at both ends are generally fast enough, and have enough RAM, that they can receive a whole message of the maximum designed length, at full speed, and therefore have no need to tell the other end to stop sending data. This is almot certainly the case with your WiFi module - it probably has lots of memory.

But you may need to look into the requirements for flow control in the other direction, because the WiFi module will receive data in frames and will transmit whole frames to your device. If your device doesn't have enough RAM to store these frames for processing, and needs to tell the WiFi module to "slow down", some kind of flow control is needed.

You may be able to use XON/XOFF flow control if the WiFi module supports it. But XON/XOFF flow control is even less widely used nowadays than RTS/CTS flow control, because it reserves two byte values in the data stream for XON and XOFF control bytes, so not all byte values can be transferred transparently between one end and the other.

Communication devices such as modems and your WiFi board may have software-selectable flow control options, which are programmed using AT commands and can be stored in non-volatile memory in the device.

I hope that gives you enough of an overview to figure out the answer to your question!

 

[Ernest George]

Kris, you're amazing! You not only know what's what but you are also able to write out in such a fashion that I actually learn something in the process. That's a rare talent.

I once read a book on TCP/IP back when the Internet was new and I needed to know how it worked. The author did such a good job of explaining it that I read the whole book in the bathtub (a university level text) and came out of it with a really, really solid foundation on TCP/IP. Again, a rare gift!

Now to the question, as it turns out, I actually looked in the developers guide for the WiFi circuit (gasp!) and found this;

"Transparent transmission mode as a low level phy layer data transmitting can't keep zero error rates by itself. User can enable UART port's hardware flow control CTS/RTS function or through higher layer protocols such as TCP to lower error rate and manage the data completeness. We recommend when doing large amounts of data transmitting in transparent transmission mode, hardware flow control should be enabled, so as to fully ensure reliable transmission.

In the applications which doesn't need flow control, users can simply leave RTS/CTS pin vacant."

This gibes with what you are saying. The ultimate destination of the signal is a proprietary board that has terminals for TX, RX & GND. As such, my guess is that it does not support flow control at the hardware level. I do know that it has a MAX 232 clone (TI) further up the chain and then it turns the incoming RS232 back to 5v TTL and then sends it directly to the CPU.

So it's a bit goofy (my implementation) because it's really going like this;

WiFi module => 3.3v TTL => Max232 => RS232 => TX,RX, GND on Proprietary board => Max 232 => 5.0v TTL

So there's translation happening twice. The proprietary board was originally designed to have a serial cable connected to it, hence the TX, RX & GND with no flow control set on the serial port of the computer connected via the cable.

If I look at it that way, from it's original design, then it seems to me the original designers felt flow control was not necessary. Weigh that out with respect to the docs for the WiFi module; "In the applications which doesn't need flow control, users can simply leave RTS/CTS pin vacant"

then I conclude that it must not be required. Given the total trace length between the WiFi module and the destination is only inches I would think data integrity would not be an issue as it might be with a long cable. This brings me back to your concern about transmission speed. I do know that the destination runs at 115,200 max but, the WiFi module does up to 230,400 - so there may be a mis-match there. In theory, the module could send data too fast.

Apparently the WiFi module supports UART Farming Scheme and this is adjustable.

Aha! Further on in the manual it shows that you can set the UART baudrate....

So, my guess is that I can set it to 115,200 and that this will match with the destination's speed limit. I can also disable CTS/RTS on the WiFi Module.

Hehehehehe.....I think that should case everything ? I can tell the WiFi module to drop CTS/RTS and set it to the same speed as the destination.

Am I good to go or have I missed something?

 

[KrisBlueNZ]

Thanks

I once read a book on TCP/IP back when the Internet was new and I needed to know how it worked. The author did such a good job of explaining it that I read the whole book in the bathtub (a university level text) and came out of it with a really, really solid foundation on TCP/IP. Again, a rare gift!

Do you remember the book or author's name? I tried learning about TCP/IP and didn't get very far!

"Transparent transmission mode as a low level phy layer data transmitting can't keep zero error rates by itself. User can enable UART port's hardware flow control CTS/RTS function or through higher layer protocols such as TCP to lower error rate and manage the data completeness. We recommend when doing large amounts of data transmitting in transparent transmission mode, hardware flow control should be enabled, so as to fully ensure reliable transmission.
In the applications which doesn't need flow control, users can simply leave RTS/CTS pin vacant."
This gibes with what you are saying. The ultimate destination of the signal is a proprietary board that has terminals for TX, RX & GND. As such, my guess is that it does not support flow control at the hardware level.

Right, if it only has TXD, RXD and GND, it definitely doesn't support hardware flow control.

I'm assuming that the firmware running on your board was written to work with a different WiFi modem, right? In that case, it MAY have used commands (sent via TXD) to tell the original modem to use XON/XOFF flow control, for example. I don't know whether this is likely or not. If it doesn't receive and transmit large amounts of information, it may well have been designed to use no flow control at all.

I guess you could try it with the modem's CTS and RTS pins unconnected, and see whether it works reliably in a high load situation. But it may appear to work properly if it retries failed transmissions, so if it has configurable error retries, disable them; if it has error counters, check them.

WiFi module => 3.3v TTL => Max232 => RS232 => TX,RX, GND on Proprietary board => Max 232 => 5.0v TTL

Yeah, it's a bit messy, but if your board only has RS-232 signals, that's what you have to do.

If I look at it that way, from it's original design, then it seems to me the original designers felt flow control was not necessary.

They felt that HARDWARE flow control was not necessary, yes.

Weigh that out with respect to the docs for the WiFi module; "In the applications which doesn't need flow control, users can simply leave RTS/CTS pin vacant" then I conclude that it must not be required.

I think you're PROBABLY right.

This brings me back to your concern about transmission speed. I do know that the destination runs at 115,200 max but, the WiFi module does up to 230,400 - so there may be a mis-match there. In theory, the module could send data too fast

That's not how it works. Both ends MUST use the same data (bits per second) rate. If there's a data rate mismatch, no data, or random meaningless data, will be transferred. But yes, the data rate does determine the maximum amount of data that can be transferred in each second.

Apparently the WiFi module supports UART Farming Scheme and this is adjustable.

I have no idea what UART "farming" is. If you mean that it supports different framing options, that's fine; nowadays almost all data connections use "N81" data format and framing - that is no parity, eight data bits, and one stop bit.

Aha! Further on in the manual it shows that you can set the UART baudrate....
So, my guess is that I can set it to 115,200 and that this will match with the destination's speed limit.

The data rate on the WiFi module must MATCH the data rate used by your board. The WiFi module may auto-detect the data rate.

I can also disable CTS/RTS on the WiFi Module.

Good. Yes, you should do that.

Hehehehehe.....I think that should case everything ? I can tell the WiFi module to drop CTS/RTS and set it to the same speed as the destination.

Yes, you should do that.

Am I good to go or have I missed something?

That will probably work, but without flow control of any kind, it's possible that under heavy data load, data could be lost. Best to try it and see.

 

[Ernest George]

Do you remember the book or author's name? I tried learning about TCP/IP and didn't get very far!

I sure do. The author asked his publisher to contact me to see if they could use my quote as an endorsement and so you'll find me (using my real name!) in the list of endorsers in the front cover along with some pretty heady company, like the people that created the Internet! It's Internetworking with TCP/IP Volume 1 - Principles, Protocols & Architecture by Douglas E. Comer - head of computer science at Purdue. I highly recommend it.If you like electronics, you'll love the logic and design / history behind TCP/IP.

I'm assuming that the firmware running on your board was written to work with a different WiFi modem, right? In that case, it MAY have used commands (sent via TXD) to tell the original modem to use XON/XOFF flow control, for example. I don't know whether this is likely or not. If it doesn't receive and transmit large amounts of information, it may well have been designed to use no flow control at all.

No, the firmware in the 'brain' was designed to be connected to an old school RS-232 cable - that's it. So it was never designed to be used with Blue Tooth (which I had working well) nor WiFi, which I would prefer/plan to use. The amount of data going back and forth is pretty small. The BlueTooth module put out 5v TTL and so what I did was tap into the vias going directly to the CPU (bypassing their on-board Max232) and it worked well. Never saw an issue with the BT module set at 115,200 8N1 and no flow control (on the computer's virtual com port)

The largest data that gets sent to it is about 350K - a firmware update, and I did this several times over BT without incident. Other then that, it's just data back and forth, and probably not much.

I think that between our back & forth's and the manual it's looking pretty good. This is a big deal for me as the blue tooth range was not very good. I also want to get as far away from virtual COM ports as possible. It's so 1970's

 

[pebe]

Another chip that may fill the bill is the SP3485.
If you look it up on the RS site and it will point you the data sheet for it.

 

[KrisBlueNZ]

That's an RS-485 transceiver, not RS-232. But thanks for playing!

 

[KrisBlueNZ]

Thanks for the pointer. It's outside my budget but I found an earlier edition for a few bucks, which will at least give me the basics.

So the firmware in the device isn't meant to work with a modem at all? So I guess the modem can be configured to automatically connect to a WiFi host, and through to some kind of virtual port on the host device or something like that? Because that device expects a transparent, permanently enabled data connection. But I guess you already did this with the Bluetooth modem so you can do the same for the WiFi modem.

 

[pebe]

(quote)That's an RS-485 transceiver, not RS-232. But thanks for playing!/quote)
The OP said he wanted to input 3.3V TTL into a some form of converter at one end of the cable and get Tx, Rx, and GND out of a converter at the other end. So I had assumed that he didn't mind what protocol was used on the cable link

 

[KrisBlueNZ]

The OP said he wanted to input 3.3V TTL into a some form of converter at one end of the cable and get Tx, Rx, and GND out of a converter at the other end. So I had assumed that he didn't mind what protocol was used on the cable link

I think you need to re-read post #1. It mentions RS-232 several times.

 

[pebe]

I think you need to re-read post #1. It mentions RS-232 several times.

I read it several times. I also saw from post #12 para2, that the OP had already bypassed the RS232 link and gone straight to the CPU. On that basis he could dispense with the RS232.

 

[KrisBlueNZ]

And this relates to RS-485 somehow?

 

[pebe]

And this relates to RS-485 somehow?

That's an illogical question. Why did you ask it?