title: serial communication anomaly in Linux?
body: <p>I am using select call to communicate with an external subsystem (protocol for the same has been provided and implemented as a Qt thread) using serial port RS232. We do not have the hardware for the external systems and thus we have developed in house simulators using .Net 2.0 and C# to mimic the behavior of the underlying subsystem hardware. There are 5 different subsystem that communicate with our application. Every interface for the subsystem is implemented as a Qt thread. Since this isn't a real time application, and we do not have the actual hardware when we communicate using simulators, all systems do find for 24 hrs or so and after that the communication goes up and down and ultimately all communication breaks down, but when I restart the simulator machine without closing my application, things become alright. Why does this happen?</p>
  
  <p>My guess is, since .Net/C# isn't a real time framework and also after the simulators have run for 24 hrs, the data sending rates start to slow down, that there is clogging of serial ports; the restart flushes everything and thus everything returns to normal. This is just a guess. If someone has a better opinion, do share it. Note, the simulators have been made by a different team of .Net guys.</p>
  
  <p>Note: Each protocol has different data rates, 1 Hz, 5 Hz, 10 Hz. </p>
  
  <p>There is one system which just doesn't resume communication even after simulator for the same is restarted after reboot. The port configuration for this system is</p>
  
  <pre><code>SetPortConfiguration()
  {
      tcgetattr(Fd,&amp;mOldtio); 
         mNewtio.c_cflag = B4800 | CS8 | CLOCAL | CREAD | CRTSCTS;
         mNewtio.c_iflag = 0; //setting the input flag to icrnl causes a blank frame to be displayed after every frame.
         mNewtio.c_oflag = 0;
         mNewtio.c_lflag =ICANON;
         mNewtio.c_cflag &amp;=~PARENB;
         mNewtio.c_cflag &amp;= ~CSTOPB;
          //mNewtio.c_cflag &amp;= ~HUPCL;  //added on 24/3/09
         mNewtio.c_cc[VEOL]=0; //setting VEOL to '\r' or '\n' causes a blank frame to be displayed after every frame.
         mNewtio.c_cc[VKILL] = 0;     /* @ */
         mNewtio.c_cc[VSTART] = 0;     /* Ctrl-q */
         mNewtio.c_cc[VSTOP]  = 0;     /* Ctrl-s */
         mNewtio.c_cc[VMIN]=0;
         mNewtio.c_cc[VTIME]=0;
         tcflush(Fd, TCIFLUSH);
         tcflow(Fd,TCION);
         tcsetattr(Fd,TCSANOW,&amp;mNewtio);
  }
  </code></pre>
  
  <p>Also there is a reset port function :</p>
  
  <pre><code>ResetPort()
  {
      tcflush(Fd, TCIFLUSH); //flush all data received but not read
  
      tcflow(Fd,TCIOFF); //transmits a STOP character, which stops the terminal device from transmitting data to the system 
      tcsetattr(Fd, TCSANOW, &amp;mOldtio);//set the old terminal settings
  
      ClosePort(); //close port
      OpenPort(mStrPortNo); //open the port specified by port number and in read mode
      SetPortConfiguration();
  }
  </code></pre>
  
  <p>If there is any break in communication, I call the ResetPort function which closes and reopens the port. This solves the problem in all cases except one system say XYZ.
  XYZ system sends data in NMEA format with each packet as a string of data terminated with a Carriage Return, LineFeed combination. </p>
  
  <p>Any idea fellows as to what may be the problem?</p>