MS Hyperterminal UART Communication

Started by sundar_1984 November 1, 2006
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).