Hello,
I’ve been working on this software that sends data over the serial port.
I’ve come across some (rather annoying) problem that I can’t seem to figure
out. I have hardware that I want to have hooked up to ser1. My software is
configured to use this port, but is changeable (a quick define at the top
can change it). As I go to run my software, I send data out and expect data
coming back, but nothing ever comes back. So, I grab the trusty
oscilloscope and start checking the lines. For the serial port, I find that
NOTHING is coming out of the port (tx line). I then go and check the other
serial port pins, and voila, there’s data coming out. So I quickly change
my setup to use the other port, compile the software, and it stops working.
Same issue. I had the hardware engineer that built the hardware verify that
everything was “safe” and that it wasn’t doing anything to disrupt the uart.
So I’m wondering what might happen that would suddenly make the UART not
transmit data. I’ve killed/restarted the serial drivers but nothing seems
to fix it. Any hints on this are appreciated.
Ron
PS: version of Dev32.ser I’m using is 4.23I
Run stty on the port. Look for a “paged” option turned on.
This means that you have some flow control turned on,
probably hardware, that is holding things up.
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Hello,
I’ve been working on this software that sends data over the serial port.
I’ve come across some (rather annoying) problem that I can’t seem to figure
out. I have hardware that I want to have hooked up to ser1. My software is
configured to use this port, but is changeable (a quick define at the top
can change it). As I go to run my software, I send data out and expect data
coming back, but nothing ever comes back. So, I grab the trusty
oscilloscope and start checking the lines. For the serial port, I find that
NOTHING is coming out of the port (tx line). I then go and check the other
serial port pins, and voila, there’s data coming out. So I quickly change
my setup to use the other port, compile the software, and it stops working.
Same issue. I had the hardware engineer that built the hardware verify that
everything was “safe” and that it wasn’t doing anything to disrupt the uart.
So I’m wondering what might happen that would suddenly make the UART not
transmit data. I’ve killed/restarted the serial drivers but nothing seems
to fix it. Any hints on this are appreciated.
Ron
PS: version of Dev32.ser I’m using is 4.23I
\
–
Mitchell Schoenbrun --------- maschoen@pobox.com
Mitchell,
You are a God! Didn’t even notice it on the machine at first, I was looking
at every one of the options, and skimmed over it quickly not noticing the
+ohpaged. Turned it off (as well as hardware flow controls) and voila, it
worked beautifully.
TX!
Ron
“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010625120259.199D@schoenbrun.com…
Run stty on the port. Look for a “paged” option turned on.
This means that you have some flow control turned on,
probably hardware, that is holding things up.
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Hello,
I’ve been working on this software that sends data over the serial port.
I’ve come across some (rather annoying) problem that I can’t seem to
figure
out. I have hardware that I want to have hooked up to ser1. My
software is
configured to use this port, but is changeable (a quick define at the
top
can change it). As I go to run my software, I send data out and expect
data
coming back, but nothing ever comes back. So, I grab the trusty
oscilloscope and start checking the lines. For the serial port, I find
that
NOTHING is coming out of the port (tx line). I then go and check the
other
serial port pins, and voila, there’s data coming out. So I quickly
change
my setup to use the other port, compile the software, and it stops
working.
Same issue. I had the hardware engineer that built the hardware verify
that
everything was “safe” and that it wasn’t doing anything to disrupt the
uart.
So I’m wondering what might happen that would suddenly make the UART not
transmit data. I’ve killed/restarted the serial drivers but nothing
seems
to fix it. Any hints on this are appreciated.
Ron
PS: version of Dev32.ser I’m using is 4.23I
\
Mitchell Schoenbrun --------- > maschoen@pobox.com
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Mitchell,
You are a God! Didn’t even notice it on the machine at first, I was looking
at every one of the options, and skimmed over it quickly not noticing the
+ohpaged. Turned it off (as well as hardware flow controls) and voila, it
worked beautifully.
Burnt offerings accepted at my website. 
.
I think that you can turn off +ohpaged in a program with
tcsetattr() if you prefer.
Mitchell Schoenbrun --------- maschoen@pobox.com
Mitchell Schoenbrun wrote:
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Mitchell,
You are a God! Didn’t even notice it on the machine at first, I was looking
at every one of the options, and skimmed over it quickly not noticing the
+ohpaged. Turned it off (as well as hardware flow controls) and voila, it
worked beautifully.
But don’t turn off flow control, you probably will need it and hardware style is
preferred if you have enough wires in your cable.
Burnt offerings accepted at my website. > > .
I think that you can turn off +ohpaged in a program with
tcsetattr() if you prefer.
Mitchell Schoenbrun --------- > maschoen@pobox.com
It doesn’t work well with hardware flow control on, I’ve only got RX and TX
connected (DTR and RTS are used in a special way). It works fine without
hardware flow control too.
“Dean Douthat” <ddouthat@faac.com> wrote in message
news:3B38BA54.ED9F5394@faac.com…
Mitchell Schoenbrun wrote:
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Mitchell,
You are a God! Didn’t even notice it on the machine at first, I was
looking
at every one of the options, and skimmed over it quickly not noticing
the
+ohpaged. Turned it off (as well as hardware flow controls) and
voila, it
worked beautifully.
But don’t turn off flow control, you probably will need it and hardware
style is
preferred if you have enough wires in your cable.
Burnt offerings accepted at my website. > > .
I think that you can turn off +ohpaged in a program with
tcsetattr() if you prefer.
Mitchell Schoenbrun --------- > maschoen@pobox.com
Mitchell Schoenbrun <maschoen@pobox.com> wrote:
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Mitchell,
You are a God! Didn’t even notice it on the machine at first, I was looking
at every one of the options, and skimmed over it quickly not noticing the
+ohpaged. Turned it off (as well as hardware flow controls) and voila, it
worked beautifully.
Burnt offerings accepted at my website. > > .
I think that you can turn off +ohpaged in a program with
tcsetattr() if you prefer.
Actually, I think you need to use tcflow().
-David
QNX Training Services
dagibbs@qnx.com
You can also turn off HW flow control in sysinit either with stty commands
or by putting ‘-F’ (I think) on the Dev.ser command line.
Bill Caroselli
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:9haefr$799$3@nntp.qnx.com…
Mitchell Schoenbrun <> maschoen@pobox.com> > wrote:
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Mitchell,
You are a God! Didn’t even notice it on the machine at first, I was
looking
at every one of the options, and skimmed over it quickly not noticing
the
+ohpaged. Turned it off (as well as hardware flow controls) and voila,
it
worked beautifully.
Burnt offerings accepted at my website. > > .
I think that you can turn off +ohpaged in a program with
tcsetattr() if you prefer.
Actually, I think you need to use tcflow().
-David
QNX Training Services
dagibbs@qnx.com