Serial port becomes unreachable after being opened and closed once.

prushik · 09-22-2009, 10:22 AM

I am writing a program to read and write to devices over my serial port. My program will need to connect to up to four other machines at once. I can connect to machines successfully, it works well. However, after I connect and disconnect once, attempting to connect again will cause the FIRST serial connection will fail and all the ones after it will pass.
e.g.

Code:

fd[0]=connect("/dev/ttyS0");
fd[1]=connect("/dev/ttyS1");
fd[2]=connect("/dev/ttyS2");
fd[3]=connect("/dev/ttyS3");

//do stuff

close(fd[0]);
close(fd[1]);
close(fd[2]);
close(fd[3]);

That works as long as it is executed only once in the program. The second time it is executed, fd[0] will die and fd[1-3] will work normally.
I can't figure out why this happens, but I found a workaround by connecting to "/dev/null" before any real serial ports.
What should I do?

jiml8 · 09-22-2009, 10:42 AM

Are you sure you want to connect()? Why not just open() ?

Connect() is for sockets; open() is for files, and everything in /dev is like a file.

prushik · 09-23-2009, 12:19 AM

Quote:

Originally Posted by jiml8

Are you sure you want to connect()? Why not just open() ?

Connect() is for sockets; open() is for files, and everything in /dev is like a file.

Alright, let me clarify. Connect(char*) is one of my custom functions, it just calls open and returns a file descriptor.
Apologies for the confusion.

jiml8 · 09-23-2009, 12:22 AM

In that event, you have not provided nearly enough code to allow anyone to help you.

theNbomr · 09-23-2009, 10:17 AM

Quote:

The second time it is executed, fd[0] will die

It would be helpful to know exactly what you mean by 'die'. Are you testing the return status of all system calls, especially open()? Printing error messages/codes?
--- rod.

prushik · 09-23-2009, 11:47 PM

Quote:

Originally Posted by theNbomr

It would be helpful to know exactly what you mean by 'die'. Are you testing the return status of all system calls, especially open()? Printing error messages/codes?
--- rod.

Its just the exact same code being executed twice. All connections are closed before trying to reopen any. The first time open() is called for fd[0] it returns 4 usually. then the 2nd time it gets called it returns 0, and when open() is called again for fd[1] in the very next line, it returns 4 (usually).

smeezekitty · 09-23-2009, 11:51 PM

but 0 is a valid file handle

jiml8 · 09-24-2009, 01:01 AM

Quote:

Originally Posted by prushik

Its just the exact same code being executed twice. All connections are closed before trying to reopen any. The first time open() is called for fd[0] it returns 4 usually. then the 2nd time it gets called it returns 0, and when open() is called again for fd[1] in the very next line, it returns 4 (usually).

Without seeing your code, we have only your word that it is right...when obviously isn't right.

If you won't post it, no one can help.

theNbomr · 09-24-2009, 09:31 AM

Filehandles get re-used. Opening and closing a file/device and then re-opening the same file or device will not necessarily return the same handle. Unless the return value is negative, it is a valid file handle.
You haven't said what you mean by 'die'. Is there more to the error condition?
--- rod.

prushik · 09-25-2009, 12:22 AM

Quote:

Originally Posted by theNbomr

Filehandles get re-used. Opening and closing a file/device and then re-opening the same file or device will not necessarily return the same handle. Unless the return value is negative, it is a valid file handle.
You haven't said what you mean by 'die'. Is there more to the error condition?
--- rod.

I just meant that it won't work. I realize that it won't necessarily return the same handle, I was just giving an example. Now you are saying that a negative return value is an error condition, which is what I would assume. but if I connect to a serial port that is not in use (nothing connected) it will return 0. Now in the past when I have written to 0, it goes to standard output. So I assumed 0 was a special file descriptor that was always open and reserved for standard IO. I could of course, be totally wrong and that isn't the correct way to write to standard output. Anyway, so anyway, with that in mind I may have figured this whole thing out, heres my theory, tell me if it makes sense:

If only ports 1 and 2 are in use
Theory (in c-like pseudo-code):

Code:

fd[0] = open("/dev/ttyS0")  //will return 4 since it is the 1st available
fd[1] = open("/dev/ttyS1")  //returns 5 since thats the next available
fd[2] = open("/dev/ttyS2")  //returns 0 since nothing is connected
fd[3] = open("/dev/ttyS3")  //also returns 0

//-----IO operations here-------

close(fd[0])  //closes descriptor 4 making it available again
close(fd[1])  //closes descriptor 5 making it available again
close(fd[2])  //closes descriptor 0 making it available again!!!!
close(fd[3])  //probably fails because its already closed. I should check

//Now the next time open is called, the first available file descriptor will be 0 since I closed it.

That makes sense to me and would explain my problem perfectly. If there is any reason this can't be, please tell me.

prushik · 09-25-2009, 09:17 AM

I added some code to check each fd before closing it. If it is equal to zero it will not get closed. Now the whole thing works as I would expect it to.

If someone can confirm this or if no one can explain otherwise, then this thread is solved.