MS Hyperterminal UART Communication

Hi All,

I am trying to communicate with a black box reciever with its onchip uart
tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
of size 105KB to the reciever from my PC through the Hyperterminal but with
a character delay of 1 ms. If i dont keep that character delay, i dont get
the required acks back from the reciever. And sending with a 1ms delay
takes about 28 minutes to get into the reciever and give me valid
acknowledgement. 

Please help me configure out a way for this problem and also why at 115200
bps, this much time should be taken...

Thanx in Advance for those who care to reply...

sundar_1984 wrote:

> I am trying to communicate with a black box reciever with its onchip uart
> tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
> of size 105KB to the reciever from my PC through the Hyperterminal but with
> a character delay of 1 ms. If i dont keep that character delay, i dont get
> the required acks back from the reciever. And sending with a 1ms delay
> takes about 28 minutes to get into the reciever and give me valid
> acknowledgement.
>
> Please help me configure out a way for this problem and also why at 115200
> bps, this much time should be taken...

You're not saying anything about the receiver. Is it your own
product/design, or did you purchase it ?

Perhaps it doesn't have a Rx FIFO, and it takes some time to process
each character.

In article <1162396447.880596.135050@e64g2000cwd.googlegroups.com>, 
usenet+5@ladybug.xs4all.nl says...
> sundar_1984 wrote:
> 
> > I am trying to communicate with a black box reciever with its onchip uart
> > tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
> > of size 105KB to the reciever from my PC through the Hyperterminal but with
> > a character delay of 1 ms. If i dont keep that character delay, i dont get
> > the required acks back from the reciever. And sending with a 1ms delay
> > takes about 28 minutes to get into the reciever and give me valid
> > acknowledgement.

> >
> > Please help me configure out a way for this problem and also why at 115200
> > bps, this much time should be taken...
> 
> You're not saying anything about the receiver. Is it your own
> product/design, or did you purchase it ?
> 
> Perhaps it doesn't have a Rx FIFO, and it takes some time to process
> each character.

This is a problem crying out for an oscilloscope.  You need to take a 
look at the time delay between the transmission of your character and
the receipt of the ACK character.   If that time is less than about
1 millisecond, and the time between transmitted character the problem
is with Windows and Hyperterm.


Windows is notoriously bad with programmmed delays---they often end up
being some multiple of the old DOS time tick---which is about 55 
milliseconds, IIRC.  It may be that  Hyperterm is really extending
your desired 1Msec delay to 18msec.   

You could also figure that out by examining the output from Hyperterm
with an oscilloscope.  Since you may not have one handy,  I did this
test for you---and voila!   The time between characters with a specified
1mSec character delay  is somewhere between  10 and 20 milliseconds---
and varies greatly.    This seems to support the  hypothesis that 
Hyperterm is using a delay routine with a clock that ticks at somewhere 
between 50 and 60Hz.

I think you need to figure out how to do this transfer without
the character delays.  If you really need an ack for each 
character, your transmission time should depend on the speed
with which the receiver can fetch the input character and send
the ACK.

Mark Borgerson

sundar_1984 <sunder.svit@gmail.com> wrote:
> Hi All,
> 
> I am trying to communicate with a black box reciever with its onchip uart
> tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
> of size 105KB to the reciever from my PC through the Hyperterminal but with
> a character delay of 1 ms. If i dont keep that character delay, i dont get
> the required acks back from the reciever. And sending with a 1ms delay
> takes about 28 minutes to get into the reciever and give me valid
> acknowledgement. 
> 
> Please help me configure out a way for this problem and also why at 115200
> bps, this much time should be taken...

Maybe your device uses hardware handshaking signals to indicate to the
host (e.g. hyperterm) that it is ready to receive data. Check if your
box' manual says anything about the type of handshaking and cable that
should be used.

-- 
:wq
^X^Cy^K^X^C^C^C^C

On 2006-11-01, sundar_1984 <sunder.svit@gmail.com> wrote:
> Hi All,
>
> I am trying to communicate with a black box reciever with its onchip uart
> tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
> of size 105KB to the reciever from my PC through the Hyperterminal

After dealing with Hyperterminal for many years, I find that a
good working hypothesis is:

  "It's Hyperterminal's fault."

Start by getting a decent terminal emulator.  Teraterm is free
and way, way better than HT.  There are other free terminal
emulators as well.  All are vastly better than Hyperterminal.

HT is a waste of bits.

-- 
Grant Edwards                   grante             Yow!  I'm thinking about
                                  at               DIGITAL READ-OUT systems
                               visi.com            and computer-generated
                                                   IMAGE FORMATIONS...

Grant Edwards wrote:
> On 2006-11-01, sundar_1984 <sunder.svit@gmail.com> wrote:
>> Hi All,
>>
>> I am trying to communicate with a black box reciever with its onchip uart
>> tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
>> of size 105KB to the reciever from my PC through the Hyperterminal
> 
> After dealing with Hyperterminal for many years, I find that a
> good working hypothesis is:
> 
>   "It's Hyperterminal's fault."
> 
> Start by getting a decent terminal emulator.  Teraterm is free
> and way, way better than HT.  There are other free terminal
> emulators as well.  All are vastly better than Hyperterminal.
> 
> HT is a waste of bits.
> 

Seconded, also this sounds suspiciously like a (cheap) USB-Serial 
adapter is being used - is it the case?

Chris.

On 2006-11-02, chris <c@b.a> wrote:

>>> I am trying to communicate with a black box reciever with its
>>> onchip uart tuned to 115200 bps, 8 data bits, and 1 stop bit.
>>> I am sending a text file of size 105KB to the reciever from my
>>> PC through the Hyperterminal
>> 
>> After dealing with Hyperterminal for many years, I find that a
>> good working hypothesis is:
>> 
>>   "It's Hyperterminal's fault."
>> 
>> Start by getting a decent terminal emulator.  Teraterm is free
>> and way, way better than HT.  There are other free terminal
>> emulators as well.  All are vastly better than Hyperterminal.
>> 
>> HT is a waste of bits.
>
> Seconded, also this sounds suspiciously like a (cheap)
> USB-Serial adapter is being used - is it the case?

That could be -- I didn't think to ask about that.

Unfortunately paying more doesn't always mean it's going to
work better.  Some of the cheap ones work fine, some of the
expensive ones don't.

They all seem to work better under Linux than Windows (at least
for me).

Even with the ones that work fine, trying to do anything with
them that requires precise timing is futile.  With a USB
adapter, you can't expect to something like a 1ms delay between
characters.  

Even with an directly connected UART getting reliable 1ms
delays between bytes just isn't going to happen unless you're
using an RTOS.

-- 
Grant Edwards                   grante             Yow!  Yes, but will I
                                  at               see the EASTER BUNNY in
                               visi.com            skintight leather at an
                                                   IRON MAIDEN concert?

chris wrote:

> Seconded, 

Thirded! ;)

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

On Wed, 1 Nov 2006 11:52:59 -0800, Mark Borgerson
<mborgerson@comcast.net> wrote:

>
>Windows is notoriously bad with programmmed delays---they often end up
>being some multiple of the old DOS time tick---which is about 55 
>milliseconds, IIRC.  It may be that  Hyperterm is really extending
>your desired 1Msec delay to 18msec.   
>
>You could also figure that out by examining the output from Hyperterm
>with an oscilloscope.  Since you may not have one handy,  I did this
>test for you---and voila!   The time between characters with a specified
>1mSec character delay  is somewhere between  10 and 20 milliseconds---
>and varies greatly.    This seems to support the  hypothesis that 
>Hyperterm is using a delay routine with a clock that ticks at somewhere 
>between 50 and 60Hz.

On single processor NT/2000 systems the Sleep(1) nominally 1 ms delay
would be about 0-10 ms, on multiprocessor systems 0-16 ms. However, if
the multimedia timers are enabled, Sleep(1) would at least try to
sleep for about 1 ms, of course there can be large variations
depending of load, even when the program executes in the realtime
priority class.

Paul

sundar_1984 wrote:
> Hi All,
> 
> I am trying to communicate with a black box reciever with its onchip uart
> tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text file
> of size 105KB to the reciever from my PC through the Hyperterminal but with
> a character delay of 1 ms. If i dont keep that character delay, i dont get
> the required acks back from the reciever. And sending with a 1ms delay
> takes about 28 minutes to get into the reciever and give me valid
> acknowledgement. 
> 
> Please help me configure out a way for this problem and also why at 115200
> bps, this much time should be taken...
> 
> Thanx in Advance for those who care to reply...
> 

That works out to around 16 ms per character - it sounds like you are 
using toy windows, which uses a resolution of something like 50 - 60 Hz 
for all its timing.  If you want to have more accurate timing, you'll 
have to get an NT-based windows (or another OS altogether...)

Using Hyperterminal for serial communication is a bit like using Wordpad 
as a programmer's editor - it's theoretically possible, but seriously 
masochistic, and there are thousands of free, vastly superior 
alternatives.  As others have mentioned, Tera Term Pro is the best 
solution in about 90% of cases.  For those few needing more control and 
features, Realterm is a good bet.

Looking at the actual problem, you're going to have to find out more 
about the receiver and why it needs this delay.  It could be that you 
can use a lower baud rate with no delay for better throughput, and you 
could also try using two stop bits (effectively, this adds an extra bit 
delay between characters).