Mailinglist Archive: opensuse-programming (61 mails)

[Jerry Feldman <gaf@xxxxxxx>]

On Friday 02 September 2005 4:05 pm, Pierre Patino wrote:
> Francois Maletras wrote:
> >>>The c code is a simple user program with canonical reads in
> >>
> >>a for loop.
> >>
> >>>Looking at console tty10 during an upload from device to
> >>
> >>computer, you
> >>
> >>>get ttyS0: 1 input overrun(s)
> >>>ttyS0: 2 input overrun(s)
> >>>ttyS0: 1 input overrun(s)
> >>>
> >>>In average, you get  3~4 overruns per upload, but it can
> >>
> >>drop to 1 or 0.
> >>One of the things you really need to do is to get a serial
> >>port analyzer. I
> >>have not used one in years, but the ones we used were
> >>breakout boxes. Not
> >>only do these have the capability to change pins, bit they
> >>also have leds.
> >>You really want to see if the hardware flow control is
> >>actually working or
> >>not.
> >>I have not done any serial port programming in a number of
> >>years, but you
> >>can really pull your hair out trying to debug this stuff.
> >
> >It is also very time consuming to sort out, especially with intermitent
> > problems .
> >
> >I have actually stumbled accross a solution by using a USB to serial
> > converter instead of the onboard 16550A UART. See
> >http://www.ftdichip.com/Products/FTEvaluationKits.htm
> >The UART in the converter has 384 bytes of Rx buffer,
> >a far cry from the mere 16 bytes of the 16550A.
> >Now works very reliably at 115200 bauds!
>
> The geek in me just loves these kind of problems.  If you wrote
> something like
>
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <stdio.h>
>
> char buf;
> int f ;
> int n;
>
> int main(int nn,char **a) {
>
> f = open("/dev/ttyS0",O_RDONLY);
>
> while(1) {
>
> n= read(f,&buf,1);
> if (n==0)
>   break;
> if (n <0)
>   perror("Merde: ");
> }
>
>  printf("read returned EOF\n");
> fflush(stdout);
>  return 0;
> }
>
>
> What would you get?  Just wondering if the problem is at the tty driver
> (which probably hasn't changed in eons) , whatever mass-storage device
> driver that you're dumping data to or something else in the kernel.
> While the program is running, take a peek at /proc/interrupts too.
Merde!, you are not setting hardware flow control as I see it.
I'm about to leave work for the weekend, but you should use termios to make 
sure that you set the serial port to use flow control. 
If your program uses hardware flow control and the device uses hardware flow 
control, you should not have any buffer overrun problems.

-- 
Jerry Feldman <gaf@xxxxxxx>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9