Actually I intend to design a DLL interface for serial communication supporting MARK and SPACE mode. When the data from outside come, I wish the simulation to put them into the registers of the 8051. However, as mentioned before, the SBUF seems of little use, and 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. What should I do to get the data into the registers? Thanks!
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.