Date: Wed, 19 Aug 1998 05:39:59 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: kpielorz@tdx.co.uk (Karl Pielorz) Cc: julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: High? Latency device-driver with no IRQ's? Message-ID: <199808190939.FAA08692@hda.hda.com> In-Reply-To: <35DA1EDB.5D0E324F@tdx.co.uk> from Karl Pielorz at "Aug 19, 98 01:39:55 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> This is the simplest mode the driver will run in. The card does support DMA - > but I'm only just starting out writing drivers etc. at the moment, so I'd > planned to 'keep it simple' for the first version - Hence I'm looking for the > best way to handle the above... > > Someone here has suggest I move all the hanging around to userland, and either > get the user process to wait 10us between reads, or provide some sort of ioctl > interface for polling whether the next sample is ready... The user process can't wait 10us so that won't get you anywhere. Since DELAY will keep the processor busy anyway you may as well poll that ready bit instead of "DELAY(10); poll_ready();". At 10 KHz you could get by with a fast interrupt scheme similar to what I think we have in SIO. Essentially you implement a FIFO in software with a low overhead interrupt stuffing in the FIFO and waking up the kernel part of your blocked user process when you've filled a buffer. Since I assume the data will come in continuously, you have to be prepared to put the data someplace when there is no user process reading. Then if you "dd if=/dev/daqb0 bs=100" you'll only get the heavy duty kernel work done every 50 transactions. This is all for informational purposes, since at the 100 KHz you're talking about you are going to have to make the DMA work because you just aren't going to be able to service that board every 10 us - some other driver is going to be doing your DELAY(30) configuration change and locking you out, etc. Note that you still have to concern yourself with where to put the incoming data when no read is in progress. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808190939.FAA08692>