I'm working with a Cavro robot that accepts command strings, returns an
acknowledgment upon receipt of a valid command, executes the command and
then sends a completion message. The completion message is sent over
and over until the host computer returns an acknowledgment. The format
of a normal acknowledgment is
char[0] = /002 (ctrl B)
char[1] = 40h (@)
char[2] = 31h (1)
char[3] = 38h (8)
char[4] = /003 (ctrl C)
char[5] = 48h (H) ---- this char is a checksum computed from the
message
The completion message is similar except the second char is a 'Q' on the
first completion message and changes on subsequent messages.
I've tried to keep the communications simple. I read and write to the
port using the following code.
int CSerial::SendData( const char *buffer, int size )
{
if( !m_bOpened || m_fd<0 ) return( 0 );
int BytesWritten = write(m_fd,buffer,size);
// fflush((FILE *)m_fd);
// tcflush(m_fd, TCOFLUSH); //flush output buffer of bytes written
but not sent
// the previous two lines were tried in failed attempts to address
question 2 below
return( BytesWritten );
}
int CSerial::ReadData( char *buffer, int limit )
{
if( !m_bOpened || m_fd<0 ) return( 0 );
int BytesRead = read(m_fd,buffer,limit);
return( BytesRead );
}
With that as background, I have a couple of problems and questions.
1) I intermittantly "receive" extra charactors. The extra char is
always zero and always appears immediately after the ctrl B. The rest
of the expected message is still there, just shifted by one. Initially,
I thought this behaivior was limited to a specific serial board I was
using. I switched to the motherboard port (on my etower 366i) and the
problem didn't crop up for several months. Now it is back with a
vengence. I have an external line monitor between the host and robot
and thus know the extra char is not being transmitted by the robot. Has
anyone seen something like this? BTW, since my host doesn't recognize
the acknowledgement with the extra zero, the robot continues to spew
completion messages. When I examine these I find some (but not all) of
them have zeros in the second position also.
2) There is a variable delay between the time I execute SendData() and
the time the command is transmitted. Sometimes this can be as long as a
couple of seconds, other times, very quick. SendData returns
immediately either way, so sometimes my code gets in trouble because
it's looking for an acknowledgement to a command that hasn't been sent
yet. Is there some way I can control (or at least monitor) this delay?
Thanks,
Tom
ps. The code I use to open the port is:
int CSerial::Open( int nPort) //, int nBaud )
{
if( m_bOpened ) return( TRUE );
switch (nPort)
{
case 1:
m_fd = open(SERIALDEVICE0, O_RDWR | O_NOCTTY);
break;
case 2:
m_fd = open(SERIALDEVICE1, O_RDWR | O_NOCTTY);
break;
case 3:
m_fd = open(SERIALDEVICE2, O_RDWR | O_NOCTTY);
//TODO change to serialdevice2
break;
default:
return 0;
}
tcgetattr(m_fd,&oldtio); /* save current port settings */
bzero(&newtio, sizeof(newtio));
newtio.c_cflag = BAUDRATE1 | CRTSCTS | CS8 | CLOCAL | CREAD;
newtio.c_iflag = IGNPAR;
newtio.c_oflag = 0;
/* set input mode (non-canonical, no echo,...) */
newtio.c_lflag = 0;
newtio.c_cc[VTIME] = 0; /* inter-character timer unused */
newtio.c_cc[VMIN] = 6; /* blocking read until 6 chars received */
// newtio.c_cc[VMIN] = 0;
tcflush(m_fd, TCIFLUSH);
tcsetattr(m_fd,TCSANOW,&newtio);
m_bOpened = TRUE;
return( m_bOpened );
}
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
