Main Site Documentation

Buffer OVFLW on EMX


#1

Hello all, I need help to solve a problem. I am using a custom board based on EMX module that have: 4 com port (COM 1=Xbee COM2=IMU at 38400,Com 3 NMEA at 4800 Com4 Octans at 9600. When I am in debug or deployement mode, I put a jumper on the DOWN pin and Xbee is deactivated and debug statements use COM1. CDC is used for GUI on a computer.

My application locks whereas it was working properly few weeks ago. (before switching to 4.2 due to troubles with cdc ewr and so manything…)

After investigating I discovered that the IMU is causing the pb. If I disconnect it application runs fine. When I connect IMU i observe a lot of Buffer OVFLW on COM1 (even if there’s nothing on COM 2 3 and 4…

Do you have any idea?


#2

I am seeing that serialport has been modified in 4.2 QFE2.

I am polling all the com port and discard buffer after reading it in order to take profit of the time of iteration of the main loop to have a new set of data in the buffer. If COM is at 38400bauds, i have problems. I I try to set it at 9600 sometimes it works, sometimes not…


#3

without seeing the actual code you are using with the serial ports it is hard to even guess what is happening.


#4

Yes it was changed to be compatible with the big .NET (I prefer the old version!). Now, the read method returns immediately, even if you asked for 100 bytes, for example.


#5

instead of polling, you should use a read with a ReadTimeout value > 0. then the read will not return immediately. I have not tested this, but that is what the documentation says.

When handling high speed serial, it is better to use the DataReceived event and put the received data into a queue(s), and have a thread(s) that takes the data from the queue and processes it. this is the most efficient way of handling, and if you have sufficient CPU power, you will not get overruns.


#6

Mike, this is how it was before 4.2. Right now it returns even with timeout…which makes me think, what is timeout for then?!!


#7

since the 4.2 documentation includes the timeout property, if the code does not work with a timeout, then the code or documentation is wrong.

this amazing analysis is a result of too much Belgium beer and chocolate. :slight_smile:


#8

@ Mike - have fun and bring some chocolate back with you :wink:


#9

@ Mike - my daily life :stuck_out_tongue:


#10

@ David@ Emrol - I tried a non-official version of the Abby beer you mentioned a few months ago. it was very good, but my favorite is Krieck. I guess you now know how serious I am about beer.

tomorrow will be biking fron Brugge to Ghent.


#11

do you prefer dark or milk chocolate?


#12

Hey guys this is a serious topic!!!

I have already spent a lot of time to manage serialport. I have never understand the aim of read timeout. May you explain me its purpose?

The first version of this application was using thread but this was resulting in a lot of lock and unlock overhead and data received event is good for uncontinuous data but my data are coming continuously!!! That is why I am not using multi-thread anymore but a single main and a while loop that get data of each serial port and process them.

Extracting portion of code to have a relevant testcase will be a huge work (the application is the result of a year and half of work on this platform)…

Is there something I can check?

The last investigation seems to prove that connecting the IMU on com port while the application is running, does not create buffer overflow. Do you know if data are receiving on a given com port while there’s no read made by EMX can create such problem? If yes this shouldn’t be the case because it seems to stall the application.

What are your feeling?


#13

@ leforban - a single thread doing the reads and processing with high speed data, from my experiences, will result in overruns. I can’t help you.


#14

Hi Mike. Nobody is perfect :slight_smile: just kidding

To be honest I do not consider that this is high speed data (4800, 2X 9600 and 38400 is not very high!!!) and even, during last experiments the problem was there only with a single com port at 38400bps and debugger on COM0.


#15

@ leforban - with 3800 bytes/sec coming in, you have to empty the RX buffers as fast as possible. of course, we are assuming that the processing required, at that rate, can be handled by the processor chip.


#16

May we know the size of the buffer in order to compute how often I need to discard the input buffer?


#17

because I am receiving data in a continuous manner and the event will stop the application very often which will result in a big overhead (at least this was the case in 4.1).


#18

Anyway I am wondering why having a full buffer on COM2 would block the entire application… this shouldn’t be the case.


using System;
using Microsoft.SPOT;
using System.IO.Ports;
using GHI.Premium.Hardware;
using System.Threading;

namespace TESTBufferCom
{
    public class Program
    {
        public static void Main()
        {
            Debug.Print(Resources.GetString(Resources.StringResources.String1));
            SerialPort UART = new SerialPort("COM2",38400);
            int counter = 0;
            UART.Open();
            while(true)
            {
                Thread.Sleep(1000);
                Debug.Print(DateTime.Now.ToLocalTime().ToString());
            }
        }
    }
}

Here’s the output…

Hello World!
06/01/2011 00:00:11
06/01/2011 00:00:12
06/01/2011 00:00:13
06/01/2011 00:00:14
06/01/2011 00:00:15
06/01/2011 00:00:16
06/01/2011 00:00:17
06/01/2011 00:00:18
06/01/2011 00:00:19
06/01/2011 00:00:20
06/01/2011 00:00:21
06/01/2011 00:00:22
06/01/2011 00:00:23

At this point the applications stop…


#19

We will give this a try


#20

I am still investigating. Using terraterm at 38400bps on com 2 of EMX to send the log file available here: http://dl.free.fr/rItIsFkpT will result in a lock of the application. At this moment the buffer is full and contains 16384 bytes to read. This is abnormal. This shouldn’t stop the application!!!