Subj : Re: win32 - High speed serial streaming code???
To   : comp.programming
From : David
Date : Thu Sep 01 2005 11:18 am

On Wed, 31 Aug 2005 06:39:38 UTC, "DarkD" <darkd@NOSPAMoptusworld.com.SPAM.au> wrote:

> I need to capture data from a serial device that has 115200bps output. Its
> continously outputs 3byte packets 1250 times per second.
> 
> I have tried using the win standard way to do serial port access (CreateFile
> ReadFile etc.) and cannot obtain anywhere near 3750 bytes per second. The
> system is completely dropping some data.
> 
> The 3rd byte in every packet is 0xFF and the packets can have no break in
> time between the 3rd byte of one and the first of the next. I am not sure if
> 0xFF is affecting anything. Alot of the packets are: 0x00 0x00 0xFF, so im
> not sure if this is cuasing the problem either.
> 
> I have tried use setupcomm to give massive buffers (30KB etc.) and can't get
> close to 3750 bytes per second
> .
> With ReadFile how many bytes should I be reading? If I put 3 I can get about
> 100 packets per second. If I put 1000bytes I get about 200 packets per
> second...
> 
> I am using visual c++
> 
> I know it is not a CPU performance thing because this is a 3GHz P4 and the
> CPU usuage is zero all the time.
> 
> Is there some other way to low level access the uart chip so I can stream in
> this data fully? I cannot understand why modern computer cannot continously
> stream and save data at 115200bps.
> 
> I have also tried event based triggering and the performance is just as bad.

  You are correct, there shouldn't be a problem keeping up with that amount
of data (all things being equal).  I've occasionally had 115200 fail due to
the cabling.  My serial code did spit out a parity error or whatever was
appropriate.  I don't have access to the code from home but it appeared to
be derived from some standard examples from many years ago.

  Without knowing anything more, I suspect that your base serial stream read
code is correct.  However, your next level is probably not responsive enough
and by the time you look for more data the buffer has overflowed.  Please
remember that if you intend to have a Windows application maintain sustained
operations, they are best kept away from the Windows Event Loop.  I generally
keep a couple layers of threads associated with each serial or TCP stream.
These are loosely coupled to higher layers that interpret the streams and
queue response data where necessary.  This idea may help you sustain your
throughput without loss.

  What kind of errors are you getting from your serial stream code?  You
may want to watch for parity, buffer overrun, and the other available
serial errors that can be reported.  This will help you identify what
needs to be done next.

  Good luck,

  David

.