stty utility

bridged with qdn.public.qnxrtp.applications
Post Reply
Geoff

stty utility

Post by Geoff » Fri Nov 29, 2002 6:38 am

The stty utility appears to have a problem identifying the type of
devices as serial unless it is actually called /dev/ser*. If it is not
identified as serial, or anything else, it displays "unknown" but more
importantly, won't display the serial parameters (baudrate, data bits,
etc). To rely on the device name to determine the type seems to me to be
a rather bad assumption to make. This was not the case in QNX4.

This is a problem for me (and I presume others) as I am writing a driver
for an intelligent serial card and the devices will not be called
/dev/ser*, as this will conflict with the devices owned by devc-ser8250
(if it is running). Furthermore, like the QNX4 serial drivers, but
unlike devc-ser8250, the driver I am working on will allow the user to
specify any device name they like away from the default. Therefore it is
very important that stty be able to identify the type and display the
information available correctly, and independent of the name. Given the
DCMD list as it is, I'm not sure how this could be done. Intuitively, I
would add a field to the _ttyinfo structure so that the type could be
returned back to the client along with the device name and number of
opened.

With the QNX4 stty utility the modem control lines of the device were
displayed along with the parameters. Furthermore, it was possible to
change the state of RTS and DTR. These [very usefull] features appear to
be missing from the QNX6 stty utility: would it be possible to have them
put back please? Or make the source for stty available so that I or
someone else can do it?

Thanks,

Geoff Roberts.

Chris McKillop

Re: stty utility

Post by Chris McKillop » Fri Nov 29, 2002 7:12 am

Couple of things...

o stty only looks at the info.ttyname (from the DCMD_CHR_TTYINFO) for the
prefix ser. So you can feel free to call your device ser-smart or
serial-device or anything you like as long as the first three letters
begin with ser. (the other options currently being con, tty and par).

o Strictly speaking, if you aren't using the io-char library then you
can pass back anything you like from the DCMD_CHR_TTYINFO. So even
if your device is /dev/smart-serial1 you could return ser-smart-serial1
in the info.ttyname.

o All the devc servers support a -u option to set the base numbering
for the device(s) they create. So you could use /dev/serX and allow
the user to pick where X starts. For example, on my dev machine I have
a PCI serial device not detected by the enumerators, so I start it
by hand...

/sbin/devc-ser8250 -u3 -T4 -t4 0x1ca0,11 0x1c98,11

...which adds two devices, /dev/ser3 and /dev/ser4.

o Lastly, if you give stty the -a flag I belive you can see and set
every option regardless of the type. Try doing "stty < /dev/con1"
and then "stty -a < /dev/con1" and then "stty baud=9600 < /dev/con1"
and finally another "stty -a < /dev/con1" to see the baud-rate change.

Hope this is helpfull...
chris


Geoff <geoff@rtts.com.au> wrote:
The stty utility appears to have a problem identifying the type of
devices as serial unless it is actually called /dev/ser*. If it is not
identified as serial, or anything else, it displays "unknown" but more
importantly, won't display the serial parameters (baudrate, data bits,
etc). To rely on the device name to determine the type seems to me to be
a rather bad assumption to make. This was not the case in QNX4.

This is a problem for me (and I presume others) as I am writing a driver
for an intelligent serial card and the devices will not be called
/dev/ser*, as this will conflict with the devices owned by devc-ser8250
(if it is running). Furthermore, like the QNX4 serial drivers, but
unlike devc-ser8250, the driver I am working on will allow the user to
specify any device name they like away from the default. Therefore it is
very important that stty be able to identify the type and display the
information available correctly, and independent of the name. Given the
DCMD list as it is, I'm not sure how this could be done. Intuitively, I
would add a field to the _ttyinfo structure so that the type could be
returned back to the client along with the device name and number of
opened.

With the QNX4 stty utility the modem control lines of the device were
displayed along with the parameters. Furthermore, it was possible to
change the state of RTS and DTR. These [very usefull] features appear to
be missing from the QNX6 stty utility: would it be possible to have them
put back please? Or make the source for stty available so that I or
someone else can do it?

Thanks,

Geoff Roberts.
--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Geoff

Re: stty utility

Post by Geoff » Fri Nov 29, 2002 8:18 am

Chris McKillop wrote:
Couple of things...

o stty only looks at the info.ttyname (from the DCMD_CHR_TTYINFO) for the
prefix ser. So you can feel free to call your device ser-smart or
serial-device or anything you like as long as the first three letters
begin with ser. (the other options currently being con, tty and par).
I think I can live with that.
o Strictly speaking, if you aren't using the io-char library then you
can pass back anything you like from the DCMD_CHR_TTYINFO. So even
if your device is /dev/smart-serial1 you could return ser-smart-serial1
in the info.ttyname.
o All the devc servers support a -u option to set the base numbering
for the device(s) they create. So you could use /dev/serX and allow
the user to pick where X starts. For example, on my dev machine I have
a PCI serial device not detected by the enumerators, so I start it
by hand...

/sbin/devc-ser8250 -u3 -T4 -t4 0x1ca0,11 0x1c98,11

...which adds two devices, /dev/ser3 and /dev/ser4.


o Lastly, if you give stty the -a flag I belive you can see and set
every option regardless of the type. Try doing "stty < /dev/con1"
and then "stty -a < /dev/con1" and then "stty baud=9600 < /dev/con1"
and finally another "stty -a < /dev/con1" to see the baud-rate change.
I missed this. Yes, it helps. All we're missing now is the ability to
change the modem lines ;-), but that was a secondary issue. Thanks very
much.

Geoff.
Hope this is helpfull...
chris

Geoff <geoff@rtts.com.au> wrote:
The stty utility appears to have a problem identifying the type of
devices as serial unless it is actually called /dev/ser*. If it is not
identified as serial, or anything else, it displays "unknown" but more
importantly, won't display the serial parameters (baudrate, data bits,
etc). To rely on the device name to determine the type seems to me to be
a rather bad assumption to make. This was not the case in QNX4.

This is a problem for me (and I presume others) as I am writing a driver
for an intelligent serial card and the devices will not be called
/dev/ser*, as this will conflict with the devices owned by devc-ser8250
(if it is running). Furthermore, like the QNX4 serial drivers, but
unlike devc-ser8250, the driver I am working on will allow the user to
specify any device name they like away from the default. Therefore it is
very important that stty be able to identify the type and display the
information available correctly, and independent of the name. Given the
DCMD list as it is, I'm not sure how this could be done. Intuitively, I
would add a field to the _ttyinfo structure so that the type could be
returned back to the client along with the device name and number of
opened.

With the QNX4 stty utility the modem control lines of the device were
displayed along with the parameters. Furthermore, it was possible to
change the state of RTS and DTR. These [very usefull] features appear to
be missing from the QNX6 stty utility: would it be possible to have them
put back please? Or make the source for stty available so that I or
someone else can do it?

Thanks,

Geoff Roberts.

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/
--

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

Igor Kovalenko

Re: stty utility

Post by Igor Kovalenko » Sun Dec 08, 2002 6:04 am

Come on Chris, so many explanations for the obviously bad idea of using a
device name to determine its type...

"Chris McKillop" <cdm@qnx.com> wrote in message
news:as7414$np$1@nntp.qnx.com...
Couple of things...

o stty only looks at the info.ttyname (from the DCMD_CHR_TTYINFO) for the
prefix ser. So you can feel free to call your device ser-smart or
serial-device or anything you like as long as the first three letters
begin with ser. (the other options currently being con, tty and par).

o Strictly speaking, if you aren't using the io-char library then you
can pass back anything you like from the DCMD_CHR_TTYINFO. So even
if your device is /dev/smart-serial1 you could return ser-smart-serial1
in the info.ttyname.

o All the devc servers support a -u option to set the base numbering
for the device(s) they create. So you could use /dev/serX and allow
the user to pick where X starts. For example, on my dev machine I have
a PCI serial device not detected by the enumerators, so I start it
by hand...

/sbin/devc-ser8250 -u3 -T4 -t4 0x1ca0,11 0x1c98,11

...which adds two devices, /dev/ser3 and /dev/ser4.

o Lastly, if you give stty the -a flag I belive you can see and set
every option regardless of the type. Try doing "stty < /dev/con1"
and then "stty -a < /dev/con1" and then "stty baud=9600 < /dev/con1"
and finally another "stty -a < /dev/con1" to see the baud-rate change.

Hope this is helpfull...
chris


Geoff <geoff@rtts.com.au> wrote:
The stty utility appears to have a problem identifying the type of
devices as serial unless it is actually called /dev/ser*. If it is not
identified as serial, or anything else, it displays "unknown" but more
importantly, won't display the serial parameters (baudrate, data bits,
etc). To rely on the device name to determine the type seems to me to be
a rather bad assumption to make. This was not the case in QNX4.

This is a problem for me (and I presume others) as I am writing a driver
for an intelligent serial card and the devices will not be called
/dev/ser*, as this will conflict with the devices owned by devc-ser8250
(if it is running). Furthermore, like the QNX4 serial drivers, but
unlike devc-ser8250, the driver I am working on will allow the user to
specify any device name they like away from the default. Therefore it is
very important that stty be able to identify the type and display the
information available correctly, and independent of the name. Given the
DCMD list as it is, I'm not sure how this could be done. Intuitively, I
would add a field to the _ttyinfo structure so that the type could be
returned back to the client along with the device name and number of
opened.

With the QNX4 stty utility the modem control lines of the device were
displayed along with the parameters. Furthermore, it was possible to
change the state of RTS and DTR. These [very usefull] features appear to
be missing from the QNX6 stty utility: would it be possible to have them
put back please? Or make the source for stty available so that I or
someone else can do it?

Thanks,

Geoff Roberts.

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Geoff

Re: stty utility

Post by Geoff » Mon Dec 09, 2002 10:30 am

After stewing on this for the last week or so, and perhaps prematurely
saying that I could live with, I now have to agree with Igor and
re-iterate my original statement.

I am developing a serial driver for a product that is amongst the market
leaders of such products. I have already had word from an eventual QNX6
user of it that freedom to name the devices whatever they want is a
requirement: in their case they want their devices named without the
"ser" AND they want stty to work and identify it correctly (for obvious
reasons).

In QNX4 Dev was told during the registration process what the device
type was ("serial") and presumably stty was able to obtain this snippet
from Dev. Of course, now we don't have Dev. But we _do_ have a ttyinfo
structure that contains at least the name of the device. Surely it would
have been or would be simple to add a field to this to return the device
type. It seems to me that it was never considered that there would be
either any other serial driver than devc-ser8250 or that eveyone would
want to incorportate the substring "ser" in their device names.

I think it would be a mistake to discount the importance of serial I/O
to the QNX world. The serial or char-io DDK seems to be very much a
black sheep - it is not even mentioned in the documents with the other
DDK's. My aussie 2 cents on that...

I am now having a very intimate relationship with the serial DDK.
Overall it is good and I like it - I am however having my moments of
pain adapting (or rather implementing) it without documentation to the
specific requirements of the intelligent serial card I amd working with,
but that's OK. It's looking good, but it's always the little things that
stick out.

Geoff.




Igor Kovalenko wrote:
Come on Chris, so many explanations for the obviously bad idea of using a
device name to determine its type...

"Chris McKillop" <cdm@qnx.com> wrote in message
news:as7414$np$1@nntp.qnx.com...
Couple of things...

o stty only looks at the info.ttyname (from the DCMD_CHR_TTYINFO) for the
prefix ser. So you can feel free to call your device ser-smart or
serial-device or anything you like as long as the first three letters
begin with ser. (the other options currently being con, tty and par).

o Strictly speaking, if you aren't using the io-char library then you
can pass back anything you like from the DCMD_CHR_TTYINFO. So even
if your device is /dev/smart-serial1 you could return ser-smart-serial1
in the info.ttyname.

o All the devc servers support a -u option to set the base numbering
for the device(s) they create. So you could use /dev/serX and allow
the user to pick where X starts. For example, on my dev machine I have
a PCI serial device not detected by the enumerators, so I start it
by hand...

/sbin/devc-ser8250 -u3 -T4 -t4 0x1ca0,11 0x1c98,11

...which adds two devices, /dev/ser3 and /dev/ser4.

o Lastly, if you give stty the -a flag I belive you can see and set
every option regardless of the type. Try doing "stty < /dev/con1"
and then "stty -a < /dev/con1" and then "stty baud=9600 < /dev/con1"
and finally another "stty -a < /dev/con1" to see the baud-rate change.

Hope this is helpfull...
chris


Geoff <geoff@rtts.com.au> wrote:
The stty utility appears to have a problem identifying the type of
devices as serial unless it is actually called /dev/ser*. If it is not
identified as serial, or anything else, it displays "unknown" but more
importantly, won't display the serial parameters (baudrate, data bits,
etc). To rely on the device name to determine the type seems to me to be
a rather bad assumption to make. This was not the case in QNX4.

This is a problem for me (and I presume others) as I am writing a driver
for an intelligent serial card and the devices will not be called
/dev/ser*, as this will conflict with the devices owned by devc-ser8250
(if it is running). Furthermore, like the QNX4 serial drivers, but
unlike devc-ser8250, the driver I am working on will allow the user to
specify any device name they like away from the default. Therefore it is
very important that stty be able to identify the type and display the
information available correctly, and independent of the name. Given the
DCMD list as it is, I'm not sure how this could be done. Intuitively, I
would add a field to the _ttyinfo structure so that the type could be
returned back to the client along with the device name and number of
opened.

With the QNX4 stty utility the modem control lines of the device were
displayed along with the parameters. Furthermore, it was possible to
change the state of RTS and DTR. These [very usefull] features appear to
be missing from the QNX6 stty utility: would it be possible to have them
put back please? Or make the source for stty available so that I or
someone else can do it?

Thanks,

Geoff Roberts.

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

--

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

Post Reply

Return to “qdn.public.qnxrtp.applications”