Has anyone had any problems with this driver locking up.
We have an application using read() & write() with /dev/ser1
The port is receiving data from an RS485 multi-drop bus.
Looking at a comms analyser, it appears that if there is corrupt data on the
bus (framing errors) then sometimes the read() will just read the corrupted
data and other times the read() will remain blocked because the data is not
being provided by ser-8250.
Under this condition we can transmit data but received data (seen as good on
the analyser) does not get picked up when we read() from the fd connected to
/dev/ser1
What does devc-ser8250 do under line errors, eg: parity, framing etc?
Ian Gibb
On Fri, 31 Jan 2003 14:24:38 -0000, “Ian Gibb” <iang@maconmgt.co.uk> wrote:
Has anyone had any problems with this driver locking up.
We have an application using read() & write() with /dev/ser1
The port is receiving data from an RS485 multi-drop bus.
Looking at a comms analyser, it appears that if there is corrupt data on the
bus (framing errors) then sometimes the read() will just read the corrupted
data and other times the read() will remain blocked because the data is not
being provided by ser-8250.
Under this condition we can transmit data but received data (seen as good on
the analyser) does not get picked up when we read() from the fd connected to
/dev/ser1
You will have to give more detail, as read’s behaviour can be influenced
when there is no (or not enough) data available when read is called…
What does devc-ser8250 do under line errors, eg: parity, framing etc?
Not sure about that one, but the source is available, at least
with Professional Edition…
BTW how are you doing the multi drop control?
Is your hw doing it, or is it a software function?
“Ian Gibb” <iang@maconmgt.co.uk>…
Has anyone had any problems with this driver locking up.
We have an application using read() & write() with /dev/ser1
The port is receiving data from an RS485 multi-drop bus.
Looking at a comms analyser, it appears that if there is corrupt data on
the
bus (framing errors) then sometimes the read() will just read the
corrupted
data and other times the read() will remain blocked because the data is
not
being provided by ser-8250.
Under this condition we can transmit data but received data (seen as good
on
the analyser) does not get picked up when we read() from the fd connected
to
/dev/ser1
What does devc-ser8250 do under line errors, eg: parity, framing etc?
As i remember any erroneous bytes go to so-called ‘out of band data’,
so read() doesn’t return sometimes (if there’s no “good” data)
I used readcond() and then check out-of-band data,
like this:
int GetOB(void)
{
char data = 0;
int res=0;
if ( res=devctl (Ser_Fd, DCMD_CHR_GETOBAND, &data , sizeof(data),
NULL ) )
{ if (res != EAGAIN)
{
LogTransportError(“GetOB - devctl”,res);
return -1;
}
else return 0;
}
else return data;
}
<…>
res = readcond( Ser_Fd,buf,b_num,b_num,time,timeout );
<…>
// error check
if ( GetOB() > 0) {
req->result = TR_ELINE;
LogTransportError(“LineError”,0);
return 0;
}
Artem Smolenkov
Ian Gibb