BasicMicro - Forums

One of the coolest things on the Atom is the hardware UART. I have noticed, however, that the time it takes to execute an HSERIN is quite long.

At 57600 baud, it takes 172us to receive a byte of data. However, it takes 1.4ms to retrieve that byte from the receive buffer using HSERIN - almost 10 times longer that it did to receive the character in the first place. This makes it very difficult to process serial data at anything approaching real time.

Moreover, the single line of code in snippet #1 (just simply looking for the CR at the end of a message) takes about the same time to execute as the loop in snippet #2. You would expect a single line of code to execute much faster than a multiline loop.

Snippet #1
HSERIN empty,10,[wait(CR)]

Snippet #2
doover:
HSERIN empty,10,[inchar]
if inchar <> CR then doover

What can I do to speed this up? Can I access the buffer directly? Is there a change that can be made to HSERIN to make it faster? I cannot change the baud rate or pacing of the sending device. Certainly it cannot take almost 1.5 milliseconds to retrieve a byte of data from a buffer in memory.

Any help you can give me is greatly appreciated.

Thanks,
RickC

1. The problem is if there is no data in the buffer the hserin command has to what for data to be received. If it is already there then it is much faster.

2. Even though it is only one line of code the same function is accuring(a comparison of the received data looping until the CR character is received so it is going to take about the same amount of time.

Nathan

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Nathan,

Thanks for the reply. However, it doesn't seem like this problem is tied to the timeout value. Note the following 2 programs:

PROGRAM #1
inchr var byte
clear
low ax2
sethserial H57600
MAIN:
pulsout ax2,5
hserstat 4, main
high ax3
hserin [inchr]
low ax3
goto main

Looking at program #1 -
PULSOUT is used as a sync point.
After receiving a byte of data and executing HSERSTAT, the HIGH AX3 executes at +76 microseconds after the sync pulse. This means that the HSERSTAT is VERY fast.
After reading the received char with HSERIN (with no timeout parameter), the LOW AX3 executes at 196 microseconds after sync. This means that the HSERIN took about 120 microseconds to execute. So far so good.

PROGRAM #2
inchr var byte
clear
low ax2
sethserial H57600
MAIN:
pulsout ax2,5
hserstat 4, main
high ax3
hserin main,100,[inchr]
low ax3
goto main

Now looking at program #2 -
Again, PULSOUT is used as a sync point.
And again, after receiving a byte of data and executing HSERSTAT, the HIGH AX3 executes at +76 microseconds after the sync pulse.
However, after reading the received char (which we know is already there because of HSERSTAT) with HSERIN (with a timeout parameter), the LOW AX3 executes at 1456 microseconds after sync (almost 1.5 milliseconds). This means that the HERSIN now took about 1380 microseconds or over 1.3 milliseconds to execute. Not so good.

Changing the timeout value (from 1 to 10 to 100) doesn't make any difference either.

(I realize that the HSERSTAT along with the HSERIN with its timeout parameters in the real world would be redundant.)

If HSERSTAT works so fast in determining if there is data available, why does HSERIN (with a timeout value) take so long?

Thanks,
RickC

[This message has been edited by RickC (edited 05-27-2003).]

I'll have to look into that. Could you email me with this possible issue so I don't forget.

Nathan

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Be glad to.

Is support@basicmicro.com the proper address to send it to?

Thanks,
RickC

Nathan,

Any progress on this issue yet?

Thanks
RickC

Yes, support@basicmicro.com is the correct email to send this to.

Nathan

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Yes, this is a very old thread. =)
I am quite interested in the answer.
Any news?

BEX

No additional news. But I feel sure you can read LOTS of bytes, in 1.5 mSec, as well as a single byte.