Hello Everybody,
I have come across a problem and I am wondering if anyone else has seen
this. We got a new shipment of computers and for some reason I can’t get
the serial ports to work in QNX, however I can get a modem set to
/dev/ser3 to work, so I am quite sure the Dev32.ser is working, but for
some reason can’t handle these new boards.
The motherboard is an ASUS, and this is what is written on the chip
Intel
FW82801BA
F0371K35
SL4HM
Has anyone seen this before?
Chris Nasr
cnasr[at]mechtronix[dot]ca
Mechtronix Systems Inc.
Hello Everybody,
I have come across a problem and I am wondering if anyone else has seen
this. We got a new shipment of computers and for some reason I can’t get
the serial ports to work in QNX, however I can get a modem set to
/dev/ser3 to work, so I am quite sure the Dev32.ser is working, but for
some reason can’t handle these new boards.
What do you mean by not working - a little more detail is needed. Also, if
you have a modem on Com3, that port typically uses the same IRQ as COM1
(unless you changed that), and could be causing you problems.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
I mean if I plug a 9 pin connector on it where pin 2 and 3 are shorted
together so that anything I send out comes right back in, I get nothing.
I run qtalk, I type, nothing comes back. I have tried this on both
serial ports on both computers. Also I have tried this on Windows
machines with the exact same hardware and everything works great.
The modem is not the problem, guaranteed, because a) we’ve used the same
configuration for the longest time, pci modems set as ser3 via arguments
to Dev.ser, and b) because the same exact thing is happening in the
other computer with no modem.
I only brought up the modem to mention that I don’t think it’s simply
Dev.ser that is corrupted.
Chris Nasr
cnasr[at]mechtronix[dot]ca
Mechtronix Systems Inc.
Hello Everybody,
I have come across a problem and I am wondering if anyone else has seen
this. We got a new shipment of computers and for some reason I can’t get
the serial ports to work in QNX, however I can get a modem set to
/dev/ser3 to work, so I am quite sure the Dev32.ser is working, but for
some reason can’t handle these new boards.
What do you mean by not working - a little more detail is needed. Also, if
you have a modem on Com3, that port typically uses the same IRQ as COM1
(unless you changed that), and could be causing you problems.
I mean if I plug a 9 pin connector on it where pin 2 and 3 are shorted
together so that anything I send out comes right back in, I get nothing.
I run qtalk, I type, nothing comes back. I have tried this on both
serial ports on both computers. Also I have tried this on Windows
machines with the exact same hardware and everything works great.
The modem is not the problem, guaranteed, because a) we’ve used the same
configuration for the longest time, pci modems set as ser3 via arguments
to Dev.ser, and b) because the same exact thing is happening in the
other computer with no modem.
I only brought up the modem to mention that I don’t think it’s simply
Dev.ser that is corrupted.
Chris Nasr
cnasr[at]mechtronix[dot]ca
Mechtronix Systems Inc.
Hello Everybody,
I have come across a problem and I am wondering if anyone else has seen
this. We got a new shipment of computers and for some reason I can’t get
the serial ports to work in QNX, however I can get a modem set to
/dev/ser3 to work, so I am quite sure the Dev32.ser is working, but for
some reason can’t handle these new boards.
What do you mean by not working - a little more detail is needed. Also,
if
you have a modem on Com3, that port typically uses the same IRQ as COM1
(unless you changed that), and could be causing you problems.
\
I mean if I plug a 9 pin connector on it where pin 2 and 3 are shorted
together so that anything I send out comes right back in, I get nothing.
I run qtalk, I type, nothing comes back. I have tried this on both
serial ports on both computers. Also I have tried this on Windows
machines with the exact same hardware and everything works great.
The modem is not the problem, guaranteed, because a) we’ve used the same
configuration for the longest time, pci modems set as ser3 via arguments
to Dev.ser, and b) because the same exact thing is happening in the
other computer with no modem.
I only brought up the modem to mention that I don’t think it’s simply
Dev.ser that is corrupted.
Chris Nasr
cnasr[at]mechtronix[dot]ca
Mechtronix Systems Inc.
Hello Everybody,
I have come across a problem and I am wondering if anyone else has seen
this. We got a new shipment of computers and for some reason I can’t get
the serial ports to work in QNX, however I can get a modem set to
/dev/ser3 to work, so I am quite sure the Dev32.ser is working, but for
some reason can’t handle these new boards.
What do you mean by not working - a little more detail is needed. Also,
if
you have a modem on Com3, that port typically uses the same IRQ as COM1
(unless you changed that), and could be causing you problems.
What is present is the “/dev” directory for serial ports? What do you get
when you do a
“stty </dev/ser1” for instance. Please post the results of the “stty”
commands and from
a “sin arg” command. Thanks.
I mean if I plug a 9 pin connector on it where pin 2 and 3 are shorted
together so that anything I send out comes right back in, I get nothing.
I run qtalk, I type, nothing comes back. I have tried this on both
serial ports on both computers. Also I have tried this on Windows
machines with the exact same hardware and everything works great.
The modem is not the problem, guaranteed, because a) we’ve used the same
configuration for the longest time, pci modems set as ser3 via arguments
to Dev.ser, and b) because the same exact thing is happening in the
other computer with no modem.
I only brought up the modem to mention that I don’t think it’s simply
Dev.ser that is corrupted.
Chris Nasr
cnasr[at]mechtronix[dot]ca
Mechtronix Systems Inc.
Hello Everybody,
I have come across a problem and I am wondering if anyone else has
seen
this. We got a new shipment of computers and for some reason I can’t
get
the serial ports to work in QNX, however I can get a modem set to
/dev/ser3 to work, so I am quite sure the Dev32.ser is working, but
for
some reason can’t handle these new boards.
What do you mean by not working - a little more detail is needed.
Also,
if
you have a modem on Com3, that port typically uses the same IRQ as COM1
(unless you changed that), and could be causing you problems.
PID USER NAME ARGUMENTS
1 System Proc32 -l 2
2 System Slib32
4 System Fsys
5 System Fsys.eide
8 System Not available.
17 System Dev
20 System Dev.ansi -Q -n 6
22 System Dev.ser 3f8,4 2f8,3 b800,9
23 System Dev.par
24 System Dev.pty
29 System Mouse
32 System Input -d/dev/mousein ps2 -r kb -2
34 System Input -d/dev/mousein ps2 -r kb -2
38 System Iso9660fsys
39 System Fsys.floppy
40 System Pipe
46 System Net
49 System lpsrvr -f /etc/config/lpsrvr.photon
53 System Net.ether82557
59 System automap
66 System nameloc
67 System nameloc
82 System tinit -T /dev/con1 /dev/con2 /dev/con3 /dev/con4
/dev/con5 /dev/con6 -t /dev/con1 -c modem -b 115200 -L -t /dev/ser3
83 root -sh
92 System modem -b 115200 -L
11636 root sin arg
Hardware flow-control! I bet your 2-3 cable doesn’t connect the flow
control signals properly (also connect pins 4-7-8). Or disable h/w
flow control using “stty -ihflow -ohflow -ihpaged -ohpaged” or more
permanently with “Dev.ser -F”.
Chris Nasr <> cnasr@mechtronix.ca> > wrote:
Name: //2/dev/ser1
Type: serial
Opens: 1 (R-)
Sigint Grp: 0, Sighup pid: 0
+raw
+ihflow +ohflow +lkhflow +ohpaged
Hardware flow-control! I bet your 2-3 cable doesn’t connect the flow
control signals properly (also connect pins 4-7-8). Or disable h/w
flow control using “stty -ihflow -ohflow -ihpaged -ohpaged” or more
permanently with “Dev.ser -F”.
Should -F cause that ohpaged cannot be set on ?
(I don’t think so…)
But that doesn’t explain why in every other QNX machine I have and have
ever had, a loop back test works, and in these ones it doesn’t.
Besides the fact that that is just a test, an example, it still doesn’t
work when I’m connecting a cable, that has been tested, to another
device, that has been tested.
Perhaps someone would be kind enough to tell me if they have a later
version of Dev32.ser then this.
Hardware flow-control! I bet your 2-3 cable doesn’t connect the flow
control signals properly (also connect pins 4-7-8). Or disable h/w
flow control using “stty -ihflow -ohflow -ihpaged -ohpaged” or more
permanently with “Dev.ser -F”.
Should -F cause that ohpaged cannot be set on ?
(I don’t think so…)
Dev.ser -F will disable all hardware flow control.
ohpaged is a status signal indicating that there is data to output ( the
‘o’) and that hardware (the ‘h’) is preventing the bytes from being
transmitted (paged).
But that doesn’t explain why in every other QNX machine I have and have
ever had, a loop back test works, and in these ones it doesn’t.
Besides the fact that that is just a test, an example, it still doesn’t
work when I’m connecting a cable, that has been tested, to another
device, that has been tested.
Perhaps someone would be kind enough to tell me if they have a later
version of Dev32.ser then this.
I’ve seen this on some machines that h/w flow control is on.
Not sure why, but definitely if the hw control is on, using a simple
loopback on pins 2/3/7 (or 2/3/4) will not work.
Just disable the h/w flow control in your sysinit or something,
or use flow control on both sides.
Dev.ser -F will disable all hardware flow control.
Is -F option stronger than stty -ihflow -ohflow -lkhflow </dev/… ?
If yes, can I get Dev.ser lanched without -F to the same state
from C code by calling tc* functions ?
ohpaged is a status signal indicating that there is data to output ( the
‘o’) and that hardware (the ‘h’) is preventing the bytes from being
transmitted (paged).
Bill Caroselli (Q-TPS) <> QTPS@EarthLink.net> > wrote:
Dev.ser -F will disable all hardware flow control.
Is -F option stronger than stty -ihflow -ohflow -lkhflow </dev/… ?
Not stronger, just sooner. If the driver is started without the -F,
then depending on hardware design, attached cables, noise environment,
the port may think it’s been told to shutup (paged). -F tells the
driver to ignore glitches (everything, actually) on the handshaking
pins.
If yes, can I get Dev.ser lanched without -F to the same state
from C code by calling tc* functions ?
Normally, Dev.ser is started before your code. In any case, you can
use -F, stty or your prog to achieve the same effect; it’s a matter of
which is more convenient. Keep in mind that if the driver was started
without -F then you may have to not only tell the port to ignore the
handshake signals but also (explicitly) to unpage itself.
Richard
ohpaged is a status signal indicating that there is data to output ( the
‘o’) and that hardware (the ‘h’) is preventing the bytes from being
transmitted (paged).
Keep in mind too that the -F does not have to apply to all ports. On the
Dev.ser command line arguments are process in order from left to right. So:
Dev.ser 3f8,4 -F 2f8,3 &
Would olny turn off hardware flow control on the second serial port.
Bill Caroselli (Q-TPS) <> QTPS@EarthLink.net> > wrote:
Dev.ser -F will disable all hardware flow control.
Is -F option stronger than stty -ihflow -ohflow -lkhflow </dev/… ?
Not stronger, just sooner. If the driver is started without the -F,
then depending on hardware design, attached cables, noise environment,
the port may think it’s been told to shutup (paged). -F tells the
driver to ignore glitches (everything, actually) on the handshaking
pins.
If yes, can I get Dev.ser lanched without -F to the same state
from C code by calling tc* functions ?
Normally, Dev.ser is started before your code. In any case, you can
use -F, stty or your prog to achieve the same effect; it’s a matter of
which is more convenient. Keep in mind that if the driver was started
without -F then you may have to not only tell the port to ignore the
handshake signals but also (explicitly) to unpage itself.
Richard
ohpaged is a status signal indicating that there is data to output (
the
‘o’) and that hardware (the ‘h’) is preventing the bytes from being
transmitted (paged).
Hardware flow-control! I bet your 2-3 cable doesn’t connect the flow
control signals properly (also connect pins 4-7-8). Or disable h/w
flow control using “stty -ihflow -ohflow -ihpaged -ohpaged” or more
permanently with “Dev.ser -F”.
Hardware flow-control! I bet your 2-3 cable doesn’t connect the flow
control signals properly (also connect pins 4-7-8). Or disable h/w
flow control using “stty -ihflow -ohflow -ihpaged -ohpaged” or more
permanently with “Dev.ser -F”.
Hardware flow-control! I bet your 2-3 cable doesn’t connect the flow
control signals properly (also connect pins 4-7-8). Or disable h/w
flow control using “stty -ihflow -ohflow -ihpaged -ohpaged” or more
permanently with “Dev.ser -F”.