Two more replies which should be included in the summary about
hardware flow control.
The first explains that the serial chip command to enable hw flow
control, also enables dcd control of receiving; ie, the problem of
hw flow control requiring dcd before receiving, even when reading
from cua0, is written in silicon.
The second reply explains why the lack of hw flow control of output
from the modem to the sun is probably not a problem; ie, big streams
Thanks also to the folks who reminded me that rs232c doesn't use
rts to flow control output from the dce; ie, the tty is behaving
according to rs232c in that regard and my expectation that enabling
hw flow control meant that rts would flow control output from the
modem was wrong. Why did I ever expect that? It's one of the telebit
flow control options, and I got carried away with dreams of modems
speed locked to 19200, using hardware flow control to cope with
any speed splitting.
Thanks again all,
From: tgsmith@spdev.East.Sun.COM (Timothy G. Smith - Special Projects)
I took a look at the Z85c30 programmers manual and at the source and at
least have some ideas about what is going on and why.
In your first message you say:
< The modem has hardware flow control enabled, and is asserting cts.
< The problem seems to be that sunos, with hw flow control enabled,
< won't send anything out the port (eg, tty[ab], alm-2 ttys, etc), until
< dcd is asserted, even when writing (eg, tip) to cua0. Without hw flow
< control, cua0 works as expected; ie, chars go out the port in the
< absence of dcd.
Are you sure that characters don't go out the port? Have you hooked
up a serial analyzer or breakout box to watch what is happening?
I have a sinking feeling that what is really happening is that
characters are going out to the device but that they aren't coming
back in. Looking at the source for tip I found that the first thing
the hayes_dialer() routine does is call hayes_sync(). The "can't
synchronize with hayes message" message is generated when hayes_sync()
routine doesn't get a reply from the modem when it sends it AT command
to see if the modem is out there.
I suspect that the sun is indeed sending characters out to the modem
and that the modem is sending characters back to the sun but that the
sun is not seeing them.
Why? Glad you asked (*ooh* a chance to bore someone with my intimate
knowledge of everyone's favorite SCC).
HW FC is handled by setting the CRTSCTS flag for the port. If one
follows down deep enough into the kernel one finds the following hunk
if (za->za_ttycommon.t_cflag & CRTSCTS)
wr3 |= ZSWR3_AUTO_CD_CTS; /* auto RTS/CTS flow control */
The above code sets the Auto Enables bit in Write Register 3 of the
Z85c30 chip. Quoting from the SCC manual:
Bit 5: Auto Enables
This bit programs the function for both DCD and CTS pins. CTS
becomes the transmitter enable and DCD becomes the receiver
enable when this bit is set to 1.
As far as I can tell the only way to get the SCC to properly handle
CTS is to put it in Auto Enables mode. It doesn't look like DCD and
CTS can be individually configured as enables. Bummer huh?
< I've since heard from some other folks that it was a "feature" of the
< uart, so I've given up expecting a solution.
They are probably right. I can't find any way to get the Z85c30 to do
what you (and I) would like it to do.
It would be possible to hack tip to ignore CTS until DCD is active;
that would be a bit of a hack. If you really need to make things work
you should be able to get the source for tip from uunet and hack it
From: stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
i went through the h/w flow control stuff with the
h/w engineering guys about a year ago. the thought
then (and obviously, still now) is that the sunos
STREAMS driver has "infinite" headroom, so there's
no reason to ever ask the modem to stop.
the headroom isn't really infinite, but 1M+ of
data block area makes it pretty close.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:37 CDT