SerialPort Class too slow & CPU Hog?

[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

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I do not know how the SerialPort class is implemented, but why don't you try
the managed wrapper that we had to use in 1.1?

I know that it was posted time ago in MSDN magazine.

 

[Kevin]

Thanks, I'll look into that. In the mean time, I've just had some
decent luck instantiating a new 'sender' thread which manages the
filling of the buffer. I haven't scoped the line out yet, but I think
it might be good enough.

- Kevin

 

[Peter Duniho]

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.

What implementation are you using now?

I'm not that familiar with the serial port stuff, but in some respects
it's going to be similar to any of the i/o classes. And generally
speaking, it should not be hard to be CPU-efficient while still
maintaining throughput.

My first thought would be to use the async methods. Assuming the
SerialPort class has some buffering somewhere (it _ought_ to even if not
within the managed portion, given that it involves i/o, but I don't know
for sure that it does), then as long as you can respond to completed i/o
operations quickly enough, it should be fine.

If that doesn't work, my second thought would be to use the async
methods. But instead, assume that there's no buffering in SerialPort
and that you need to do it yourself. Again, I don't have any real
experience with SerialPort, but I do have experience with the networking
stuff which may be similar.

If that's the case, then you should be able to call BeginWrite() multiple
times, rather than having to wait for a previous BeginWrite() to
complete. And if that's the case, then those calls should be handled in
order, having the effect that you've provided multiple buffers to the
SerialPort class so that as it exhausts one, it still has another to read
from while it waits for your code to respond to a completion callback.

In that scenario, it's entirely possible that just two buffers would be
enough. But if not, three or four concurrently send buffers should
suffice.

That would definitely work if you were dealing with unmanaged IOCP-based
code for a serial port, and since the .NET SerialPort class ought to be
using IOCP it ought to work there too.

Pete