A few weeks ago I reported a bug in devc-ser8250 which was giving me a hard
time. Now that I have had a gap long enough to look closer at the bug, I
have fixed it (I hope).
The problem came with reading the state of the serial control lines, while
using more than on serial port. What would happen is that the state of the
incoming lines for whichever port’s lines changed most recently would be
reported for all the ports.
After downloading the devc ddk I discovered that a global variable was used
to hold the state of the most recent line change and this same variable was
used to service all requests for line status.
I have now patched my copy of devc-ser8250, as a bonus my copy of
devc-tser8250 was updated as well, free of charge. I have posted the diffs
below for anyone else who is interested.
Enjoy,
Larry
P.S. Thanks to QNX who made it so easy to fix. (Download ddk, cvs out
source, patch source, type make).
“Larry Holding” <> larryh@ansys.co.za> > wrote in message
news:9r0u6t$srg$> 1@inn.qnx.com> …
A few weeks ago I reported a bug in devc-ser8250 which was giving me a
hard
time. Now that I have had a gap long enough to look closer at the bug, I
have fixed it (I hope).
Thanks Larry, although your exact fix won’t be used, we’ve already patched
it, and it should be included in the next release.
Quick question – does this bug exist in the QNX 4 version of Dev.ser? (I thought
the codebase was similar or at least “derived” …??)
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
I too have been having problems with devc-ser8250, but I thought it might
have been a problem with the serial I/O card I was using. My application
supports a full duplex protocol over a serial port at 56K to a device which
we manufacture. To emulate our device, I wrote a loopback program and used
a null modem cable to link /dev/ser1 and /sev/ser2 together. The
application ran perfectly fine, except every so often, the data flow
“freezes” for anywhere from 2 to 15 seconds. Using the debugger, I
determined that readcond(), did not return within the provided timeout (I
asked it to return with >1 bytes or after 5 seconds). This problem occurs
on releases 6.0B, 6.0C and 6.1A. Both /dev/ser1 and /dev/ser2 are linked to
COM1 and COM2 respectively (standard PC board).
In addition to the data flow “freezing”, I also appear to be having a
problem with my serial I/O card. I purchased a Blueheat 8-port serial card
from connecttech and I run their wrapper, which in turn invokes devc-ser8250
with the correct parameters. Now, I run the same loopback program on ports
attached to the serial I/O card and it ceases to operate correctly. Its
almost as if it does not recognise hardware flow control (actually
connecttech ships their Blueheat card wrapper with a special program as they
say that QNX’s stty cannot determine the state of the hardware control
lines). I wonder if the problem is actually with dev-ser8250 and not with
stty.
“Larry Holding” <> larryh@ansys.co.za> > wrote in message
news:9r0u6t$srg$> 1@inn.qnx.com> …
A few weeks ago I reported a bug in devc-ser8250 which was giving me a
hard
time. Now that I have had a gap long enough to look closer at the bug, I
have fixed it (I hope).
Thanks Larry, although your exact fix won’t be used, we’ve already patched
it, and it should be included in the next release.
A few weeks ago I reported a bug in devc-ser8250 which was giving me a
hard
time. Now that I have had a gap long enough to look closer at the bug, I
have fixed it (I hope).
Thanks Larry, although your exact fix won’t be used, we’ve already patched
it, and it should be included in the next release.
I just looked at our cvs tree and there was no variant for QNX4 under
the devc-ser8250 code. So it looks like it is a separate codebase
(not sure exactly why that is exactly).
So the fix probably didn’t make it to the QNX 4 driver yet.
Operating System Tech Support <> os@qnx.com> > wrote:
“Larry Holding” <> larryh@ansys.co.za> > wrote in message
news:9r0u6t$srg$> 1@inn.qnx.com> …
A few weeks ago I reported a bug in devc-ser8250 which was giving me a
hard
time. Now that I have had a gap long enough to look closer at the bug, I
have fixed it (I hope).
Thanks Larry, although your exact fix won’t be used, we’ve already patched
it, and it should be included in the next release.
Quick question – does this bug exist in the QNX 4 version of Dev.ser? (I thought
the codebase was similar or at least “derived” …??)
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at > www.parse.com
The 2 to 15 seconds sounds worrysome to me. I have an application that
interfaces to some hardware via rs-232. The hardware watchdog will reset the
the equipment if it does not receive serial messages at least once a second.
What I have found recently is that the hardware is occasionally (every
couple of weeks) reseting,
We created a listener processes running on an other machine that just
eavesdrops on the serial traffic (both ways) using 2 serial ports. What we
found was that our QNX machine stops transmitting data out the serial port
for around 14 seconds. We are also logging what is being written to the
port. The serial interface gives no indication that anything is wrong (the
writes continue with no errors) When data starts flowing again the 14
seconds of data seems lost as the first message output is the last message
written to the port.
The ports is running at 9600 baud on a dual serial (Lava dual serial pci
card). The other port on the card is receiving a data feed at 56k. (4.8k
Bytes per sec). We are running version 6.1A.
I too have been having problems with devc-ser8250, but I thought it might
have been a problem with the serial I/O card I was using. My application
supports a full duplex protocol over a serial port at 56K to a device
which
we manufacture. To emulate our device, I wrote a loopback program and
used
a null modem cable to link /dev/ser1 and /sev/ser2 together. The
application ran perfectly fine, except every so often, the data flow
“freezes” for anywhere from 2 to 15 seconds. Using the debugger, I
determined that readcond(), did not return within the provided timeout (I
asked it to return with >1 bytes or after 5 seconds). This problem occurs
on releases 6.0B, 6.0C and 6.1A. Both /dev/ser1 and /dev/ser2 are linked
to
COM1 and COM2 respectively (standard PC board).
In addition to the data flow “freezing”, I also appear to be having a
problem with my serial I/O card. I purchased a Blueheat 8-port serial
card
from connecttech and I run their wrapper, which in turn invokes
devc-ser8250
with the correct parameters. Now, I run the same loopback program on
ports
attached to the serial I/O card and it ceases to operate correctly. Its
almost as if it does not recognise hardware flow control (actually
connecttech ships their Blueheat card wrapper with a special program as
they
say that QNX’s stty cannot determine the state of the hardware control
lines). I wonder if the problem is actually with dev-ser8250 and not with
stty.
“Operating System Tech Support” <> os@qnx.com> > wrote in message
news:9r1l3p$kej$> 1@nntp.qnx.com> …
“Larry Holding” <> larryh@ansys.co.za> > wrote in message
news:9r0u6t$srg$> 1@inn.qnx.com> …
A few weeks ago I reported a bug in devc-ser8250 which was giving me a
hard
time. Now that I have had a gap long enough to look closer at the bug,
I
have fixed it (I hope).
Thanks Larry, although your exact fix won’t be used, we’ve already
patched
it, and it should be included in the next release.
| in8(port[REG_MC])) & 0xf003);