views:

989

answers:

3

Hi

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

A: 

Maybe this gives you a clue, why it is too slow: Performance Of System.IO.Ports Versus Unmanaged Serial Port Code

Oliver
OK. I just building up my SerialPort class based on that information. There isn't about how to read data from serial stream, but I found it. When I finish I'll share that knowledge. THX.
MarekK
A: 

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.

tommieb75
A: 

I have this problem. I need more speed in serialport control. MarekK you said "I found it. When I finish I'll share that knowledge". Can you Help Me sooner please???

Amir Adel
I had to go to other project. But before I tried to rebuild MS Serial class with NTE Reflector. But it is very difficult. Many properties are internal and that means it is sealed for other namespace.Second: USB Serial Port is based on internal stack. That stack is part of USB system and that means data is sending via USB in packs and stored on that stack. USB doesn't provide smooth data transfer becouse of this stack. I have found Serial ExpressCard for laptop which is fast and it's not based on USB. But other are. It is more expesive solution. I didn't buy that.
MarekK
And I don't know it works. Probably yes.Third: Some suggested me to try serial class from other companies. I didn't have time to check it, yet.Unfortunately I have too many things to do right now.
MarekK