eric@sactoh0.UUCP (Eric J. Nihill) (07/29/90)
I would like to thank all those who took the time to respond
to my question regarding hardware flow control from a EPORTS
board to a TB+. (System=AT&T3B2/310 SVR3.2.2)
The general concensus seems to be that it can't be done. There
have been several people who noted that there are bugs in the
drivers. I currently have version 1.2 and was told that 1.3
may work better. ( Now to try to find a copy! )
One of the troubles seems to be that in release 1.2 of the
EPORTS driver, AT&T supplies a new getty for HFC. However,
there is no uugetty inclosed. Hopefully it is in 1.3. Also
is the hope that there is a HFC variable that can be set in
the gettydefs line to set hfc.
Several people suggested hacks that could be made to the
source code, but I neither have source nor am a programmer.
Oh well, I'll just go back and sit on the bench. :-)
Again, thank-you for your time and information.
Eric
(P.S. Want'a buy a 300 w/ XM package? )
--
Some do, some don't. | eric@sactoh0
Some will, some won't. | ames!pacbell!sactoh0!eric
I might! | ucbvax!csusac!sactoh0!eric
| USMail 95611-0785woods@robohack.UUCP (Greg A. Woods) (07/30/90)
In article <3613@sactoh0.UUCP> eric@sactoh0.UUCP (Eric J. Nihill) writes: > [re: EPORTS version] I currently have version 1.2 and was told that 1.3 > may work better. ( Now to try to find a copy! ) Call AT&T. > One of the troubles seems to be that in release 1.2 of the > EPORTS driver, AT&T supplies a new getty for HFC. However, > there is no uugetty inclosed. Hopefully it is in 1.3. Also > is the hope that there is a HFC variable that can be set in > the gettydefs line to set hfc. I didn't even notice a different getty. There's definitely no new uugetty though. There won't be an HFC for gettydefs either. In their wisdom, AT&T put the EPORTS control under a totally different interface (i.e. different struct's and ioctl() commands). It is impossible to even hack the right bit into a binary of getty (or uugetty). You can't even set HFC with an stty, rather you have to use epstty. It was a really brain-dead, stupid thing to do, especially after almost every other vendor had used (usually the same) un-used bits in a termio flag to do the same. > Several people suggested hacks that could be made to the > source code, but I neither have source nor am a programmer. Don't let that stop you! :-) If I had a Telebit, I might bother to hack one of the PD uugetty's to work properly with EPORTS.... > (P.S. Want'a buy a 300 w/ XM package? ) I am looking for a really cheap XM with only a power supply.... -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
friedl@mtndew.UUCP (Stephen J. Friedl) (07/30/90)
Greg A. Woods writes: > > You can't > even set HFC with an stty, rather you have to use epstty. It was a > really brain-dead, stupid thing to do, especially after almost every > other vendor had used (usually the same) un-used bits in a termio flag > to do the same. The reason for this is that they wanted to keep the UNIX porting base free from port-specific code. Note that there are not that many unused bits in the termio flag, and this is not the best way to do it anyway. I don't like the epstty approach either, but it's not "brain dead". Steve -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "I'm a simple girl; I wear a cat on my head." - Laura Dykstra @ NCR Orlando
woods@robohack.UUCP (Greg A. Woods) (07/31/90)
In article <473@mtndew.UUCP> friedl@mtndew.UUCP (Stephen J. Friedl) writes: > Greg A. Woods writes: > > > > You can't > > even set HFC with an stty, rather you have to use epstty. It was a > > really brain-dead, stupid thing to do, especially after almost every > > other vendor had used (usually the same) un-used bits in a termio flag > > to do the same. > > The reason for this is that they wanted to keep the UNIX porting > base free from port-specific code. Note that there are not that > many unused bits in the termio flag, and this is not the best way > to do it anyway. Unfortunately there are enough free bits to allow a choice. Without the leadership of AT&T by putting such features in the porting base, we end up with in-compatible flags and manifest constants for different vendors, making it really difficult to maintain portable code. Not only that, but with so many vendors out there who don't know how to make rs-232 ports work (including, this time, AT&T), we end up with a lot of broken drivers. I've been banging my head against AT&T's minimalist attitude for a long time now. Even the new getty which comes with EPORTS-1.3 doesn't seem to have anything to do with HFC, but rather only supports B38400. > I don't like the epstty approach either, but it's not "brain dead". I'm not flaming at you Sephen, but I do stick firmly to my position that the eptermio design (as well as implementation) is brain dead. Your argument just doesn't stick, especially in light of what has been required for SysVr4 by POSIX with split speed control. As for your suggestion that there are better ways to do it, I'm interested in what you think. I've been puzzling over these kinds of things for quite a few years now, and perhaps I'm stuck in a rut. -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
les@chinet.chi.il.us (Leslie Mikesell) (08/01/90)
In article <1990Jul31.144823.13802@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: Re: ports that can't do both hardware flow controll and xon/xoff >> > You can't >> > even set HFC with an stty, rather you have to use epstty. It was a >> > really brain-dead, stupid thing to do, especially after almost every >> > other vendor had used (usually the same) un-used bits in a termio flag >> > to do the same. >Unfortunately there are enough free bits to allow a choice. Without >the leadership of AT&T by putting such features in the porting base, >we end up with in-compatible flags and manifest constants for >different vendors, making it really difficult to maintain portable >code. The right way to do this without causing coding problems is to provide different device names for the same port with and without HFC. However, this can still cause trouble if you use the name of the device in a locking scheme. >Not only that, but with so many vendors out there who don't >know how to make rs-232 ports work (including, this time, AT&T), we end >up with a lot of broken drivers. I've been banging my head against >AT&T's minimalist attitude for a long time now. Amen. How many years were smart modems around before it was possible to dial them reasonably (the \M,\m tokens in Dialers)? It wouldn't have been possible to do this in combination with uugetty before the SysVr3 release because an open without O_NDELAY (uugetty's) would never complete if another process opened the same port with O_NDELAY. Now, they still don't believe that people might use a speed-matching modem with HFC for an interactive application where xon/xoff is needed. >As for your suggestion that there are better ways to do it, I'm >interested in what you think. I've been puzzling over these kinds of >things for quite a few years now, and perhaps I'm stuck in a rut. Why doesn't everyone just provide HFC by default, always on? If you connect to a device that doesn't support it, all you have to do is loop back the computer's RTS to CTS. I can make up a custom cable a lot faster than waiting for AT&T to make their software work (Has it been 5 years already?). Les Mikesell les@chinet.chi.il.us
woods@robohack.UUCP (Greg A. Woods) (08/03/90)
In article <1990Aug01.164029.3251@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > Amen. How many years were smart modems around before it was possible > to dial them reasonably (the \M,\m tokens in Dialers)? It wouldn't > have been possible to do this in combination with uugetty before > the SysVr3 release because an open without O_NDELAY (uugetty's) > would never complete if another process opened the same port > with O_NDELAY. Luckily I missed this period of time. I was using XENIX, which had semi-decent bi-directional ports. (Though if I remember, Sun was the first to get it right with two devices which didn't need lock files between getty and uucico.) > Why doesn't everyone just provide HFC by default, always on? If you > connect to a device that doesn't support it, all you have to do is > loop back the computer's RTS to CTS. I can make up a custom cable > a lot faster than waiting for AT&T to make their software work (Has > it been 5 years already?). I knew there was an obvious solution! I can't quite figure out why the damn PORTS card didn't have hardware flow control in the first place. I thought software flow control went out with 20 mA loop! :-) However, I will say that it's nice to have full control over a device with software, and that goes for HFC too. Now if only AT&T would provide source for their drivers, and a development system for those horrid 80186's on the smart-cards, for a decent price. Then we could fix our own problems! -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
dennis@nebulus.UUCP (Dennis S. Breckenridge) (08/09/90)
woods@robohack.UUCP (Greg A. Woods) writes: lots deleted... >Now if only AT&T would provide source for their drivers, and a >development system for those horrid 80186's on the smart-cards, for a >decent price. Then we could fix our own problems! Well the problem is obvious. The 3B2 driver is not as generic as one would like. Some of the driver code lives on the 3B2 side of the world and most of the "low level" code lives on the ports card itself. It is easy to say, if I had the source I could fix it. There are many more constraints than just broken software. The ports card is driven by it's own heartbeat and interrupts are serviced on a hardware priority. What really has to happen is the hardware has to be modified, and then a driver must be DESIGNED post facto. You cannot get away with a "MODIFICATION" of the existing driver and expect the card to work. This does not include the fact that you have to deal with the 3B2's buss protocol and data block transfer nonsense. I am sure that AT&T would be happy to relieve themselves of the constant abuse they get as a corporation regarding that whole EPORTS issue, but they are very aware of the costs involved to repair/redesign the hardware firmware and software. If it was economical to repair or resdesign do you not think that other companies would have cloned the card and fixed the driver? I wait, with flame suit donned, your reply! -- ----------------------------------------------------------------------------- Dennis S. Breckenridge (604) 277-7413 dennis@nebulus.uucp VE7-TCP Mercifully Free of the Ravages of Intelligence :-) -----------------------------------------------------------------------------
les@chinet.chi.il.us (Leslie Mikesell) (08/11/90)
In article <1990Aug9.113122.8696@nebulus.UUCP> dennis@nebulus.UUCP (Dennis S. Breckenridge) writes: >Well the problem is obvious. The 3B2 driver is not as generic as one >would like. Some of the driver code lives on the 3B2 side of the world >and most of the "low level" code lives on the ports card itself. It is >easy to say, if I had the source I could fix it. There are many more >constraints than just broken software. The ports card is driven by it's >own heartbeat and interrupts are serviced on a hardware priority. What >really has to happen is the hardware has to be modified, and then a driver >must be DESIGNED post facto. Why would any hardware have to be modified to make software flow control work? Are you saying that the on-board 80186 can't see the characters that are transfered into the 3B2 memory, or that the 3B2's ioctl's can't pass information to the 80186 when the modes are changed? The obvious thing to do is to let the on-board CPU deal with both types of flow control and unless something is really wierd it should be possible in software. >[...] If it was economical to repair or >resdesign do you not think that other companies would have cloned the card >and fixed the driver? No. Why should they? But you might note that the 80386 ports expansion almost works right. Is this due to having to compete with equivalent reasonable products or did the whole thing come from an outside source? Les Mikesell les@chinet.chi.il.us