SerialPort Class too slow & CPU Hog?

  • Thread starter Thread starter Kevin
  • Start date Start date
K

Kevin

Does anyone out there happen to have experience using VC# (or any .NET
really) to control the serial port for demanding use? My ultimate
goal would be to stream an arbitrarily large size (MB+) file out over
the serial port with zero down time at speeds ranging from 9600 to
480600 baud.

While using the SerialPort Control, I cannot come up with an
implimentation that doesn't A) hog the CPU at 100% and B) is able to
continually fill the TX buffer before it empties itself.

If anyone has done this, or even come close, I'd be very appreciative
of your help and suggestions. Thanks!

- Kevin
 
Kevin said:
Does anyone out there happen to have experience using VC# (or any .NET
really) to control the serial port for demanding use? My ultimate
goal would be to stream an arbitrarily large size (MB+) file out over
the serial port with zero down time at speeds ranging from 9600 to
480600 baud.

While using the SerialPort Control, I cannot come up with an
implimentation that doesn't A) hog the CPU at 100% and B) is able to
continually fill the TX buffer before it empties itself.

If anyone has done this, or even come close, I'd be very appreciative
of your help and suggestions. Thanks!
Click to expand...

I'm not doing large data transfer like that, but I'm managing ~8 UARTs
connected over USB with little or no CPU used at rates from 9600-115200
each. I found other problems with the BCL SerialPort class, so I wrote the
serial comm code against the Win32 API using overlapped I/O with ReadFileEx
and WriteFileEx.

Using OVERLAPPED operations, each write should complete when the data is
transferred completely into the kernel buffers (possibly into the UART FIFO)
and you can then post the next write operation. But that's complicated and
not easy to accomplish with p/invoke, I used C++/CLI to integrate .NET and
Win32.

Have you tried just dedicating a thread to a blocking write operation?
Something along the lines of always submitting a 16k chunk should work
really well, and be very CPU efficient.
 
<qoute>
Have you tried just dedicating a thread to a blocking write
operation?
</quote>

I tried a little while back, but it didn't work. After your
suggestion, I re-evaluated my approach, found I wasn't really doing
the processing in the dedicated thread. After fixing it, I think its
working and the dedicated thread did the trick! Thanks a bunch,

- Kevin
 
Back
Top