serialport read buffer

[chenatcr]

Hello,

I added a serial-USB converter to my laptop, it appear as USB serial
port COM4, and I wrote an application to read 78k data from this port.
In my VC++ express code, I defined ReadBufferSize = 78k, and
ReceivedBytesThreashold = 78k so that I can get the whole data with
one ReadExisting() method when DataReceived event fires.



However, everytime the readbuffer only received 4096 bytes, but when I
test the same code with real serial port COM1, it received full 78k
data. There is no buffer configuration in driver of USB converter, and
it's impossible the converter has 4k limitation, this is confirmed
when I use hypertermial to capture the data, I got full 78k data too.

There must be something I don't know in .net or serialport class. Can
anyone tell me where I am wrong?



Thanks a lot!

 

[Ben Voigt]

Hello,

I added a serial-USB converter to my laptop, it appear as USB serial
port COM4, and I wrote an application to read 78k data from this port.
In my VC++ express code, I defined ReadBufferSize = 78k, and
ReceivedBytesThreashold = 78k so that I can get the whole data with
one ReadExisting() method when DataReceived event fires.



However, everytime the readbuffer only received 4096 bytes, but when I
test the same code with real serial port COM1, it received full 78k
data. There is no buffer configuration in driver of USB converter, and
it's impossible the converter has 4k limitation, this is confirmed
when I use hypertermial to capture the data, I got full 78k data too.

How does this prove the converter has no 4k limitation? Hyperterminal will
immediately call ReadFile again each time any data is received, until of
course the whole block is eventually received.

Have you used sysinternals (now part of Microsoft TechNet) portmon to
discover the actual call sequence?

There must be something I don't know in .net or serialport class. Can
anyone tell me where I am wrong?

I suspect BeginRead/EndRead would "work" more often. What happens is that
as soon as the PC becomes aware that data is received (one USB frame worth),
the DataReceived event fires. But you should always handle partial reads,
and issue a new read for the remaining data.

 

[Guest]

I use these converters all the time, and as Ben surmised, the drivers (for
the ones I use, at least) are limited to 4096 bytes at a time. You'll have to
make multiple calls to read all 78 K.

 

[Guest]

I was looking for confirmation of this 4096 byte limitation I'm having using
writefile on an open serial port connected to a bluetooth dongle and I saw
these posts .
Unfortunately turning the single write into multiple 4k writes introduces
some performance problems on the device I'm communicating with - there is a
big hit getting the i/o going . My tests show this isn't much of an issue if
the other device is a PC but not so with my bluetooth dip module . Sigh.
Also I will make note of the fact that you don't get an error , just a
reduced number of bytes written to signal you to the fact the behavior is
different than native serial port I/O .
Sigh.

 

[Ben Voigt [C++ MVP]]

I was looking for confirmation of this 4096 byte limitation I'm having
using
writefile on an open serial port connected to a bluetooth dongle and I saw
these posts .
Unfortunately turning the single write into multiple 4k writes introduces
some performance problems on the device I'm communicating with - there is
a
big hit getting the i/o going . My tests show this isn't much of an issue
if
the other device is a PC but not so with my bluetooth dip module . Sigh.

I would suggest getting a USB bluetooth dongle and take out the serial
conversion entirely. The maximum rate of bluetooth is much higher than
async serial typically reaches.

Also I will make note of the fact that you don't get an error , just a
reduced number of bytes written to signal you to the fact the behavior is
different than native serial port I/O .

That's true, and while it's more common dealing with sockets, any time you
do I/O you should be prepared that only part of your data was accepted and
you need to call again with the rest.