PLEX86  x86- Virtual Machine (VM) Program
 Plex86  |  CVS  |  Mailing List  |  Download  |  Linux  |  Newsgroups

Why is the serial port sooo slow in Linux


Your Ad Here

Your Ad Here

This is meant to be a more general question rather than a code-specific question, although I have attached some of my code at the end. I have a device that I made that communicates over the serial port with a PC. The communication is based on single-byte transfers, i.e. the PC sends a single byte to the device, and the device answers back with a single byte. For many years I used a program that was written for DOS to accomplish this communication strategy. Recently I attempted to implement a similar program in Linux, using gcc 3.2.1 and kernel 2.4.20. To my surprise, the Linux program is about 50 times slower than the DOS program! At first I thought that serial interrupts were not set up correctly, however I examined theproc directory and verified that serial interrupts are indeed occuring.

I did a search in Google Groups and found some discussion saying that the Linux serial driver does not respond until a certain number of bytes is received, otherwise it basically times out waiting for its quota of bytes. If this is the case it is really bad news for my scheme based on single byte exchanges. Does anyone know if this is in fact the case for the Linux serial driver? Is there any way around this problem, or perhaps has it been addressed in later kernels?

Thanks very much for any help.

Here is the code that I used to set up the serial port:

* ----------------------------------------------------------------------- *

int setupserialport(int icom, long int baud) {

int fd; struct termios options;

* * Open serial port *

if(icom==1) { fd = open("-dev-ttyS0", ORDWR ONOCTTY ONDELAY); } else { fd = open("-dev-ttyS1", ORDWR ONOCTTY ONDELAY); }; if (fd == -1) { * * Could not open the port. * perror("openport: Unable to open serial port "); return fd; } else fcntl(fd, FSETFL, 0);

Kernel panic: No init found 1726
On Wednesday 28 June 2006 01:44, Sam stood up and spoke the following words to the mbuttes incomp.os.linux.misc...: I beg to differ... Then perhaps...

* to make the read function return immediately (non-blocking mode): * fcntl(fd, FSETFL, FNDELAY);

* * Get the current options for the port... *

tcgetattr(fd, &options);

* * Set the baud rate... *

switch (baud) { case 0:* note: case 0 disconnects the line * cfsetispeed(&options, B0); cfsetospeed(&options, B0); break; case 50: cfsetispeed(&options, B50); cfsetospeed(&options, B50); break; case 75: cfsetispeed(&options, B75); cfsetospeed(&options, B75); break; case 110: cfsetispeed(&options, B110); cfsetospeed(&options, B110); break; case 134: cfsetispeed(&options, B134); cfsetospeed(&options, B134); break; case 150: cfsetispeed(&options, B150); cfsetospeed(&options, B150); break; case 200: cfsetispeed(&options, B200); cfsetospeed(&options, B200); break; case 300: cfsetispeed(&options, B300); cfsetospeed(&options, B300); break; case 600: cfsetispeed(&options, B600); cfsetospeed(&options, B600); break; case 1200: cfsetispeed(&options, B1200); cfsetospeed(&options, B1200); break; case 1800: cfsetispeed(&options, B1800); cfsetospeed(&options, B1800); break; case 2400: cfsetispeed(&options, B2400); cfsetospeed(&options, B2400); break; case 4800: cfsetispeed(&options, B4800); cfsetospeed(&options, B4800); break; case 9600: cfsetispeed(&options, B9600); cfsetospeed(&options, B9600); break; case 19200: cfsetispeed(&options, B19200); cfsetospeed(&options, B19200); break; case 38400: cfsetispeed(&options, B38400); cfsetospeed(&options, B38400); break; case 57600: cfsetispeed(&options, B57600); cfsetospeed(&options, B57600); break; case 115200: cfsetispeed(&options, B115200); cfsetospeed(&options, B115200); break; case 230400: cfsetispeed(&options, B230400); cfsetospeed(&options, B230400); break; default: printf("Error in baud rate specification-n"); return -1; }

* * Enable the receiver and set local mode... *

options.ccflag = (CLOCAL CREAD);

* no parity (8N1): * options.ccflag &= ~PARENB; options.ccflag &= ~CSTOPB; options.ccflag &= ~CSIZE; options.ccflag = CS8;

Kernel panic: No init found 1730
On Thursday 29 June 2006 23:48, Sam stood up and spoke the following words to...
Kernel panic: No init found 1731
On Friday 30 June 2006 03:40, Sam stood up and spoke the following words to the mbuttes incomp.os.linux.misc...: With a response like that, I rest my case. So I've noticed, yes. Actually, it is your...

* disable hardware flow control: * options.ccflag &= ~CRTSCTS;

* setup raw input: * options.clflag &= ~(ICANON ECHO ECHOE ISIG);

* select raw output: * options.coflag &= ~OPOST;

* disable software flow control * options.ciflag &= ~(IXON IXOFF IXANY);

* * Set the new options for the port... *

tcsetattr(fd, TCSANOW, &options);

* serial port is now configured *

Kernel panic: No init found 1729
the following words to the mbuttes incomp.os.linux.misc...: I can butture you that this is how Mandrake used to work, and Mandriva probably still works...

return fd;

};* ---------------------------------------------------------------- *



Your Ad Here

List | Previous | Next

Kernel panic: No init found 1726

Linux groups from Newsgroups

The #1 Usenet Provider on the Internet

burn multi cd from read only files server and limited HD space