Re: Problem to read on a serial port

From: collinm (collinm_at_laboiteaprog.com)
Date: 03/30/05 

Date: 30 Mar 2005 10:13:37 -0800

>Jens.Toerring@physik.fu-berlin.de wrote:

>
> First thing I would definitely avoid is closing the file descriptor
> for the serial port between writing and reading. The other side may
> interpret this as meaning that you aren't interested in getting a
> reply.

ok changed that, now in my function i do a write and a read...

void writereadopen(char msg[], int size)
{

    int fd1;
    int wr;
    int rd;
    fd1 = open(ledisplay, O_RDWR | O_NOCTTY | O_NDELAY );
    if (fd1 == -1)
        fprintf(stderr, " %s open_port: Unable to open %s\n",
strerror(errno), ledisplay);
    else
    {
        fcntl(fd1, F_SETFL, 0);
        wr=write(fd1, msg, size);
        if (wr < 0)
            fputs("write() of n bytes failed!\n", stderr);
        else{
            char buff[20];
            printf("write\n");
            rd=read(fd1, buff, 20);
            printf(" Bytes recieved are %d \n",rd);
        }
    }
    close(fd1);
}

i see the write message... but that seem to wait

> Then there are a lot of possible problems, which you may already have
> carefully checked, but I list them anyway, perhaps you overlooked one
> of them:
>
> 1) Why do you call fcntl() on the file descriptor? And why do you
> use FNDELAY in open()

all code i checked on the web have that, i'm a newbie with seria
programming

>while O_NONBLOCK probably would be more
> portable? Shouldn't be the fcntl() command be e.g.
>
> fcntl( fd1, F_SETFL, ( fcntl( fd1, GETFL ) & ~ O_NONBLOCK ) );
>
> if you want to switch off non-blocking mode?

i remove fcntl(fd1, F_SETFL, 0);
and i put
fcntl( fd1, F_SETFL, ( fcntl( fd1, F_GETFL ) & ~ O_NONBLOCK ) );

i see the write message... but that seem to wait

> 2) What is the value of errno after the failed write() call? It might
> give you some indication of what's going wrong.

i write on serial port without problem... i only have problem when i
read

> 3) Are you sure the serial port is correctly set up for the
communication
> with the device? There is a huge number of possible settings and
> lots of things can go wrong. Obviously, you don't set up the
serial
> port at all after you open the file. If you're very lucky the
settings
> are just what the other side expects, but you really can't rely on
that.
> Did you check the man page for tcsetattr(3)? Admittedly, it's a
lot
> to learn, but in the end you will have to anyway. Did you ever
manage
> to communicate with the device with some other program?
>

i'm able to write on the serial port... i send some command to
initialize the led display, another to send message...

i need to read on the led display because we want to know if what we
send to the led display is ok....

our solution is to send a command and after we read this command...

> One thing I don't like about the serial port settings you posted
at
> the start is that it seems to be in canonical mode.

waht i need to change to use another mode?

> While this mode
> is fine when there's a terminal or something similar at the other
end,
> it doesn't look good with a device where you seem to exchange
binary
> data. Some bytes won't make it to the other side (and back) at all
in
> canonical mode, and things are line buffered. And since you never
send
> a '\n' I wouldn't be surprised if none of the data you write ever
make
> it to the other end of the line and get stuck in the internal
buffer
> of the serial port driver (even though read() returns no failure,
but
> that's ok, since it found something that took care of the data).
>
> What's what the device expects? From a quick look at the User
Manual
> it looks as if the device has two serial ports with different
numbers
> of lines connected, so it's possible that both need different
> settings, especially for the control lines...

i need to send a special command to the led display if i want to read
something about it

with: char msg[]={'\0', '\0', '\0', '\0', '\0', '\1', 'Z', '0', '0',
'\2', 'F', '&', '\4' };

with this string, i ask to led display to send me the day of the week
...

the led display is suppose to send me something like

\0 \0 \0 \0 \0 \1 0 \3 \3 \2 E & 6 \03 00A6 \4

\0 = null
\1 = start of header character
0 = response code
\3 = sign of the actual address
\2 = start of text character
E = is the read special function
& = read day of week
6 = stands for friay
\03 = end of text character
00A6 = checksum
\4 end of transmission character

>
> Getting the communication parameters wrong is probably the most
common
> reason for failures to exchange data, so you should check them
very
> careful.
>
> 4) Did you make sure the cable is ok? I.e. all the required lines are
> there, you're not using a null-modem cable when you need a normal
> one or vice versa, have all lines low resistance?

ya, we use time since week without problem... we have a bash file who
write every x time to the led display (who use this cable)

> Sorry for asking more questions than providing answers...
>
> Regards, Jens
no problem :) , you are the expert

Relevant Pages