SerialPort hardware handshaking problem (not the usual one)

[Steve Mowbray]

Hi

I am using SerialPort component to send raw binary files to a remote device
with RTS/CTS handshaking - the remote device has a small receive buffer and
is slow so needs to be hardware flow controlled to prevent the PC sending
too much data per second. Here is my attempt at setting the hardware
handshake operation:

serialPort1->Handshake = System::IO::Ports::Handshake::RequestToSend;
serialPort1->RtsEnable = true;

However the port outputs data at max rate with data loss at the receiving
end.

Using Hyperterminal with the appropriate settings on the same COM port works
perfectly so I assume its my code that is missing something - any help would
be appreciated.

I am using Visual Studio 2008 Express on WinXP and have TI UART chipset on
the COM port.

Cheers
Steve

[Dick Grier]

Hi,

Your application fills the UART Tx FIFO (16 bytes) much faster than your
fingers (HyperTerminal). The communications driver only responds to
lowering CTS in filling the FIFO -- anthing already in the FIFO will be sent
regardless of CTS state.

So, what you have to do is to break your send data into "chunks" of less
than 16 bytes, and put an adjustable delay between sending each "chunk." I
suggest that you try (say), 8 bytes at a time, and start with a delay of
(say) 10 mS between each chunk. Reduce this delay until things fail (or
increase it), then you know what works and what doesn't. Add a little
"slop" for safety.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Steve Mowbray]

A couple of things I should have mentioned, I am using the TI chipset UART
which does single byte hardware handshaking and I am using the Hyperterminal
send text file (which sends binary no bother also). Hyperterminal correctly
sends data at about continuous 8kBytes/s being the max receive capability of
the serial device (and with 100% integrity) but my SerialPort program
squirts data out at about 10.5kBytes/s being the max rate at 115200 baud. So
I am sure that the PC configuration is capable of doing this hardware
handshaking ok - just my VSC++.NET programming knowledge that is lacking...

Still looking for a SerialPort hardware handshake configuration.

Cheers
Steve

"Dick Grier" <dick_grierNOSPAM@.msn.comwrote in message
news:#d**************@TK2MSFTNGP05.phx.gbl...

Hi,

Your application fills the UART Tx FIFO (16 bytes) much faster than your
fingers (HyperTerminal). The communications driver only responds to
lowering CTS in filling the FIFO -- anthing already in the FIFO will be
sent regardless of CTS state.

So, what you have to do is to break your send data into "chunks" of less
than 16 bytes, and put an adjustable delay between sending each "chunk."
I suggest that you try (say), 8 bytes at a time, and start with a delay of
(say) 10 mS between each chunk. Reduce this delay until things fail (or
increase it), then you know what works and what doesn't. Add a little
"slop" for safety.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Steve Mowbray]

Ach this is a stupid non-issue after all

The serial driver seems to get itself into state where hyperterminal still
functions but my .NET app doesnt - reboot PC solves problem - hardware
handshaking works all round. Still confused why the port gets into this
state but when it does all I need do is reboot...

"Steve Mowbray" <st***********@hotmail.comwrote in message
news:26**********************************@microsof t.com...

A couple of things I should have mentioned, I am using the TI chipset UART
which does single byte hardware handshaking and I am using the
Hyperterminal send text file (which sends binary no bother also).
Hyperterminal correctly sends data at about continuous 8kBytes/s being the
max receive capability of the serial device (and with 100% integrity) but
my SerialPort program squirts data out at about 10.5kBytes/s being the max
rate at 115200 baud. So I am sure that the PC configuration is capable of
doing this hardware handshaking ok - just my VSC++.NET programming
knowledge that is lacking...

Still looking for a SerialPort hardware handshake configuration.

Cheers
Steve

"Dick Grier" <dick_grierNOSPAM@.msn.comwrote in message
news:#d**************@TK2MSFTNGP05.phx.gbl...

>Hi,

Your application fills the UART Tx FIFO (16 bytes) much faster than your
fingers (HyperTerminal). The communications driver only responds to
lowering CTS in filling the FIFO -- anthing already in the FIFO will be
sent regardless of CTS state.

So, what you have to do is to break your send data into "chunks" of less
than 16 bytes, and put an adjustable delay between sending each "chunk."
I suggest that you try (say), 8 bytes at a time, and start with a delay
of (say) 10 mS between each chunk. Reduce this delay until things fail
(or increase it), then you know what works and what doesn't. Add a
little "slop" for safety.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications,
Fourth Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Dick Grier]

Hi,

I have no real idea. The serial driver use is identical. HyperTerminal
uses a different API to access that driver than the serial port. Still, I
have my doubts about the implementation of the driver itself. Manufacturers
are do not always implement all features of the hardware (though, someone
like Quatech or other responsible manufacturer should).

If I were to guess, I'd speculate that, somehow, the standard serial driver
is being used when you have trouble, and the specialized one is being used
after reboot. What might cause such a thing is beyond my ken.

Still, character pacing should work. I've found it to be necessary with a
number of devices, and (at the end of the day), the performance is about as
good as if everything else worked "as designed," instead of "as
experienced."

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Steve Mowbray]

aye - who knows - getting too used to these Win32 driver peculiarities
unfortunately.

My application might not work across the board on every PC - but I already
guessed that since I was relying on the TI chipset feature of RTS working
per byte rather than per 16 byte burst although I was hoping that modern
motherboards would have improved UART chipsets and hoping even more that
decent USB-serial convertors will do the same trick. BTW the connected
serial device is slow and only has a 1 byte receive buffer hence the
difficulties.

Thanks for your suggestions - I might fall back on the software rate control
method you mentioned if I run into more trouble.
Cheers
Steve
"Dick Grier" <dick_grierNOSPAM@.msn.comwrote in message
news:uT**************@TK2MSFTNGP05.phx.gbl...

Hi,

I have no real idea. The serial driver use is identical. HyperTerminal
uses a different API to access that driver than the serial port. Still, I
have my doubts about the implementation of the driver itself.
Manufacturers are do not always implement all features of the hardware
(though, someone like Quatech or other responsible manufacturer should).

If I were to guess, I'd speculate that, somehow, the standard serial
driver is being used when you have trouble, and the specialized one is
being used after reboot. What might cause such a thing is beyond my ken.

Still, character pacing should work. I've found it to be necessary with a
number of devices, and (at the end of the day), the performance is about
as good as if everything else worked "as designed," instead of "as
experienced."

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Dick Grier]

Hi,

It is quite unlikely that manufacturers will use the more expensive UARTs in
their designs. The require a specialized serial driver, and cost is
EVERYTHING. 99.9% of all users would never notice.

BTW, about 40% of computers, these days, are notebook-class. Thus, they use
USB serial adapters. The serial port "end," (AFAIK) does not support
byte-by-byte handshaking, and the FIFOs iin the Virtual Serial Port
(software UART) tend to be about 98 bytes.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.