One more question

I am still confused, actually I want to simulate the serial communication without the physical realization. Thus the behavior RXD seems to be unable to be simulated in Keil. And when data come, indeed they come in together, which is realized using buffers in my DLL. In this case I would like to put value into the registers in 8051 directly, could you explain in more detail what can I do? i.e which operation should I take to put values all at once?

I am still confused, actually I want to simulate the serial communication without the physical realization. Thus the behavior RXD seems to be unable to be simulated in Keil. And when data come, indeed they come in together, which is realized using buffers in my DLL. In this case I would like to put value into the registers in 8051 directly, could you explain in more detail what can I do? i.e which operation should I take to put values all at once?

DLL?? are you writting Code for the 8051, or the simulator?
SBUF = 'A';
temp = SBUF;
does not put and 'A' in temp.
Data written to SBUF is "clocked out the tx pin by the UART. This happens at UART speed. "TI" tells you it is done.
Reading SBUF gets you the byte from the input buffer of the UART. It holds 1 byte. If you do not read a byte before the next one is recieved it is over-written.
RXD works in real life and on the simulator.

"I have tried SIN, which I assumed that the value in SBUF would change with it accordingly but found that it was of no help."

As Reinhard said to you initially, you need to explain precisely why you consider SIN to be "of no help"

What exactly have you done?
How did you test it?
What did you expect to happen?
What actually happened?

It appears that the uVision manual is not available online, so you'll just have to read the PDF version installed on your PC.
You need the uVision Getting Started Guide - available on the 'Books' tab in the 'Project' Window (The 'Books' window is also available via the 'Help' menu; failing all that, search for GS51.PDF in your Keil folder).

The version I have is dated 02.2001, and the SxIN and SxOUT VTREGs are described on page 114, under the heading "CPU Pin Registers (VTREGs)".

(for chips with only 1 UART, SxIN is SIN; with >1 UART, you get S0IN, S1IN, etc...)

I paste my simple test program here:

#include<reg52.h>
#define tovf1 0xFD
void serial_interrupt();
void main()
{
TH1 = tovf1;
TL1 = tovf1;
TMOD = 0x20;
TR1 = 1;
PCON =0xBF;
SCON = 0x50;
IE = 0x90;
while(1){}
}
void serial_interrupt() interrupt 4 using 1
{
	unsigned char ch;
	IE=0x10;
	ch = SBUF;
	RI = 0;
	TI = 0;
	IE=0x90;
	return;
}

I think writing that DLL was a waste of time. uVision2 can already establish a virtual connection between the simulated 8051's serial port and a physical COM port of your PC without it. See the "ASSIGN" command in the "uVision2 Debug Commands" manual.

As previously noted, uVision can already use the PC's COM port(s) for simulator serial IO.

Have you verified that your 8051 code works with the standard uVision COM port interface?

If your 8051 code works with the standard uVision COM port interface, then the fault must lie in your DLL.

Have you actually tried the example program & DLL in the AGSI Application Note?

As previously noted, uVision can already use the PC's COM port(s) for simulator serial IO.

The problem is the uVision is unable to simulate the serial transmission in MARK or SPACE mode, so I have to write my own DLL to realize it.

Have you verified that your 8051 code works with the standard uVision COM port interface?If your 8051 code works with the standard uVision COM port interface, then the fault must lie in your DLL.


I have successfully write the data from COM2 into SIN, which could be watched in the debugger, and nothing happened to the internal registers and variables located in the memory.

Have you actually tried the example program & DLL in the AGSI Application Note?
Do you mean the A/D and Timer? I have tried them.

As previously noted, uVision can already use the PC's COM port(s) for simulator serial IO.

The problem is the uVision is unable to simulate the serial transmission in MARK or SPACE mode, so I have to write my own DLL to realize it.

Have you verified that your 8051 code works with the standard uVision COM port interface?If your 8051 code works with the standard uVision COM port interface, then the fault must lie in your DLL.


I have successfully written the data from COM2 into SIN, which could be watched in the debugger, and nothing happened to the internal registers and variables located in the memory.

Have you actually tried the example program & DLL in the AGSI Application Note?
Do you mean the A/D and Timer? I have tried them.

The problem is the uVision is unable to simulate the serial transmission in MARK or SPACE mode

I do not use the simulator, but am heavily involved in many types of serial comm. Something here puzzles me: the RS232 standard IS "mark and space"
e.g.
http://www.tldp.org/HOWTO/Text-Terminal-HOWTO-22.html
states
A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic 0)

so how can ANYTHING that support the PC serial port not support "mark and space"

Pleae inform, I'd love to hear about it.

Erik

A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic 0)
I am not proficient in serial comm. What I learned is that in MARK mode the parity is always 1, whereas in SPACE mode the parity is 0. And in keil we could not simulate this function in that it only provide mode 0(no parity),1(odd parity),2 (even parity).

But this is not the relevant matter, my focus is writing the data from DLL into the registers or variables in simulation.

If your 8051 code works with the standard uVision COM port interface, then the fault must lie in your DLL.

I have tried the code assigning com1 to sin and sout, however, ch can not get the value from com2.

"I have tried the code assigning com1 to sin and sout, however, ch can not get the value from com2."

Well of course it can't!

If you've assigned SIN and SOUT to COM1 they will obviously not get anything from COM2!!!

If you've assigned SIN and SOUT to COM1 they will obviously not get anything from COM2!!!

As previously described, I run a program sending data from COM2 to COM1!

"What I learned is that in MARK mode the parity is always 1, whereas in SPACE mode the parity is 0."

Not quite - you are suffering from sloppy terminology, I'm afraid.

There is no such thing as "Mark Mode" nor "Space Mode." What you are talking about is "Mark-Parity" and "Space-Parity" - ie, when the Parity bit is "fixed" in the Mark or Space state, irrespective of the other bits in the byte.

Anyhow, why do you specifically need this setting?

"I run a program sending data from COM2 to COM1!"

Have you checked independently that the connection from COM2 to COM1 is actually working?

eg, by using Hypoterminal?

Yes, I have checked them, they are working normally.

My previous test in the keil is using the program pasted above. I checked it assigning COM1 to sin and sout, while using a program to send out data from COM2.