Date: Tue, 10 Oct 1995 11:25:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au Subject: Re: non-sio UART driver Message-ID: <199510101825.LAA10775@phaeton.artisoft.com> In-Reply-To: <199510101009.UAA15689@godzilla.zeta.org.au> from "Bruce Evans" at Oct 10, 95 08:09:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > As I dribbled a little while ago, I need to talk to a multidrop serial bus > >using a standard serial port. > > What's a multidrop serial bus? You know; like an Altos 2000. 8-). Basically, it uses an RS422 interface to talk to a box with multiple serial ports. The Altos and PrimeOS driver problem that these had was that there was a single input/output request queue per port -- just like VMS TTY I/O in VMS 4.2 and below. Basically, if you did a blocking read, subsequent operations, including writes, could not complete until the read completed. Quite bogus. Watch out for the single queue bug if you write/port a driver for the things. > >The nature of the protocol and interface mechanism for the bus tend to > >indicate to me that I don't want to use the sio driver and hack on that, > >but perhaps to make a copy and cut it severely down to size. > > If you need to do any normal serial i/o to a 16x50 then I suggest adding > to sio. It's not; it's a muxed 422/424 connection to multiple uarts in a fan-out box. Actually, it'd be fun to use the ports themslves as 1-2Mb/S serial interfaces without the fan-out units attached. 8-). > >Given this, how should I avoid the MCR_IENABLE conflict that's > >introduced by sioprobe() forcing the standard four ports' interrupts off? > > >(Perhaps just reenable interrupts on open?) > > That would work if the new device is probed after sio. This is probably the wrong way to probe it. > >Infact, given that this is really a packet-based network, would I be better > >of abandoning all of the tty interface gumpf in the sio driver and doing > >everything via ioctl() calls? (or something equally bogus?) > > If there are only protocol differences, then use a line discipline. Slip > and ppp are good examples. Yes. Integrate it as a serial interface with a different line discipline that means demux for the fan-out on the other end. Then probe it as if it were just another serial card. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510101825.LAA10775>