Date: Tue, 16 Mar 2004 09:34:04 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: freebsd-hackers@freebsd.org Subject: Re: How to write a new line discipline? Message-ID: <20040316083403.GA1258@cicely12.cicely.de> In-Reply-To: <200403161629.04021.doconnor@gsoft.com.au> References: <200403161629.04021.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 16, 2004 at 04:29:04PM +1030, Daniel O'Connor wrote: > Hi, > My company uses RS485 to talk to various pieces of hardware, and currently to > do this we have a hacked up copy of sio which talks to a conventional RS485 > card, while this works well it would be nicer to be able to use different 485 > cards via the puc driver instead of having to use a custom driver. Our custom > driver only understands 8250/16550/etc UARTS which is another limitation (not > currently an issue though :) > > It was suggested a while ago by phk (I think..) that a line discipline would > be the best approach, and I think this makes sense. The protocol in question > uses the parity bit as a 9th bit to signal an address byte (only 256 > addresses on this bus). I can't see how a line discipline can directly > control and read the parity information, and to set various control lines > (specifically RTS) to switch the transceiver into transmit mode when > necessary. Don't forget that there are chips (e.g. uftdi(4) based) that can control txenable themself without OS interaction. You can't expect the userland software to know. Using an USB RS232 Interface with an RTS controlled RS232-RS485 converter is unlikely to work in many cases for timing reasons. I needed half-duplex RS485 for modbus which fortunately is a 8 bit protocoll, but does addressing by using strict bus idle times. It was very tricky to do the timing good enough in userland. Currently I'm using uftdi(4) based chips, but I think the next generation will be a special kernel driver for self build modbus USB devices to allow interleaving support for higher throughput. I think other RS485 protocolls might be better with special non tty based kernel drivers too. uart(4) layering seems to be a good starter for connecting such a driver to various generic interfaces without loosing the ability to have protocoll specialized hardware. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040316083403.GA1258>