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…
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…
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.
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.
@ 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.
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.
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.
@ 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.
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).
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());
}
}
}
}
I am still investigating. Using terraterm at 38400bps on com 2 of EMX to send the log file available here: DL.FREE.FR 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!!!
just kidding