Hello
I try to set up a test environment with the keil environment with an ADUC848 from analog device.
Basically my application acquires data from ADC and sends it to a host on UART link every 240 ms, and waits for an acknowledge from the host.
The acquisition is started when a “HELLO frame is received “, so the protocol communication protocol looks like that:
HOST : Send Hello
Simulated ADUC848 : Ack Hello
Simulated ADUC848 : Send DATA t0
HOST : Ack DATA
Simulated ADUC848 :Send DATA t0 + 240 ms
Simulated ADUC848 : Send DATA t0 + 480 ms
....
The UART link between keil simulator and the host are by a cross cable between COM1 ( the host) and COM4 (connected to keil simulator)
The communication protocol is set with a baud rate of 9600 bps, and 9 data bits with even parity.
The communication between host and simulator are correct, the Hello frame is received by the simulator, and correctly acknowledged to the host.
The Data frame has a length of 26 characters, so the expected time of transmission it 26/27 ms ( at 9600 bps).
By installing an UART spy between host and simulator, I measure a total sending time of data frame about 235-250 ms, with some times a gap of 30 to 40 ms between each sendig of a character.
Waht could be the reason for this large time to send the frame ? A clue to solve this problem ?
Thanks in advance.
Nicolas BERTRAND
A simulator is not an emulator. It isn't perfect. To get the expected speed, the serial port on the PC must be constantly filled.
Are you using any FIFO function of the target UART so that your source code is pushing in multiple characters at a time into the serial port?
To whom may know: are there any C51 with FIFO support for the UART?
Next step is if Keil can pick up multiple characters from the simulated machine and send to Windows to allow the physical serial port to run at max speed, or how fast your program can manage to detect that the previous character has been sent and insert a new character for transmission.
You can never expect 100% perfection when using one hardware to simulate another hardware. Another thing is that the speed of your PC will affect how fast Keil can simulate your processor. And when your PC is busy doing other things, the emulation will pause.
In this case, Keil may wait until one character has been transmitted out the PC port before letting your simulated C51 know that you may insert the next character.
Thanks for the response.
I have implemented a FIFO for TX and RX. The transmission is made by the UART ISR.
And I have not this type of problem, on the real hardware.
@ Per Westermark say: "In this case, Keil may wait until one character has been transmitted out the PC port before letting your simulated C51 know that you may insert the next character."
I don't know how I can check this point.
regards
Nicolas
When I wrote FIFO, I didn't mean the general case of first-in-first-out as in your normal ring-buffer for pending data to send, but an UART that has hardware FIFO to allow multiple characters to be given to the UART at the same time.
It is only with a UART with FIFO that you may let the simlated machine see more than one character at a time, allowing the simulator to send more than one character to the Windows serial driver.
With a UART without FIFO, you have to assume that there will be a pause between each sent character, since the PC UART runs dry and have to wait until the simulator wakes your program so you can put a new character into the simulated UART so there will be any character to restart the PC UART with.
In short: It is expected that a simulation will not be able to run the PC serial port at optimum speed. If the simulated UART has FIFO support and the program makes use of it, then the simulator has a better chance of keeping the PC UART constantly running. When Keil simulates the serial port for logging to the IDE or a file, it is possible to set an option that the simulator should ignore baudrate and instantly allow the simulated UART to accept more characters. But that is a special case intended for logging of data - not for use as a general serial port with hand-shake signals and data being sent in both directions.