C# serialPort speed

Question

I am developing some monitoring tool for some kind of protocol based on serial communication.

Serial BaudRate=187,5kb I use System.IO.Ports.SerialPort class.

This protocol has 4 kinds of frames. They have 1Byte,3Bytes,6Bytes, 10-255Bytes. I can work with them but I receive them too late to respond.

For the beginning I receive first packed after ex. 96ms (too late), and it contains about 1000B. This means 20-50 frames (too much, too late). Later its work more stable, 3-10Bytes but it is still too late because it contains 1-2 frames. Of Course 1 frame is OK, but 2 is too late.

Can you point me how can I deal with it more reliable? I know it is possible.

Revision1:

I tried straight way:

private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
       if (!serialPort1.IsOpen) return;
       this.BeginInvoke(new EventHandler(this.DataReceived));
}

And Backgroud worker: And ... new Tread(Read) and... always the same. Too late, too slow. Do I have to go back to WinApi and import some kernel32.dll functions?

Revision 2: this is the part of code use in the Treading way:

int c = serialPort1.BytesToRead;
byte[] b = new byte[c];
serialPort1.Read(b, 0, c);

I guess it is some problem with stream use inside SerialPort class. Or some synchronization problem.

Revision 3: I do not use both at once!! I just tried different ways.

Regards MarekK

Answer 1

Maybe you should read this first, as this bug has to do with DataReceived Event which does not fire at times, and it is still not fixed in Framework 3.0/3.5. Also, you should read something here about this poster who reported the problem to Microsoft when he had issues using it, under VS2008/NET 3.5...I cannot say if that is true or not...but is something worth keeping in mind about...and Microsoft did have a certain amount of difficulty with the .NET version which was introduced into .NET version 2.

At the time, I was using .NET 1.1, I came across suggestions to use the version that came with VB6's ActiveX control, which according to sources on the internet, that it was the best serial comms control!!!

You might be better to investigate using a third party code to handle the serial communications, usually, the ones written outside of the managed world, i.e. unmanaged using lots of p/invokes.

I have tried using John Hind's version found in the MSDN article here, which I did find very off-putting as there was no way to do it asynchronously, plus it was a horrible coding experience..

I did end up using one supplied by Franson which produced better results than Hind's code.

Hope this helps, Best regards, Tom.