UART to UART between 2 uCs

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I want to communicate between 2 uCs of the same type and operating at the same voltages using the UART peripheral.

The distance between the 2 micros is about 2 meters, both micros share the same common ground, each micro has it's own 5v power supply.

BAUD rate is 19.2kps

I can not use a MAX232 chip due to space and cost limitations.

I put in current limiting resistors and TVS diodes on each unit. I will chose a TVS with the lowest capacitance I can find. The working voltage of the TVS will be 5v, and the breakdown will be around 8v.
The Max current of my uC pin is ~25ma, the micro is running 5v.

I can do a straight calculation for R1,R3,R7,R7 based just on protection (8v-5v)/25ma = 120 ohms.

For R2,R4,R5,R6, I guess I can do something similar based on specs of the TVS diode.

But, I am not sure for the sake of UART functionality what range or resistance would be ok. Please let me know your thoughts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think you need to look for very low capacitance TVS diodes. At these rates I don't think it matters at all, and the capacitance helps to slow the edges, which helps EMC.

TVS diodes are available in many packages, one is two in a SOT23; will be quite small then.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course you realise that if you turn one if the boards off it will then be powered by the the other chip via the RXD pin.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before you model the system as a low pass filter based upon the cable capacitance and the TVS capacitance, I would think two preliminary calculations come to mind:

If one Micro is outputting a Hi, say 5 V, (knowning that this is an over-estimate of the true pin's high voltage); and one micro is accidentally in output mode, Low, (it should be an Input, Hi impedance), then the 4 resistors in series need to limit the current to 25 mA. So R=V/I = 5/25m = 200 ohms total resistance for the string, minimum.

Run-away code then won't fry the hardward given this condition.

Next, if EMC / Noise / abraided wire and accidental connection to another voltage source puts > 8 V on the 2 meter cable's center conductor, and the TVS clamps it to 8 V, then the current into the micro's pin will be (8-5)/R7.

The internal clamping diodes direct this current to the V+ power rail. Several users have stated that the internal clamping diodes are generally rated for 1 - 2 mA. Assuming this is a transient fault and you use 2 mA then R7 = 1.5 kohms. Using the more conservative 1 mA through the internal clamp diode makes R7 3 Kohms.

One needs a matching 1.5k or 3k at the other end.

One needs R2 & R5 based upon the TVS and the transients to be protected against. The point being the in line series resistance will be well above what is determined as the minimum from the first calculation.

Once you select some values then model the LPF effect of the system to be sure it won't impact your ability to transmit at your desired baud rate.

Then try it.

Then try it some more :)

Sorry I can't give you a specific answer on what the line will tolerate for an upper limit to the resistances's.

My first guess, without any calculations to support it, would be that it won't be a problem, (JS's "fault" condition aside, which could be a problem).

You will have to look closely at the condition John raises, one micro on, the other off. Parasitic powering could lock up the micro, or parts of it, at least until it is reset, (assuming there is no permanent damage, albeit operated out of spec).

The "easy" solution might be to have one power supply running both boards, but this assumes you can tolerate running the V+ to the remote micro, and that the other I/O to the remote micro can also run off the Master's power, via the cable. One would generally want a fuse in the power supply just in case the V+ & Gnd cable was accidentally cut/shorted, and another couple of caps filtering the V+ and Ground coming into the remote board.

Obviously use a shielded cable for the cable connecting the two boards, preferably with the two signals twisted together inside the shield.

And give some thought to negative voltage spikes, (noise), induced in the cable.

Disclaimer: Just a few late night thoughts from a tire individual.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jay: I agree that capacitance should not really matter at 19.2k, but I may go to a high baud rate. I am going to use a SOD 323 package, I have no space on the board to do much routing so placing the diode right next to the connected resistors is what I will have to do.

John: Good point, I had problems like this before, I will look into it, and maybe set the LVD on the micro to take care of that type of condition.

JC: The first point is a good one, I will keep that in mind.

I made a mistake referring to the breakdown voltage, at breakdown the reverse currents are quite small.

The reverse clamp voltage of the diode was what I had in mind, is ~10v and the max current is 5A, it also states that @ ~15v the max current is 23A. For some reason both the 10v and the 23v are labelled as "Max reverse Clamp Voltage".

I will use 10v in my calculations as the max voltage at the diode.

Both units will have their own power supply, that is something I can not change. The power supplies for both will be over voltage, reverse voltage, and fused.

I am going to run the units in some pretty nasty environments when it comes to electrical noise. I can not shield nor use twisted pair, the fact that I am using 0-5v voltages on the cable and not RS232 voltages makes the problem worse, also I am running the micros using the internal oscillator which is not very precise.

I only need to send about 5 bytes of data between the modules @ 10Hz, I will put a CRC checksum at the end of the datapacket. If the CRC check fails then there is plenty of time to ask for a retransmit. If the noise also beats up the retransmit request then I will just lose that packet, it is no a show stopper so long as 99% of the time I get the data packets.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toalan wrote:
I can not shield nor use twisted pair, the fact that I am using 0-5v voltages on the cable and not RS232 voltages makes the problem worse, also I am running the micros using the internal oscillator which is not very precise.

I hope the internal oscillators are calibrated or their nominal frequency is known, so you know if they can even talk to each other at all. For 8N1 configuration the absolute maximum deviation of baud rates is about 4%, so each end must be within 2% of nominal, or even near 1% since you seem to have long wires, protection networks causing slow edges and noisy environment.

For two wires and ground, I might suggest I2C communications instead. It does not require precise clock sources. But because it is an open-collector bus, the noise problem might be even larger, as only the pull-ups are responsible keeping the lines high. For a 5V 3mA bus the pull-up is about 1k7 minimum, but AVRs can easily sink more current, so you can use 1k or even 820 ohm pull-ups. And keep the bit rate below 100kHz standard mode limit, so you have relaxed rise time requirements, which allow you to even put some filter caps on the IO pins, max would most likely be 100pF, but you can easily calculate that capacitance from 1000ns rise time and your pull-up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toalan,

What type of interconnecting wires ARE you using for Tx & Rx? Does, or can, the common ground run physically with these Rx & Tx wires?

What condition exists that prompts you to include the TVS diodes in the interconnect?

You do not have space for a Max 232 converter chip, but do you have room for a SOT-23-6 on each board?

How closely are the 5 volt supply voltages matched?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
toalan wrote:
I can not shield nor use twisted pair, the fact that I am using 0-5v voltages on the cable and not RS232 voltages makes the problem worse, also I am running the micros using the internal oscillator which is not very precise.

I hope the internal oscillators are calibrated or their nominal frequency is known, so you know if they can even talk to each other at all. For 8N1 configuration the absolute maximum deviation of baud rates is about 4%, so each end must be within 2% of nominal, or even near 1% since you seem to have long wires, protection networks causing slow edges and noisy environment.

For two wires and ground, I might suggest I2C communications instead. It does not require precise clock sources. But because it is an open-collector bus, the noise problem might be even larger, as only the pull-ups are responsible keeping the lines high. For a 5V 3mA bus the pull-up is about 1k7 minimum, but AVRs can easily sink more current, so you can use 1k or even 820 ohm pull-ups. And keep the bit rate below 100kHz standard mode limit, so you have relaxed rise time requirements, which allow you to even put some filter caps on the IO pins, max would most likely be 100pF, but you can easily calculate that capacitance from 1000ns rise time and your pull-up.

I had not looked at the oscillator issue until now. I will need and external oscillator as the internal oscillator is +/-3% over temperature. Problem is that, I have no space for a normal hc49 oscillator package, so I will have to pay premium and get a small non standard package oscillator. The current bill of materials for my system is $5, including cable, enclosure, components, and assembly. I really need to meditate on paying 50 cents more for a small oscillator for the UART feature. The UART is there for expansion possibilities, it is not a critical piece of the core functionality, but my thoughts on it being critical or not change from day to day.

I have worked with I2C but I can not use it as much as I would like to. I can not get into why I can not use it, if I do use I2C there is a 100% chance that it will turn into a bloody mess. No serial communications is a better option than the hell that I2C will raise for my application.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck-Rowst wrote:
toalan,

What type of interconnecting wires ARE you using for Tx & Rx? Does, or can, the common ground run physically with these Rx & Tx wires?

What condition exists that prompts you to include the TVS diodes in the interconnect?

You do not have space for a Max 232 converter chip, but do you have room for a SOT-23-6 on each board?

How closely are the 5 volt supply voltages matched?

The wires connecting the Rx and Tx will be 20 AWG stranded wire.

The units are specified to connect to a common ground point. Each unit will push around 100ma through the common ground, ground will be through 20 AWG stranded wire. I do not expect any tangible offsets between the grounds of each unit.

I have 2 reasons to put the TVS diodes on the lines. First is ESD protection during the time when the lines are physically connected together, I am not using a connector so the wires will be twisted together by hand, hopefully soldered, and heatshrink applied. 2nd is that in my marketing material I want to put "all inputs and outputs, are over voltage and current limited"

Please let me know what solution you have with a sot-23-6. If the solution is a great one, then I will make space.

I am using a 2% regulator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As mentioned in some of the prior posts there is no need to use actual RS-232 levels to communicate between the serial ports of two micros. You just connect the transmit output of one to the receive input of the other, and it will work fine provided:

A. The micros have a common ground (i.e. DC Common) between them.

B. The electrical interconnection of the xmit & receive signals can faithfully conduct the signals. For example, imposes no attentuation on the signals, imposes no voltage offset on the signals, imposes no noise on the signals.

C. The baud-rate clocks of the two micro's are suitably matched - as mentioned in the prior posts.

D. A few other common sense electrical rules are obeyed.

There are certainly valid reasons to use legitimate RS-232 or RS-422 or RS-485 levels and converters. Still, I have seen countless processor-to-procesor systems with interconnect distances of less than a few feet which include RS-232 converter chips (Maxim & similar). Totally unnecessary !!!!!!

As long as your interconnect can faithfully conduct logic-level signals at the intended baud-rate (i.e. frequency), the thing will work perfectly. "Faithfully" = appropirately noise-free, no DC offsets, etc as outline above.

So that, the challenge, such as it is, is to design an interconnect that can carry logic signals 6 feet (2 meters) faithfully. I dare say this has been done before. Garden variety 7400 bipolar and CMOS family logic (LS, HCT, ACT, etc) can do this with their pins tied behind their backs!

You do have one other constraint in your system because of the split "power domains" - that is, the two 5 volt power supplies that can be powered on or off independently. This requires a bit of attention so that you do not inadvertently power-up the powered-down entity from the receive logic signal.

This type of "phantom" power phenomenon is essentially a CMOS problem caused by the protection diodes attached internally to the inputs in most CMOS devices. There are various circuit topologies for thwarting this "phantom power" mechanism. The problem does not present itself with bipolar logic families like 74, 74LS,74F because of several reason, primarily the lack of protection diodes on the inputs. Atmel processors DO have this problem because they are CMOS devices and their inputs DO have the protection diodes which "promote" the phantom powering problem.

Anyway, assuming you will be using CMOS levels to communicate, you need to come up with a method of dealing with the phantom power issue. Picking the simplest solution usually dpeneds on other factors in your system. For example, if power consumption is not a problem you can simply put a reasonably high resistance in series with the interconnect logic signals and a relatively low value ballast resistor across your power supply rails. Say, 10K on the signals and 100 Ohms for the ballast resistor. The receive signal will still flwo thru the protection diodes, raising the Vcc rail of the receiver chip (e.g. the micro), but the rail voltage can only go so hihg because of the ballast resistor. There are a number of other methods to thwart the phantom power effect. I'm sure otehr Freaks will offer up their favorites if you ask.

Oh by the way, twisting the transmit and receive interconnect wires together probably won't buy you any noise immunity. Normally, the twisting is applied to the signal and its return wire. In your case the "return" wire is the ground wire which you stated is separated from the signal interconnect wires. If you take the approach of adding resistance to the signal lines to thwart the phantom power effects, you will want to separate the transmit and receive lines physically (1/2" or so) to avoid coupling between them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

These might be a tad pricey for your circuit, but how about something like this?
http://www.infineon.com/dgdl/IFX1050G_DS_rev10.pdf?folderId=db3a30431ed1d7b2011edadb13813703&fileId=db3a304320d39d590121f374ea660d66

It's got the protection circuitry already built in, and fits both transmit and receive into an soic-8 package

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Oh by the way, twisting the transmit and receive interconnect wires together probably won't buy you any noise immunity

:oops: Yup. Good point. I obviously wasn't thinking well when I wrote that.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
For two wires and ground, I might suggest I2C communications instead. It does not require precise clock sources. But because it is an open-collector bus, the noise problem might be even larger, as only the pull-ups are responsible keeping the lines high. For a 5V 3mA bus the pull-up is about 1k7 minimum, but AVRs can easily sink more current, so you can use 1k or even 820 ohm pull-ups.

Rather than using simple resistors for the I2C pull-ups, use a current mirror (implemented with a resistor and two PNP transistors) instead. This will give much faster rise times on the I2C signals and allow use of much longer cable runs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The reverse clamp voltage of the diode was what I had in mind, is ~10v and the max current is 5A, it also states that @ ~15v the max current is 23A. For some reason both the 10v and the 23v are labelled as "Max reverse Clamp Voltage".

Then it's likely a bidirectional Tranzorb, you can also get unidirectional ones which have -0.7V clamp voltage.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Quote:
The reverse clamp voltage of the diode was what I had in mind, is ~10v and the max current is 5A, it also states that @ ~15v the max current is 23A. For some reason both the 10v and the 23v are labelled as "Max reverse Clamp Voltage".

Then it's likely a bidirectional Tranzorb, you can also get unidirectional ones which have -0.7V clamp voltage.

The TVS I am looking at is unidirectional, the datasheet was just worded poorly, the ~10v is not really max, just another data point in the graph but they labelled it as max.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chris-Mouse wrote:
These might be a tad pricey for your circuit, but how about something like this?
http://www.infineon.com/dgdl/IFX1050G_DS_rev10.pdf?folderId=db3a30431ed1d7b2011edadb13813703&fileId=db3a304320d39d590121f374ea660d66

It's got the protection circuitry already built in, and fits both transmit and receive into an soic-8 package

I would love to use CAN BUS, it is absolutely perfect. But space and price limitations do not allow me. I will have CAN BUS for higher end designs, just not the current low priced one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update:

I managed after a few hours of moving components around and routing, put a small external crystal on the design with load capacitors on each end.

The sum of the tolerance, temperature drift, and aging is +/- 55 ppm.

The crystal costs 69 cents in qty of 1k, my micro costs $1.39 in qty of 1k. I can not believe I am paying half the price of a micro for a crystal.

I will just wait for my PCB to arrive, and play with the Resistor values until I find something that looks good.

Thanks for all your help guys.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about a ceramic resonator? I just used CSTCC3M58G53-R0 from Murata on a board; $0.39 in 1k quantity, and it has the caps inside. A fun one to solder, but it certainly is small. If you need thruhole, ZTT-16.00MX is $0.28 in 1k.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can manage without a crystal if you are in control of both micros software which you seem to be.
I have solved this by sending a "U" to the receiving micro which will measure the bit length and adjust its baudrate to fit the transmitter. Repeat this periodically.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know where you are buying your Xtals from, but most normal frequencies are available for < 20p in the UK...... (= 30 cents in the USA)- HC49 package.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

n1ist wrote:
What about a ceramic resonator? I just used CSTCC3M58G53-R0 from Murata on a board; $0.39 in 1k quantity, and it has the caps inside. A fun one to solder, but it certainly is small. If you need thruhole, ZTT-16.00MX is $0.28 in 1k.

Thanks for the tip, looks like resonator might work for me better since they are typically smaller than crystals.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
You can manage without a crystal if you are in control of both micros software which you seem to be.
I have solved this by sending a "U" to the receiving micro which will measure the bit length and adjust its baudrate to fit the transmitter. Repeat this periodically.

So you keep sending "U" and adjust the baud rate from one end to the other, find the 2 baud rates on each end that are the limit to properly reading "U" and take the middle as the baud rate?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chartman wrote:
I don't know where you are buying your Xtals from, but most normal frequencies are available for < 20p in the UK...... (= 30 cents in the USA)- HC49 package.

Standard HC49 is too big, I need a non standard smaller package.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So you keep sending "U" and adjust the baud rate from one end to the other, find the 2 baud rates on each end that are the limit to properly reading "U" and take the middle as the baud rate?

No, but I guess that might work too.
The upper/lower/mid values at expected temp and voltage are already known through testing and hardcoded.
The side that initiate transmissions always use mid value.

So the receiver start at mid value as default.
Should that value result in frame error I increase and try again until upper limit is reached or the small packet is received without frame error. If there's still a frame error I start with lower limit value and repeat.
This is the first step, normally the default value works and step two come into play.

This is where I measure the actual bit length of three "0" and three "1" from the "U" received.
Results are averaged and become the new "mid value".
In the app I refer to several packets are sent twice a second and the first packet sent include "U" character.
So twice a second transmitters bit length are recalculated before receiving the other much longer packets.
The reason for step one is that every packet have a checksum and if that don't match at receivers end the packet is discarded. So step one is only to get a working comm, step two will then fine tune baudrate if temperature or voltage change.

I'm sure there are other/better ways to do this but the trick is that the receiver measure the length of one bit at some repeated interval and adjust.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One way to syncronize is to send a byte (0xFF for example, it has just the start bit low, all other bits high) every known interval, if nothing else is sent. The receiver then knows what the interval should be, and then adjust the clock speed until the interval time matches.

By transmitting only 0xFF, the receiver will see that as 0xFF if it just sees the start bit. Initial baud rate error can be huge, but it is the time between bytes that is used for calibration, not the time during a byte.

Of course, the transmitter must have good real time operation for transmitting these without much jitter, and the receiver also good real time operation to measure interval between bytes. Does not work if interrupts are often disabled etc, or transmitting end is a non-realtime thing like PC.

Sometimes you could even encode information to the intervals, so that even if baud rate is unknown, you can send out the baud rate information as a pattern of what delays are between bytes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't read the entire thread so apologies if this has been mentioned already but to synchronise the clocks you don't need to use the UART. Before you set TXEN just drive the pin as an I/O and pulse some square wave down it at what micro A thinks is frequency N then have micro B keep tweaking his OSCCAL until he sees it as N too. Then maybe use the other line for B to signal A to say "OK I'm in step - lets enable the UARTs" and off you go. UBRR can then be set to pretty much anything as long as it is the same at both ends.

Cross wiring the inbound pulse to an interrupting pin or an ICP pin could make the process simpler still.