RE: [suse-programming-e] serial port overrun
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! ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------
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.
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@blu.org> 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
Jerry Feldman wrote:
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.
Isn't hardware flow control on by default? Anyway, this explicitly does it. #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <asm/termbits.h> #include <stdio.h> char buf; int f ; struct termios opts; int n; int main(int nn,char **a) { f = open("/dev/ttyS0",O_RDONLY); ioctl(f, TCGETS, &opts); opts.c_iflag &= ~(IXON | IXOFF | IXANY); ioctl(f, TCSETS, &opts); 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; } I'd like to know if this code generates buffer overruns as it reads hundreds of kB at 115200 baud.
participants (3)
-
Francois Maletras -
Jerry Feldman -
Pierre Patino