Date: Thu, 16 Mar 1995 13:07:59 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: terry@cs.weber.edu (Terry Lambert) Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: Splicing in a new serial line protocol Message-ID: <199503161807.NAA04729@hda.com> In-Reply-To: <9503161742.AA23644@cs.weber.edu> from "Terry Lambert" at Mar 16, 95 10:42:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > > Would anyone care to comment on where to splice in a new serial line > > protocol? I haven't looked at the code at all yet; I plan on looking > > later on today. > > Ha! I recognize this protocol... can't quite place what equipment it > goes with though; are you perhaps doing blood gas analysis? It is similar to many protocols. For a blood gas analzer you are probably thinking of the ASTM protocol which is the basis for a lot of laboratory anlysis systems. This protocol is home grown and is most similar to the link level of SECS (semi equipment communication standards). It is used to communicate to the firmware we've developed for a few instruments. > > The place I'd implement it would be in a user mode process and not in > the kernel at all -- everything that you do in terms of line bidding, > etc. is on the basis of in-band data only. Since there is no need > for detailed control of line signals, a user space process is more > than adequate, and better for file I/O for storing it off. That will give you a pretty nasty latency in bidding for the line. The user process is going to have to take the ENQ and send back the EOT. With a kernel driver a single receive interrupt with the ENQ and we'll grant the line. With four lines sending small packets there would be pretty big process load handling the bidding protocol, and that seems like a natural for in the kernel. I also like the way the kernel could mux and demux the streams as separate devices without a filter to specify the stream, though I suppose there is no real advantage: > echo "set mode 3" > /dev/stream3 versus > echo "set mode 3" | stream 3 /dev/streams Likewise for receiving - demuxing the streams would need a single demux process receiving the data and sending to processes waiting for info. Somehow a device looks cleaner. The protocol is implemented as an interrupt state machine and the user process would never have to be activated until a full frame was received and validated. I was just looking at the "tablet" line discipline as a starting point to add this as a new line discipline. But you may be right. I'll think a little more. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503161807.NAA04729>