Serial driver for multiport card

Serial driver for multiport card

Post by Chip Yamasa » Wed, 23 Oct 1991 05:57:22



I have a multiport card from ITT called a MTS (Multiuser Terminal Subsystem)
card.  The cards included drivers for an old version of SCO Xenix, but
they don't have a driver for Unix.  The company no longer makes this
product and I may not be able to get the source for a driver.

How hard is it to write a driver for a serial card you have very loose
specs for?  Does anybody out there have a model I can start from?

Appreciate any help you can give me :-)

Thanks!
--
-----------------------+---------------------------------------------------
Charles "Chip" Yamasaki| The opinions expressed here are my own and are not

-----------------------+---------------------------------------------------

 
 
 

Serial driver for multiport card

Post by Bruce Hi » Thu, 24 Oct 1991 02:33:22



> How hard is it to write a driver for a serial card you have very loose
> specs for?  Does anybody out there have a model I can start from?

I think that without a very _detailed_ understanding of the card it will be
next to impossible to write a driver.  The driver is the part of the OS
that is supposed to know how to talk to the hardware.  Without an
understanding of the way memory is partioned for each port, the structure
of each port, registers on the card, and how they react to various conditions
the board will not behave in any expected way.  I have written many
serial card drivers, on several different OS's, and each is very different
in its own way.  Serial drivers are _very_ complex.  If you just want to be
able to read and write raw data at a fixed baud rate and character size
maybe you will be able to get something working, but once you start to
handle all of the options available in the UNIX termio specification
things can get quite hairy.  Termio specifies all the parameters that
UNIX serial tty devices must be able to handle.  Things like baud rate,
character size, parity checking, echo modes, canonical processing, output
processing, CR-NL processing, special characters like interrupt, quit,
and suspend, background/foreground and process group ioctls, etc, etc....

I think that you will be much better off buying a serial card that comes
with a driver for your particular machine.  In the long run it will save
you the 6 months of effort (at least, full time) that it will take to
get anything working on your existing hardware.

--
Bruce T. Hill          Danford Corp.               voice: (213) 514-9334
Project Manager        350 W. 5th St.              FAX:   (213) 831-0454
uunet!dannet!bruce     San Pedro, CA 90731 USA

 
 
 

Serial driver for multiport card

Post by Chris Lew » Fri, 25 Oct 1991 10:49:42




>> How hard is it to write a driver for a serial card you have very loose
>> specs for?  Does anybody out there have a model I can start from?
>I think that without a very _detailed_ understanding of the card it will be
>next to impossible to write a driver.  The driver is the part of the OS
>that is supposed to know how to talk to the hardware.  Without an
>understanding of the way memory is partioned for each port, the structure
>of each port, registers on the card, and how they react to various conditions
>the board will not behave in any expected way.  I have written many
>serial card drivers, on several different OS's, and each is very different
>in its own way.  Serial drivers are _very_ complex.  If you just want to be
>able to read and write raw data at a fixed baud rate and character size
>maybe you will be able to get something working, but once you start to
>handle all of the options available in the UNIX termio specification
>things can get quite hairy.  Termio specifies all the parameters that
>UNIX serial tty devices must be able to handle.  Things like baud rate,
>character size, parity checking, echo modes, canonical processing, output
>processing, CR-NL processing, special characters like interrupt, quit,
>and suspend, background/foreground and process group ioctls, etc, etc....

While I agree that serial I/O drivers are often the most difficult of
all to write, I should point out that in all but the most esoteric
implementations on smart I/O cards that the more difficult parts of
termio processing (canonical processing, CR-NL, signal handling etc.)
is done in line discipline routines that are already in the kernel.
The details of handling things like bits per character, baud rate are
usually pretty simple - you create a control word and just stuff it
into the right register (taking into account the various types
of "set" ioctls)

Serial drivers are fairly invariant across hardware types (except
with smart cards), and given a good source example for a specific
O/S, it should be easy to port it to a new card.

But, as you say, you need a *very* good specification of the hardware
to get anywhere.  Even the most trivial thing can take a long time
to figure out.

I have built serial drivers for various versions of UNIX (V7 thru
SVR3).  All the way from having to implement *everything* in the
driver, to situations where the driver is the easy part - the firmware
on the card (written in 80188 assembler yech!) did *all* of the termio
processing.  Getting it to behave exactly like other drivers was
quite a challenge.

Modem control?  Weeeelll, you have your work cut out for you!
--



 
 
 

Serial driver for multiport card

Post by Guy Harr » Fri, 25 Oct 1991 02:54:49


Quote:>Serial drivers are _very_ complex.  If you just want to be
>able to read and write raw data at a fixed baud rate and character size
>maybe you will be able to get something working, but once you start to
>handle all of the options available in the UNIX termio specification
>things can get quite hairy.

However, serial drivers rarely, if ever, have to *worry* about handling
all the options in "termio"; they normally leave that up to a line
discipline or STREAMS module.  For example, things like:

Quote:>...echo modes, canonical processing, output
>processing, CR-NL processing, special characters like interrupt, quit,
>and suspend, background/foreground and process group ioctls, etc, etc....

are all handled by the line discipline or STREAMS module, unless you
have some "smart" (and, hopefully, not "smart-ass") piece of serial port
hardware that can be told to do some or all of that processing (in which
case the driver might have to ask the line discipline or STREAMS module
to shut off some of its processing and let the hardware do it).  This
presumes that the hardware *should* be asked to do it; i.e., that it can
do a better job than the software can (which means, among other things,
that it doesn't do a half-assed job that takes as much work by the
software to fix up as would be required to do it all in software in the
first place).

Having the *driver* do that processing in *software* is most likely a
Bad Idea, as there should already *exist* software on the system to do
that, namely the line discipline or STREAMS module.

 
 
 

Serial driver for multiport card

Post by Jacques Gelin » Fri, 25 Oct 1991 13:28:18



Quote:> I have a multiport card from ITT called a MTS (Multiuser Terminal Subsystem)
> card.  The cards included drivers for an old version of SCO Xenix, but
> they don't have a driver for Unix.  The company no longer makes this
> product and I may not be able to get the source for a driver.

> How hard is it to write a driver for a serial card you have very loose
> specs for?  Does anybody out there have a model I can start from?

> Appreciate any help you can give me :-)

Maybe you should check the FAS driver. It does not support you card, but
it a nice serial driver. Adapting it to the peculiarity of the card
might not be too difficult. You will need at least some documentation
on how to intialise the hardware (interrupt, i/o mapping, etc). But it is
a good start (for 386 UNIX al least).

--

Today, it is my opinion.

 
 
 

Serial driver for multiport card

Post by Bruce Hi » Sat, 26 Oct 1991 02:58:03



> However, serial drivers rarely, if ever, have to *worry* about handling
> all the options in "termio"; they normally leave that up to a line
> discipline or STREAMS module.  For example, things like:

> >...echo modes, canonical processing, output
> >processing, CR-NL processing, special characters like interrupt, quit,
> >and suspend, background/foreground and process group ioctls, etc, etc....

STREAMS is the way to go _if_ it is available for your machine.  The drivers
that I wrote for our SBus cards under SunOS take full advantage of the
ldterm and ttcompat STREAMS modules.  And Sun has loadable drivers too!!!

However, the worst case scenario I was refering to would be something like
HP-UX.  No STREAMS available, and you have to rebuild the kernel and reboot
each time you want to test your driver. UGH.

--
Bruce T. Hill          Danford Corp.               voice: (213) 514-9334
Project Manager        350 W. 5th St.              FAX:   (213) 831-0454
uunet!dannet!bruce     San Pedro, CA 90731 USA

 
 
 

Serial driver for multiport card

Post by Guy Harr » Sun, 27 Oct 1991 02:42:22


Quote:>...to situations where the driver is the easy part - the firmware
>on the card (written in 80188 assembler yech!) did *all* of the termio
>processing.

I eagerly look forward to the supplier of that card's first experience
with the SVR4 terminal driver - the card ain't gonna do *all* of the
"termio(s)" processing, unless they anticipated the arrival of a bunch
of BSD-derived user interface features (correct implementation of ECHOE,
clearing the entire line on line kill, echoing control characters as ^x,
etc.)....
 
 
 

Serial driver for multiport card

Post by Matthias Urlic » Sun, 27 Oct 1991 22:34:00




< >...to situations where the driver is the easy part - the firmware
< >on the card (written in 80188 assembler yech!) did *all* of the termio
< >processing.
<
< I eagerly look forward to the supplier of that card's first experience
< with the SVR4 terminal driver - the card ain't gonna do *all* of the
< "termio(s)" processing, unless they anticipated the arrival of a bunch
< of BSD-derived user interface features (correct implementation of ECHOE,
< clearing the entire line on line kill, echoing control characters as ^x,
< etc.)....

Well, then you put the card into raw mode and let the Streams modules handle
the details. Nothing could possibly be easier. ;-)

--

Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

 
 
 

Serial driver for multiport card

Post by Chris Lew » Tue, 29 Oct 1991 01:34:41



>>...to situations where the driver is the easy part - the firmware
>>on the card (written in 80188 assembler yech!) did *all* of the termio
>>processing.
>I eagerly look forward to the supplier of that card's first experience
>with the SVR4 terminal driver - the card ain't gonna do *all* of the
>"termio(s)" processing, unless they anticipated the arrival of a bunch
>of BSD-derived user interface features (correct implementation of ECHOE,
>clearing the entire line on line kill, echoing control characters as ^x,
>etc.)....

No different than any other vendor of intelligent hardware.  They
would have had to work on the firmware and had a different version.
Big deal.  (Besides the card was really intended as a proprietary
add-in to our own machines)

On the other hand, the supplier has gotten out of the computer manufacturing
business, and now just buys and sells service companies, and sells cheap
"made in PRC" electronics to the Americans.

Nor do I work for them anymore.
--



 
 
 

Serial driver for multiport card

Post by Guy Harr » Sat, 02 Nov 1991 06:59:23


Quote:>However, the worst case scenario I was refering to would be something like
>HP-UX.  No STREAMS available,

So?  That *STILL* doesn't get to your worst-case scenario; unless HP-UX
doesn't even have line disciplines - in which case it'd be *MASSIVELY*
weird, because line disciplines have been around for *ages*, and have
been in *every* version of UNIX released by AT&T until the arrival of
the STREAMS-based tty driver - your serial port driver doesn't have to
do all the processing for all of the "termio" modules.  It just calls
the line discipline code and has it do most of the processing.
 
 
 

1. Multiport serial cards VS multiport USB hubs.

    I am considering starting up a small Internet Service Provider using a
Linux/Alpha based machine that has USB support. I was considering buying an
8 port serial card to hook up the dialin modems (haven't bought the modems
as yet). But the prices for multiport serial card hardware is quite
expensive compared to another alternative, multiport USB hubs.
Has anyone here setup up an ISP using USB hubs and USB modems?

2. hardware-raid

3. Device driver for the Decision PCCOM8 multiport serial card

4. fvwm window decorations inactive after running Netscape

5. Equinox SST Multiport Serial Card Drivers?

6. Intellimouse Trackball

7. Driver for SIIG multiport serial/parallel card

8. Gentoo 1.4-RC3 Live-CD: my review

9. Multiport serial ISA card Linux driver devlopment doubts

10. EXSYS PCI Multiport serial card driver ???

11. Multiport serial card drivers

12. Drivers for old multiport serial board

13. Stallion Multiport Serial Driver for Linux