Slooowww serial with Gadgeteer drivers?

I have a PC application which is sending about 50 bytes via a serial connection (FTDI chip) to a Spider2 board on COM2 (socket #4). I have it configured for a baud rate of 19200.

usbSerial.Configure(19200, SerialParity.None, SerialStopBits.One, 8, HardwareFlowControl.NotRequired);
usbSerial.Port.NewLine = "\r\n";
usbSerial.Port.LineReceived += Port_LineReceived;

The data being sent is delimited with a CRLF ("\r\n") so I’m using the Port.NewLine event. In the 50 or so bytes that are sent there are three such delimited strings so I will get three NewLine events. The application sending this data could do so at 50ms intervals but I have to slow it down to about 750ms intervals to keep from overwhelming the Spider (buffer overflow). It appears that the rate at which the NewLine event is generated is painfully slow. Is this a result of the Gadgeteer drivers? I’m wondering if I would be better off using plain NETMF? (In one test I was sending data from the PC application only if it changed at the 50ms rate. I would see the RED transmit LED on the FTDI board go out and it might take several seconds for the Spider to chew through the buffer.)

The event handler on the Spider2 is:

        private void Port_LineReceived(Serial sender, string line)
            if (line.IndexOf("XDRO=") == 0)
                xPos = line.Substring(5);
            else if (line.IndexOf("YDRO=") == 0)
                yPos = line.Substring(5);
            else if (line.IndexOf("ZDRO=") == 0)
                zPos = line.Substring(5);

LineReceived isn’t a native netmf call, and has an overhead. From history of seeing this kind of issue, everyone implements their own scan to improve response.

Create a thread to handle the received data. I’ve never had success with the linereceived event.

Thinking about this some more I don’t think this is due to any overhead in the Gadgeeter code, if you listen for received events and parse the stream yourself you are doing the same task in the same managed code. It is probably something closer to the LineRecived code/event have very low priority. So I guess todays task is to fire up a separate thread to listen to the received event or just read bytes, sleep, read bytes, etc.

OK, you know what they say about assumptions don’t you? I implemented a reader on a separate thread and was still overflowing the serial buffer on the Spider2. So then I actually measured the loop time of the Mach 4 ‘Sim’ plug-in and found it was 2ms! So, 500loops/sec*50 bytes/loop = 25K bytes/second! :-[

So, a reader on its own thread might be better but…you still need to know (not assume) how much data you are sending. The LineRecieved method was coping with about 1.6K bytes/second (I was sending every 16th loop). Using a reader on its own thread I can send every 6th loop without overflowing the serial buffer on the Spider2.

[ol]Don’t assume things
Using a separate read thread does increase performance.[/ol]