Date: Tue, 11 Nov 1997 19:55:18 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Cc: hackers@freebsd.org Subject: Re: LabPC+ Driver Specifics Message-ID: <199711120055.TAA00327@hda.hda.com> In-Reply-To: <Pine.BSF.3.96.971111135016.353A-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at "Nov 11, 97 02:02:32 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Can you possibly take a glance at my source in a few days? Yes. > > There is only one clock on that board. > > does that mean if you say set AD_MICRO_PERIOD = 10000 and you are reading > from 4 of the 8 channels then really each channel is only getting 25 > readings per second. (I can't remember of the labpc if internally > multiplexed like my board) The board has a single A-D converter connected to a mux. It has a scanning mode where it will scan through sequential channels from 0 to the selected channel encoded in the minor number. It has a single gain selection for all channels. Each tick of the clock will convert the next channel and clock it into the board FIFO. In my experience, a general data acq interface should be frame (another term is record) based, where you can specify a channel list, a gain list, a trigger specification, and a sampling specification. Channel and gain lists are common and set the specifics for each channel (The LabPC is restrictive in that there is a single gain for all channels and the channel list can only be 0...N, where N is one of the channels). The trigger specification states when to start the frame (or record) collection process. This is typically immediately on read, via an external TTL input, via a timer, or dependant on the data. The sampling specification states the details of the time between samples and is typically either an external input or an inter-sample timer. More complicated specifications such as you present (i.e., setting different per-channel sample rates) should be handled as separate devices even when implemented in a single driver. > > If you have (or are implementing) independent clocks you probably have > > (or are implementing) independent FIFOs or other memory channels > > and you should handle it as separate instances of the driver, i.e., > > as if each is a separate board. > > Not possible (there is only one clock) and any drivers would have to be > cooperating with each other You should have a single driver implementing multiple devices. You would treat part of your driver as the firmware of a virtual board where you design as if that piece can be pushed off on a dedicated microcontroller. This part should be fast, low overhead, and a candidate for execution at an elevated priority level. It would do little other than demux your data into software FIFOs and implement the timing strategy. > So data acquisiton doesn't start on a labpc channel until the _first_ > read, then it is continuous until closing? Until closing or until an error such as FIFO overrun. > I was going to have my channels when open not spew any data. > when you ioctl() AD_START they start to read at the MICRO_PERIOD rate. > when you AD_STOP they stop spewing. Of course if each has its own virtual > clock this might not be neccessary. > That was my problem in a multiplexed system say you have 3 channels open. > > channel 1 wants 10hz signal > channel 2 wants 20hz signal > channel 3 wants 30hz signal > > then for me you have to do some pretty fancy scheduling stuff and run the > 8253 at 60 hz having it go through a scheduling list on each interrupt of > which channel to read. This particular example is easy, and any example which is a multiple of a base clock rate will be easy, either by using "skip counters" or a callout table (ordered list of expired timers as used in the kernel timeout). You are right in that in general this can't be done properly especially if you need temporaly clean data. I'd prefer this to be three separate devices where your driver demuxes these channels - I don't want to sort that out in software, I'd rather open channel 1 set to 10 Hz, open channel 2 set to 2 Hz, etc. > Can you explain what the concept of frame means to you in this context? By a frame I mean a record of data described using the ioctl calls we discussed earlier. For example, three channels at 500 Hz and four other channels at 60 Hz are two frames at different frame rates. Whether or not these frames can be supported by a single piece of hardware are an issue of the hardware and software design. > I fear that the labpc can get 8 readings on one interrupt ... The LabPC will get a single DONE interrupt after a counter expires. That counter is set based on the size of the read. I punt as much control as possible back to the application programmer. > wheras I really > only have one port but it is double multiplexed (reading is the two step > process of setting a multilplexer address, and letting that settle for 1 > click then (thus the external multiplexer signal) then starting a > conversion going a click (always more than the 30microsecond conversion > time) and reading the result. Starting the conversion would be a good candidate for moving into your hardware so that the conversion begins after a timer expires that is started by the mux write. > if I want 48 channels at 10 samples/sec each my clock rate is 960hz Using my terminology you have a channel list of 48 channels with an immediate trigger (start ASAP) and a sample spec of 960 Hz. Though it may put a nasty, bursty load on the system, someone will reasonably want the same 48 channels sampled as close together as they can at the 10 Hz rate. Then you have a clocked trigger set at 10 Hz and a sample spec of "as fast as the hardware can do it". You can see how with a mux settle timer, an interval timer and a simple counter you could implement that same sequential scan that the LabPC has and move that part out of the driver. I'm not saying you should do that but that you should structure your software with that in mind. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711120055.TAA00327>