C＃：读取串口 - BytesToRead

Question

I am modifying a C# based UI that interfaces to a small PIC microcontroller tester device.

The UI consists of a couple buttons that initiates a test by sending a "command" to the microcontroller via a serial port connection. Every 250 milliseconds, the UI polls the serial interface looking for a brief message comprised of test results from the PIC. The message is displayed in a text box.

The code I inherited is as follows:

try
{
    btr = serialPort1.BytesToRead;
    if (btr > 0)
        Thread.Sleep(300);
    btr = serialPort1.BytesToRead;
    if (btr > 0)
    {
        Thread.Sleep(300);
        btr = serialPort1.BytesToRead;

        numbytes = serialPort1.Read(stuffchar, 0, btr);
        for (x = 0; x < (numbytes); x++)
        {
            cc = (stuffchar[x]);
            stuff += Convert.ToString(Convert.ToChar((stuffchar[x])));
        }

What would be the rationale for the first several lines consisting of three calls to BytesToRead and two 300 millisecond sleep calls before finally reading the serial port? Unless I am interpreting the code incorrectly, any successful read from the serial port will take more than 600 milliseconds, which seems peculiar to me.

Answer 1

It is a dreadful hack around the behavior of SerialPort.Read(). Which returns only the number of bytes actually received. Usually just 1 or 2, serial ports are slow and modern PCs are very fast. So by calling Thread.Sleep(), the code is delaying the UI thread long enough to get the Read() call to return more bytes. Hopefully all of them, whatever the protocol looks like. Usually works, not always. And in the posted code it didn't work and the programmer just arbitrarily delayed twice as long. Ugh.

The great misery of course is that the UI thread is pretty catatonic when it is forced to sleep. Pretty noticeable, it gets very slow to paint and to respond to user input.

This needs to be repaired by first paying attention to the protocol. The PIC needs to either send a fixed number of bytes in its response, so you can simply count them off, or give the PC a way to detect that the full response is received. Usually done by sending a unique byte as the last byte of a response (SerialPort.NewLine) or by including the length of the response as a byte value at the start of the message. Specific advice is hard to give, you didn't describe the protocol at all.

You can keep the hacky code and move it into a worker thread so it won't affect the UI so badly. You get one for free from the SerialPort.DataReceived event. But that tend to produce two problems instead of solving the core issue.

Answer 2

If that code initially was in a loop it might have been a way to wait for the PIC to collect data.

If you have real hardware to test on I would sugest you remove both Sleeps.

Answer 3

@TomWr you are right, from what I'm reading this is the case.
Your snippet below with my comments:

try
{
    // Let's check how many bytes are available on the Serial Port
    btr = serialPort1.BytesToRead;

    // Something? Alright then, let's wait 300 ms.
    if (btr > 0)
        Thread.Sleep(300);

    // Let's check again that there are some bytes available the Serial Port
    btr = serialPort1.BytesToRead;

    // ... and if so wait (maybe again) for 300 ms 
    // Please note that, at that point can be all cumulated about 600ms 
    // (if we actually already waited previously)
    if (btr > 0)
    {
        Thread.Sleep(300);
        btr = serialPort1.BytesToRead;

        numbytes = serialPort1.Read(stuffchar, 0, btr);
        for (x = 0; x < (numbytes); x++)
        {
            // Seems like a useless overhead could directly use
            // an Encoding and ReadExisting method() of the SerialPort.
            cc = (stuffchar[x]);
            stuff += Convert.ToString(Convert.ToChar((stuffchar[x])));
        }

My guess is the same it as been already mentioned above by idstam, basically probably to check whether is data sent by your device and fetch them

You can easily refactor this code with the appropriate SerialPort methods cause there are actually much better and concise ways to do check whether there are data available or not on the Serial Port.

Instead of "I'm checking how many bytes are on the port, if there is something then I wait 300 ms and later same thing again." that is miserably ending up with
"So yep 2 times 300 ms = 600ms, or just once (depending on whether there was a first time", or maybe nothing at all (depending on the device you are communicating to through this UI which can be really slacky since the Thread.Sleep is blocking the UI...). "

First let's considering for a while that you are trying to keep as much of the same codebase, why not just wait for 600ms?

Or why not just using the ReadTimeout property and catching the timeout exception, not that clean but at least better in terms of readability and plus you are getting your String directly instead of using some Convert.ToChar() calls...

I sense that the code has been ported from C or C++ (or at least the rationale behind) from someone who rather has mostly an embedded software background.

Anyway, back to the number of available bytes checks, I mean unless the Serial Port data are flushed in another Thread / BackgroundWorker / Task handler, I don't see any reason of checking it twice especially in the way it is coded.
To make it faster? Not really, cause there is an additional delay if there are actually data on the Serial Port. It does not make that much sense to me.

Another way to make your snippet slightly better is to poll using the ReadExisting().

Otherwise you can also consider asynchronous methods using the SerialPort BaseStream.

All in all it's pretty hard to say without access the rest of your codebase, aka, the context.

If you had more information about what are the objectives / protocol it could give some hints about what to do. Otherwise, I just can say this seems to be poorly coded, once again, out of context.

I double and even triple back what Hans mentioned about the UI responsiveness in the sense that really I hope your snippet is running in a thread which is not the UI one (although you mentioned in your post that the UI is polling I still hope the snippet is for another worker).

If that's really the UI thread then it will be blocked every time there is a Thread.Sleep call which makes the UI not really responsive to the user interactions and may give some feeling of frustration to your end-user.

Might also worth to subscribe to the DataReceived event and perform what you want/need with the handler (eg using a buffer and comparing value, etc.).

Please note that mono is still not implementing the trigger of this event but if you are running against a plain MS .NET implementation this is perfectly fine without the hassles of the multi-threading.

In short:

• Check which thread(s) is(are) taking care of your snippet and mind about the UI responsiveness
  • If it is the UI, then use another thread through Thread, BackgroundWorker (Threadpool) or Task.
  • Stream Asynchronous Methods in order to avoid the hassles of the of UI thread synchronization
• Try to see whether the objectives really deserve a double 300 ms Thread Sleep method call
• You can directly fetch the String instead of gathering if latter checks are using so to perform operations rather than gathering the Bytes by yourself (if the chosen encoding can fulfill your needs).