c# - Will SerialPort DataReceived Event trigger repeatedly?

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

Suppose I read data from SerialPort whenever there is 100 bytes available or else nothing is done. That means, the remaining data will still be available in the SerialPort Buffer. This reading is done inside the event handler of DataReceived.

Now suppose a situation arises, when there there is, say 50 bytes in the SerilaPort Buffer and no more data comes. From what I understand, the DataReceived Event will be triggered whenever there is certain amount of bytes available for reading from the Buffer.

Now, in the given scenario, if I never read those 50 bytes, will the Event get activated continuously due to the presence of these unread bytes?

i suspect that you are using .Net 2.0 SerialPort object. how did you expect DataReceived event to be triggered? By SerialPort.ReadTimeout? By SerialPort.PinChanged? – volody May 16, 2010 at 18:36 I am using .NET 3.5, but I guess the internal implementation is same as version 2.0. All I did was register a function to the DataReceived Event using the delegate SerialDataReceivedEventHandler. – Shamim Hafiz - MSFT May 16, 2010 at 19:18 No. From the documentation "The DataReceived event is raised on a secondary thread when data is received from the SerialPort object." Read this social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/… – dbasnett May 17, 2010 at 13:18

I did post the answer(see comments above). It is in the documentation. " ...when data is received from the SerialPort object." The OP said "if I never read those 50 bytes, will the Event get activated continuously due to the presence of these unread bytes?" and you replied "Yes, it will keep firing until you call Read()."

The event only fires whenever new data is received. If you do not process that piece of data, that piece of data will NOT cause a new event. However, if new data arrives, a new event will fire and you can then process it all.

"To remove all confusion, you always read the number of BytesToRead in the event, there's no point in reading less. Which means that when the event fires again, you get fresh bytes." That is your opinion. What happens if more bytes arrive while you are reading bytes in the event? Test I have done at .75 Mbps show that does occur. – dbasnett May 18, 2010 at 13:35 Ok guys, thanks for the help :) But please, let's be bit more professional. We can work towards proving our or disprove someone else's point, but starting a flame war isn't a cool thing. – Shamim Hafiz - MSFT May 19, 2010 at 8:04

Yes, it will keep firing when additional bytes come in until you call Read(). You could use the ReceivedBytesThreshold property to delay that. This is usually a bad idea, losing a byte due to an overrun error could cause communications to seize completely. Buffer what you Read() in the event handler yourself.

Also beware that this is only the known behavior of the Microsoft serial port driver. The SerialPort class uses the WaitCommEvent API function, it is up to the driver to implement this. Especially the plethora of USB drivers that emulate a serial port to make it easy to interface to a custom device are not created equal.

Ok. So to track arrival of fresh data, I must do so by other means instead of relying on the event being triggered to indicate fresh data? – Shamim Hafiz - MSFT May 16, 2010 at 19:31 Erm, no, it fires when there are new bytes available to read. Fresh ones. They only turn stale when you don't read. – Hans Passant May 16, 2010 at 19:38 But does this not contradict your earlier answer? Perhaps I am misunderstanding.. What do you imply by "turn stale"? – Shamim Hafiz - MSFT May 16, 2010 at 20:14 I don't think so. To remove all confusion, you always read the number of BytesToRead in the event, there's no point in reading less. Which means that when the event fires again, you get fresh bytes. – Hans Passant May 16, 2010 at 21:00 @dbasnett: come on man, if you know the proper answer it behooves you to post it. Your "this answer is from another high rate answer, must thus be wrong" analysis" is leaky, nowhere was it stated that the event fires when there's no data. Don't be a downvoting luzer, post. – Hans Passant May 17, 2010 at 23:47

I think this proves my point, sorry for the VB Code.

Private Sub Button1_Click(ByVal sender As System.Object, _
                          ByVal e As System.EventArgs) _
                          Handles Button1.Click
    'set up the com port for a test
    SerialPort1.PortName = "COM5" 'attached to breakout box with loopback
    SerialPort1.BaudRate = 115200 'some speed
    SerialPort1.Encoding = System.Text.Encoding.GetEncoding("windows-1252")
    Dim b() As Byte = New Byte() {42, 16, 20, 254, 255, 128} 'test data
    ctrcv = 0 'counter
    SerialPort1.Open() 'open the port
    Debug.WriteLine(DateTime.Now.ToString("HH:mm:ss.ffff")) 'show time
    SerialPort1.Write(b, 0, b.Length) 'write the test data
    'give the DataReceived event handler chances to fire
    Threading.Thread.Sleep(30000)
    'show the last time it fired and how many times
    Debug.WriteLine(lastRCV.ToString("HH:mm:ss.ffff") & " " & ctrcv)
    'show how many are available to read
    Debug.WriteLine(DateTime.Now.ToString("HH:mm:ss.ffff") & " " & SerialPort1.BytesToRead)
    Array.Clear(b, 0, b.Length)
    SerialPort1.Read(b, 0, SerialPort1.BytesToRead) 'read them
    SerialPort1.Close() 'close the port
End Sub
Dim ctrcv As Integer = 0, lastRCV As DateTime
Private Sub SerialPort1_DataReceived(ByVal sender As System.Object, _
                                     ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) _
                                     Handles SerialPort1.DataReceived
    ctrcv += 1
    lastRCV = DateTime.Now
End Sub
Debug output
 09:34:11.3241 <- when the test started
 09:34:11.3642 3 <- the last data received event!, and how many events
 09:34:41.3718 6 <- when the test ended
        Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.