Serial comms between two microcontrollers - not working!

[AceOfHearts]

Ok, I have two 8051 uCs.

One has a keypad attached to it the other one has an LCD attached to it.
Both have the relevant code upoloaded.

The idea is that I send 12 key presses (Hex) serially from the uC attached to the key pad to the uC attached to the LCD.

I have tested both ends independantly and they both work. I used the Terminal software to read what the uC connected to the keypad was transmitting, and all the key worked displaying the correct value on the laptop. I also tested the uC connected to the LCD by sending values to the uC using the Terminal software, and it showd up correctly on the LCD.

However the problem is, when I try to connect the serial link between the two uC and press any key, I get wierd symbols appearing on the LCD. For some reason connecting the two subsystems do not work, whereas I know they both work on their own.

What could be the matter with my system?

Many thanks.

 

[3v0]

Simple things first. I am guessing you know this but it needs to be checked.

DTE and DCE. If you do not have one of each you need a null modem cable to connect them. In short TX and RX (2 and 3) are crossed.

 

[AceOfHearts]

Simple things first. I am guessing you know this but it needs to be checked.

DTE and DCE. If you do not have one of each you need a null modem cable to connect them. In short TX and RX (2 and 3) are crossed.

No I have not.

Can you kindly elaborate please?

Many thanks.

 

[3v0]

If both of your uC's can talk to a PC then they will not be able to talk to each other.

You need a Null Modem Cable. As I said the sort version is that TX and RX wires (pin 2 and 3) are crossed.

This sounds stupid but: Think of it like this. You have two pipes.
Your friend speaks into one and listens to the other.
You speak into the one he listens to, and listen to the one he speaks in.

If you get it wrong you are both speaking into the same pipe and listening on the other (that no one is speaking into). It is a good chance that is what you are doing.

 

[Leftyretro]

That is frequently a source of confusion to the inexperienced. In a way the terms send and receive are poor descriptors because in a full duplex communications both end devices have both a send and receive pin. It's obviously important that one ends send pin is wired to the other device's receive pin and visa verse.

The RS232 standard tried to make this more clear by stating two different kinds of termination wiring schemes, a DCE (digital communication equipment, modems, multiplexers, etc) end and a DTE end (digital terminal equipment(CRT, printers,etc).

If the two different end devices are wired one as a DCE and the other as a DTE, then a straight through pin for pin cable will result in proper send/receiver data relationship. However if both equipment ends are wired same as DCE or DTE ends then everyone is talking but nobody is listening

To make it more confusing the original RS232 standard does not define a computer port as being a DCE or DTE device, as computer typically can hook to both types (PC comm ports use to frequently be used for both modems (DCE) and serial printers (DTE). And to add to the confusion IBM implemented RS-232 comm ports using a 9 pin D connector rather then the 25 pin D connector that the original RS-232 standard used.

So serial RS-232 is a very old standard interface, and is probably the most abused and confusing standard. Many options are hard to work out in new installations, such as hardware flow control (DTR/DSR, RTS/CTS), software flow control (X-on/X-off) or no flow control (here it comes ready or not), to say nothing of the baud rate, data bits, stop bits, parity bit or none, options that have to be consistent between the two end devices.

Good luck
Lefty

 

[kjennejohn]

Here's a handy thing to know when working with RS232: the transmit line will measure a negative voltage, usually anywhere from minus 3 to minus 12. The receiving line is indeterminate or slightly positive, but never negative. These are measured to ground. On a DB9 connector ground is pin 5, pin 7 on a DB25. A DTE port will have this minus voltage on pin 2, a DCE will have it on pin 3. So, simply measure the voltages on pins 2 and 3 of each port. If the minus voltage is on pin 2 of one connector and on pin 3 of the other, you are good to go. If not, get or make a null-modem adapter and use that to get these right. This simple rule has saved me a lot of hand wringing in the shop.

Hope that helped,
kenjj

 

[AceOfHearts]

If both of your uC's can talk to a PC then they will not be able to talk to each other.

You need a Null Modem Cable. As I said the sort version is that TX and RX wires (pin 2 and 3) are crossed.

This sounds stupid but: Think of it like this. You have two pipes.
Your friend speaks into one and listens to the other.
You speak into the one he listens to, and listen to the one he speaks in.

If you get it wrong you are both speaking into the same pipe and listening on the other (that no one is speaking into). It is a good chance that is what you are doing.

Im sorry, I really dont understand whats going on here. I only have half duplex comms as I am transmitting from one uC only and not not doing transmit/receive at any time.

It just makes sense that my Tx pin of one uC goes into the Rx pin of the other uC.

As far as I am concerned, the data is ready and is comming out of the Tx, and it shouldnt be a problem going into Rx.

Leftryretro says "It's obviously important that one ends send pin is wired to the other device's receive pin and visa verse." but you said something opposite?

I am sure there is a way to get around the problem (whatever it is) without buying a Null Modem Cable (built one if necessary).

But at the moment, I am still trying to absorb what the problem really is, because I just dont understand it as of yet!

Many thanks for the responses.

 

[Leftyretro]

Im sorry, I really dont understand whats going on here. I only have half duplex comms as I am transmitting from one uC only and not not doing transmit/receive at any time.

It just makes sense that my Tx pin of one uC goes into the Rx pin of the other uC.

As far as I am concerned, the data is ready and is comming out of the Tx, and it shouldnt be a problem going into Rx.

Leftryretro says "It's obviously important that one ends send pin is wired to the other device's receive pin and visa verse." but you said something opposite?

I am sure there is a way to get around the problem (whatever it is) without buying a Null Modem Cable (built one if necessary).

But at the moment, I am still trying to absorb what the problem really is, because I just dont understand it as of yet!

Many thanks for the responses.

Well you do say that there is data moving from one uC to the other uC, only it's garbled characters displayed on the LCD. That should mean it's not a hardwired data direction problem. What baud rate are you using? It's possible that the baud rate error (there is always a small amount of error due to uC clock speed variation) for either uC is small enough to work via the PC but when working together the error is adding such that it's garbling characters. You might try slowing the baud rate to the slowest speed possible and see if the garbled characters improve. Also make sure that there isn't a 7 bit Vs 8 bit problem. Your PC may ignore 8th (strip off the non ASCII 8th bit), but your LCD may not and is displaying non-ascii characters?

You just have to keep try things using logical steps, you're not the first to have trouble establishing a serial link

Good luck

Lefty

 

[3v0]

I missed the following when I read your poist. Duh.

However the problem is, when I try to connect the serial link between the two uC and press any key, I get wierd symbols appearing on the LCD.

In general this means you have the TX>RX correct. What I said agrees whit Lefty but if it confuses you ignore it.

What confused me was that you said both of your uC's could talk to a PC and you did not know what a null modem cable was. This led me to think you had RX->RX and TX<-TX. Which does not seem to be the case.

Lefty is right. You need to get the baudrate, parity, stop bits identical on both uC's. Most PC terminal emulators are forgiving about a mismatch (to some degree) but the uC's are not.

 

[eblc1388]

However the problem is, when I try to connect the serial link between the two uC and press any key, I get wierd symbols appearing on the LCD. For some reason connecting the two subsystems do not work, whereas I know they both work on their own.

Baudrate of one uC is off by +5% and the other by -5% ???

Don't do 12 values first. You must confirm that the link works by sending a single value, like the ASCII "U" or 0x55. Insert a temporary code fragment to send a single known value each time a key is pressed. Report back here what is displayed on the LCD.

If it is displayed correctly on the LCD, then you can send two or more.

Added: You do know besides RX and TX, you still have to connect the common of two uC systems together.

 

[AceOfHearts]

Thanks for all the responses, much appreciate it.

I will try and switch things around a little and see what I get.

Well you do say that there is data moving from one uC to the other uC, only it's garbled characters displayed on the LCD. That should mean it's not a hardwired data direction problem. What baud rate are you using? It's possible that the baud rate error (there is always a small amount of error due to uC clock speed variation) for either uC is small enough to work via the PC but when working together the error is adding such that it's garbling characters. You might try slowing the baud rate to the slowest speed possible and see if the garbled characters improve. Also make sure that there isn't a 7 bit Vs 8 bit problem. Your PC may ignore 8th (strip off the non ASCII 8th bit), but your LCD may not and is displaying non-ascii characters?

You just have to keep try things using logical steps, you're not the first to have trouble establishing a serial link

Good luck

Lefty

But my LCD has 8 bit data line?

 

[Leftyretro]

Thanks for all the responses, much appreciate it.

I will try and switch things around a little and see what I get.



But my LCD has 8 bit data line?

As most character devices do these days. The original ASCII character set only used 7 bits to define 128 common alfa, numeric and basic puntuation characters. As time passed there were many different character sets that used the extra 128 characters gained by using the 8th bit. You just have to make sure that what you are sending is what you expect to be sending. Bit 8 should be low when transmitting from the sending PIC for simple letter & number characters. Your receiving pic, if it's not going to be using those 'special characters' that require the 8th bit on, can force that bit off in your program (AND it with 07Fh) before sending to the LCD.

Good luck
Lefty

 

[Brevor]

How far apart are the two uc's, do they share a common ground?
It sounds like you are not using a max 232 IC.

 

[AceOfHearts]

Thanks Lefty.

How far apart are the two uc's, do they share a common ground?
It sounds like you are not using a max 232 IC.

There is no MAX232 between the two uC as it is not required to, they transmit at 5V or 0V. I use the MAX232 IC to connect to the serial port of my laptop only.

The uC are on the same breadboard where I am testing and are connected to the same GND and Vs.

Thanks.

 

[AceOfHearts]

Im going to try and reduce the baud rate from 4800 to 2400 and see if that makes any difference.

Both 8051 is loaded with 50H into the SCON register, that is 8 bit data, 1 start bit, 1 stop bit and REN enabled

Oh yes, Lefty,

The 8th bit would not make any difference should it, given that it is the MSB and the fact that I am only transmitting 0 to B in hex which does not require the 8th bit. ie. the maximum value is B, which is 00001011 in binary?

 

[AceOfHearts]

Baud Rate down to 2400 from 4800, still I am getting weird symbols. Well, they are enot much of a symbol, more like strieght lines.

I might try reducing the baud rate further down to 1200.

I set both of my uC such that there is 1 start and 1 stop bit with 8 bit serial data bits. So the transmitting uC transmits what the receiving uC is already expecting.

How can synchronisation be an issue I wonder? 11.0592Mhz crystal on both uC and /12 is 921.6kHz (machine cycle freq.) 921.6kHz/32=28800 (provided by UART), 28800/12=2400 bit/sec (so -12D loaded in TH1)

now how many machine cycles do we have in one second? 921600, how many bits in one second? 2400. How many machine cycles per bit?

921600/2400 = 384 machine cycles per bit. This means a single bit of a serial byte will be lingering on the Rx pin while 284 machine cycles take place.

384 machine cycles correspond to 384*12=4572 oscilations of the crystal.
The discrepency between the two crystals cannot add up to such a high value. Or can they? If they do, then a single bit error is spelling the disaster. That's a (100/11.0592Mhz)*4572 = only 0.041% error tolerance in one crystal or both crystal by 0.021% giving one bit error.

Crystals are meant to be extremely accurate, are they not? What about to this accuracy level 100-0.021 = 99.98%?

I am just trying to eliminate all possible causes.
But the actual baud rate I want I have set using software and is identical on both uC, and given the crystals are working accurately, there should be no problems?

This is strange indeed. I am sure its just one thing I need to get my head around.

I will reduce the baud rate further down, this will increase the system tolerance.

 

[Pommie]

RS232 works fine even with digit % differences. If you are still worried about the crystals then swap them and see if the error changes. Also, try swapping the chips around. If the error stays the same then you know the problem is software. I don't know much about the 8051 but know that they cannot drive outputs high, is the internal pull up adequate, maybe an external pullup may improve things.

Mike.

 

[AceOfHearts]

RS232 works fine even with digit % differences. If you are still worried about the crystals then swap them and see if the error changes. Also, try swapping the chips around. If the error stays the same then you know the problem is software. I don't know much about the 8051 but know that they cannot drive outputs high, is the internal pull up adequate, maybe an external pullup may improve things.

Mike.

Only Port 0 of an 8051 requires external pull-up resistor.

But seen as you mentioned it, I tried an external pull-up resistor on the Tx pin, made no differece!

Thanks for the help.

PS. Tried two brand new identical crystals, nothing.

 

[AceOfHearts]

Something interesting I noticed as I played with the logic probe.

The Tx pin output from the sending uC seems to be at logic 0, Whereas the output pin from the nearby MAX232 which is connected to my laptop for testing purposes is at a logic 1.

The Rx input of the receiving uC seems to be at logic 1.

I am thinking since the computer output via MAX232 is logic 1 (signal from which it works), should the sendind uC Tx pin too be at logic 1?

By the way, the receiving uC Tx pin is at logic 1 (though not using it).

Maybe the start/stop bits cannot be recognised since it is initially at the wrong logic level?

PS. Ah, see what the problem was. I was scanning the key pad through port 3 which also contains the Tx pin, so I was 'sending' unwanted signals while I scanned to the other uC.

I will get that corrected and see what heppens tommorrow.

 

[AceOfHearts]

Ok, I fixed the code. I really thought this was it. But much to my disappointment, it gives the same problem.