>sundar_1984 wrote:
>> 
>> Hi i m sorry for i could not reply to this post at the earliest.
>> Frankly i wasnt aware that posts can also be on the usenet and not only
by
>> mail.
>> 
>> Well the recievr is not mine. it has reciver FIFO enabled but its 1
byte.
>
>Lacking any quotations, your reply is totally meaningless.  Every
>article should stand by itself.  Previous traffic may, in fact
>probably, is not available to your readers.
>
>-- 
>Chuck F (cbfalconer at maineline dot net)
>   Available for consulting/temporary embedded and systems.
>   <http://cbfalconer.home.att.net>
>
>
Sorry Guys for the delay. Ws out of college on a vactiona ndnow i m back.
Well, after reading all the posts to this query the following points are
cleared further.:
1. No i dont use a usb-serial adapter.
2. I use only the RS232 Cable to connect to my receever and my PC>
3. I have tried this thing out with TeraTerm also and i find that i need
to have that 1ms delay there too to get the valid ack messages.
4. the reciver is not mine. I dont hve the source code for the reciever,
else there wouldnt hve been any problem at all in debugin the transfer.
5. As far as i recall enabling/disabling the FIFO does not have any efect
on slwoing the transfer bcoz everything is controlled by the LSR only in
this case of No flow control applications.

Awaiting further replies...

Thanx

sundar_1984 wrote:
> 
> Hi i m sorry for i could not reply to this post at the earliest.
> Frankly i wasnt aware that posts can also be on the usenet and not only by
> mail.
> 
> Well the recievr is not mine. it has reciver FIFO enabled but its 1 byte.

Lacking any quotations, your reply is totally meaningless.  Every
article should stand by itself.  Previous traffic may, in fact
probably, is not available to your readers.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

Sorry Guys for the delay. Ws out of college on a vactiona ndnow i m back.
Well, after reading all the posts to this query the following points are
cleared further.:
1. No i dont use a usb-serial adapter.
2. I use only the RS232 Cable to connect to my receever and my PC>
3. I have tried this thing out with TeraTerm also and i find that i need
to have that 1ms delay there too to get the valid ack messages.
4. the reciver is not mine. I dont hve the source code for the reciever,
else there wouldnt hve been any problem at all in debugin the transfer.
5. As far as i recall enabling/disabling the FIFO does not have any efect
on slwoing the transfer bcoz everything is controlled by the LSR only in
this case of No flow control applications.

Awaiting further replies...

Thanx

Hi i m sorry for i could not reply to this post at the earliest.
Frankly i wasnt aware that posts can also be on the usenet and not only by
mail.

Well the recievr is not mine. it has reciver FIFO enabled but its 1 byte.

Not Really Me wrote:

> I use a cheap USB-Serial adapter and it works a whole lot better than 
> hyperterminal.

Setting aside that pretty much anything that can drive a serial port on 
Windows works a whole lot better than Hypoterminal, that statement 
doesn't make any sense at all.  You just stated an analogon of: "I use a 
cheap car and it works a whole lot better than a pair of trousers".

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.

Like everything else from that place. Teraterm works nicely for me
(during unfortunate periods of running Windows).

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

On Thu, 02 Nov 2006 18:03:12 +0000, Grant Edwards wrote:

> 
> You probably could have sped up the conventional serial port
> drastically by setting the low latency flag and setting the RX
> FIFO size to 1 on the device using the setserial program.  By
> default, the Linux serial drivers are set up to be optimal for
> things like PPP that transfer largish blocks of data (more than
> 10ms worth).  
> 
> The default configuration is it's pretty sub-optimal for things
> like sending a single byte and waiting for a single byte to
> come back.

Thanks for info. Next time I use the software I'll investigate further.

Regards,

Paul.

On 2006-11-02, Paul Taylor <paul_ng_pls_rem@tiscali.co.uk> wrote:
> On Thu, 02 Nov 2006 02:51:13 +0000, Grant Edwards wrote:
>
>> 
>> 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).

> I have a usb-serial adapter that I was suprised to find that total
> transfer time was halved compared to a conventional serial port in one
> particular application (both under Linux). The application sends out a
> character and then waits for it to be echoed back before sending the next
> character. I have used the adapter on several different flavours of Linux
> and it behaved the same. Suprised.

You probably could have sped up the conventional serial port
drastically by setting the low latency flag and setting the RX
FIFO size to 1 on the device using the setserial program.  By
default, the Linux serial drivers are set up to be optimal for
things like PPP that transfer largish blocks of data (more than
10ms worth).  

The default configuration is it's pretty sub-optimal for things
like sending a single byte and waiting for a single byte to
come back.

-- 
Grant Edwards                   grante             Yow!  .. does your DRESSING
                                  at               ROOM have enough ASPARAGUS?
                               visi.com            

On Thu, 02 Nov 2006 02:51:13 +0000, Grant Edwards wrote:

> 
> 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).
> 

I have a usb-serial adapter that I was suprised to find that total
transfer time was halved compared to a conventional serial port in one
particular application (both under Linux). The application sends out a
character and then waits for it to be echoed back before sending the next
character. I have used the adapter on several different flavours of Linux
and it behaved the same. Suprised.

Regards,

Paul.

"chris" <c@b.a> wrote in message 
news:8ec2h.57254$rP1.29845@news-server.bigpond.net.au...
> 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.

I use a cheap USB-Serial adapter and it works a whole lot better than 
hyperterminal.

I like Com7.6 as a com program, but it won't run faster than 115,200 even 
though the USB/Serial will run at 921,600.

Scott