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.

 

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.

 

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.

 

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

__________________
Measurement changes behavior

 

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

__________________
All my pencils *used* to have erasers!

 

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

__________________
Measurement changes behavior

 

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

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.

 

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.

__________________
L.Chung

 

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

__________________
Measurement changes behavior

 

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.

 

Thanks Lefty.

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.

 

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?