From owner-freebsd-hackers Wed Sep 24 01:40:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15630 for hackers-outgoing; Wed, 24 Sep 1997 01:40:23 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15624 for ; Wed, 24 Sep 1997 01:40:21 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA21456; Wed, 24 Sep 1997 01:15:32 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd021454; Wed Sep 24 08:15:26 1997 Date: Wed, 24 Sep 1997 01:34:25 -0700 (PDT) From: Julian Elischer To: "Jamil J. Weatherbee" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Raise your hand if you know how to make this work. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk there is a function to do this for you it's rather trivial. check clock.c and see how the PCAUDIO device uses this to get itself called 16000 times per second.. On Tue, 23 Sep 1997, Jamil J. Weatherbee wrote: > > Personally, I don't care how much processor overhead it takes. I simply > just want to be able to get a loop running at ~1000hz, because I've taken > a look at the technical manuals for some of the hardware I am using. > These boards can pass through an interupt on a rising edge to one of the > digital input lines. This makes me think I could hook it up to one of the > clocks on the included 8253 and make it generate a periodic interrupt (in > fact I am quite sure of this). However, this is not how the board was > intended to be used, it is designed as a polling device and if it was > connected to an dedicated computer that is probably precisely how I would > use it. What I refuse to believe is that freebsd is incapable of this > task, there are plenty of devices in the world that are by nature polling > type device even though this doesn't fit very well into the event driven > picture of things. You see, there is really no difference between me > making some physically external connections (and using another interrupt > line that could be utilized for something better) patching in a device > driver specifically for this purpose, or simply having a small piece of > user code with SIGALRM delivered on a more timely basis (e.g. setitimer() > that is more or less reliable to 1ms). I don't understand exactly why but > I know that for instance in Linux, Alphas generally have a scheduling > clock frequency of either 1 or 2khz (I'll have to check again) what Is so > wrong with x86 that it cannot do this also? > > >