Jan and Andy already have some great suggestions here, but I'd like to add that you should verify that your embedded application is in fact really transmitting what you think it is. There are a number of things that can go wrong, including incorrectly setting the serial port mode, baud rate, and so forth. Another common mistake made by newcomers is failing to wait for the transmission to complete before sending another byte. In an interrupt-based design with some sort of more formal software FIFO implemented, this tends to be less of a problem, but when doing polled I/O, it is quite easy to overlook this.

A nice test is to write some test code that does nothing but repeatedly writes the letter "U" to the serial port. This has the nice property, when transmitting in 8-N-1 mode (arguably the most common), of putting a 50% duty cycle waveform on the TXD pin, and allowing you to verify much of your serial transmission functionality. The time for each bit (e.g., period/2) should be 1/baudrate; in the case of 19200 bps transmission, for example, that works out to 1/19200 = 52.08 microseconds. In a polled I/O application (I am not endorsing polled serial communication here; this is just an example), you could do this with code similar to the following:

tstlp: mov sbuf,#h'55
serwt: jnb scon.1, serwt
       clr scon.1
       sjmp testlp

Once your 8051 is up and running with this, use your scope to verify the duty cycle, period, and voltages (high and low; see Beyond Logic for more details).

Good luck.

--Sasha Jevtic