Serial communication problem

zdenekkrejci · 07-18-2010, 11:00 AM

Hi I have a problem with serial communication... I already created a few small programs but now I have got an error that Im not able to fix. I have two simple programs, one is sending a chars 'a\r' and the other program should read these chars. To show you exactly, this is the case..

The sending program:

Code:

int write_port() {
	int error = 0;
		
	int n = write(pd.file_ID, "a\r", 2);
	error = errno;
	
	printf("ERROR: %i\n",error);


return 1;

}

now the reading program:

Code:

int read_char(){
	char * result;
	int iIn =0;
	int count = 0;
	int error = 0;
while (1)
{

   iIn = read(pd.file_ID,result,2);

   error = errno;
     	printf("ERROR: %s\n",strerror(error));
   printf("Characters read: %d\n",iIn);
   count++;
   printf("Pass:%d\n",count);

   printf ("Answer: %s\n\n",result);

}

return 1;

Looks verry simple but as it is it should send two chars and finish as there is no while and the reading is in while but in blocking mode so it should read two chars and wait again... but this is the problem it does not stop.. it just keep going and reading one char... now just make it clear the port is on loopback... and when I break the loop it stoped so it looks like the first sending program is just somehow making the serial port keep sending one char.... please help me guys Im out of ideas....

Ye and this is my settings

Code:

int init_port() {

        struct termios options;
        // Get the current options for the port...
        tcgetattr(pd.file_ID, &options);

        cfsetispeed(&options, B57600);
        cfsetospeed(&options, B57600);
        // Enable the receiver and set local mode...
        options.c_cflag |= CLOCAL;//(CLOCAL | CREAD);

        options.c_cflag &= ~PARENB;
        options.c_cflag &= ~CSTOPB;
        options.c_cflag &= ~CSIZE;
        options.c_cflag |= CS8;
        options.c_cflag &= ~CRTSCTS;

        options.c_oflag = 0;
        options.c_lflag = 0;
        options.c_cc[VTIME] = 0;
        options.c_cc[VMIN] = 1;
        
        // Set the new options for the port...
        tcsetattr(pd.file_ID, TCSANOW, &options);
        tcflush(pd.file_ID,TCIOFLUSH);
        return 1;
}

and openning is done by

Code:

pd.file_ID=open("/dev/ttyS0", O_RDWR | O_NOCTTY);

Thanks

harry edwards · 07-18-2010, 02:40 PM

Are both opening the port with O_RDONLY? If so, that cannot be right.

Also, print the int values returned by write and read. These should equal 2.

theNbomr · 07-18-2010, 02:46 PM

My guess is that you will find the problem by using the return values of all of the system calls you make. In a cursory scan of your source code (would have been easier if it had been posted in [CODE][ /CODE ] tags), I don't see a single case where you actually use the return code.

--- rod.

zdenekkrejci · 07-18-2010, 06:19 PM

To Harry Edwards Im sorry as I was trying modify the code I posted the old code for opening the port, so it is now
pd.file_ID=open("/dev/ttyS0", O_RDWR | O_NOCTTY );
and I was trying also nonblock while opening but I get the same...
And to theNbomr: Im not sure if I understand your posting, but if I do than what returning code do you mean? If the returning value, than im just using it for now to scan how many char I read.
Also guys if you want I will send you all the source code or the compiled program just to see or try it your self it requires only to connect TX and RX by loop on your RS232 connector...

zdenekkrejci · 07-18-2010, 06:22 PM

Ye tags ok will do... I hope we get the any solution because I really need this one to work :-(

theNbomr · 07-18-2010, 11:54 PM

Code:

int n = write(pd.file_ID, "a\r", 2);

What is the return value from write()? You assign it to a variable, and then do nothing with it. Same for the file open(). read() will not append a null to any data, so you cannot rely on one being there if you use the data as a string, like you're doing:

Code:

   printf ("Answer: %s\n\n",result);

--- rod.

zdenekkrejci · 07-19-2010, 03:07 AM

Hi as far as I know the returning values of these functions are just status, how many char was read or available. So Im for sure planing to use them later. Now I would like to make these functions work properly. So they should have blocking behavior.

Im sorry but just dont fully know what you mean by:

Quote:

read() will not append a null to any data, so you cannot rely on one being there if you use the data as a string, like you're doing:

So do you mean, that reading the pointer result will affect the blocking manner of the read() function???

theNbomr · 07-19-2010, 09:05 AM

Quote:

as far as I know the returning values of these functions are just status

Yes, like 'some error happened' or 'end-of-file'. I suggest you read the man pages for your system calls.

The 'result' string you are printing is not guaranteed to be a null-terminated string, as handled by the read() function, and yet you are assuming that it will be so, by using it with the "%s" format in printf(). read() doesn't know anything about the data; how would it know to format it aas a string? Once again, I suggest

Code:

man 2 read
man 3 printf

--- rod.

zdenekkrejci · 07-19-2010, 12:03 PM

I thing I know what you say now but lets thing about it this way. The function red() should be blocking, will it than make any different if the string "the data" in variable result is terminated properly or not?? You know what I mean? Or else to say I thing "I could be wrong" that it does not matter whether the data are terminated properly or not or whether Im reading the return value or not... The function read should still just block if there is no char available. On other hand, my reading program, could now be working correctly and the reason way its not blocking and keep reading one char, is that the writing program, is somehow making the serial driver to keep sending a char. Because when I disconnect the loopback it stopped. I did now try GTK-TERM to send a char and seems to be working just the way I want. But after I checked the GTK-TERM source code, I havent find any answer I fact that the GTK-TERMs code for writing and reading looks very the same... So I guess that the faulty part is on the sending program... Now, tell me, could the string sent in function write() cause this when its not terminated properly ??
I have found another thing that if I send by write() "a" the reading site is still blocking means no printf is done.
But when I send "a\r" the reading site starts reading and just reading and reading but it should not continue reading anymore....

harry edwards · 07-19-2010, 02:12 PM

Try NULL terminating before the printf after the read e.g.

Code:

iIn = read(pd.file_ID,result,2);
result[iIn] = 0;

zdenekkrejci · 07-19-2010, 05:32 PM

Add NULL at the end of the string going to be print by printf? But why do you want me to try it as Im not having problem with the printing the strings or printf() it self but with the read() function. So it is still reading when the sending is already stopped. But as I was writing before, I found that when I broke the loop-back on my rs232 than it stops the reading. So it must be in writing function and so Im now asking why is that.

zdenekkrejci · 07-20-2010, 03:25 PM

Ok guys I have it sorted it was in settings... but now I have another problem straight way :-) Im sending a string to GTK TERM and its reading only 16 characters of my 25 char long string... Any idea?

Wim Sturkenboom · 07-21-2010, 01:40 AM

What is gtk term ?

Anyway, if your read is still like below, you will have a problem.

Code:

int read_char(){
	char * result;
...
...
while (1)
{

   iIn = read(pd.file_ID,result,2);

result is a pointer pointing somewhere; very dangerous

It should point to a defined buffer.

And you're only reading 2 characters? Do you have an updated version of your source code?

PS How do you compile?