Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Jul 1999 11:23:42 -0700 (PDT)
From:      Julian Elischer <julian@whistle.com>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        Seigo Tanimura <tanimura@naklab.dnj.ynu.ac.jp>, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
Message-ID:  <Pine.BSF.3.95.990708112244.25198C-100000@current1.whistle.com>
In-Reply-To: <Pine.BSF.4.10.9907080952480.558-100000@salmon.nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
this is problematic.

you cannot add a new element before the pending firing because you can't
tell how far into the present trigger you are.


On Thu, 8 Jul 1999, Doug Rabson wrote:

> On Thu, 8 Jul 1999, Seigo Tanimura wrote:
> 
> > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT),
> >   Julian Elischer <julian@whistle.com> said:
> > 
> > julian> With your scheme the clock needs to be always running at elevated speed. 
> > julian> Possibly you might have a startup routine that turns on the elevated
> > julian> frequency, (basically does an 'aquire_timer0()' )  I would say that you
> > julian> would have more success in implementing your finetimer() by using
> > julian> "aquiretimer0" than the other way around. 
> > 
> > I agree that acquire_timer0() would give more freedom to the ticks
> > to callout. Then I tried figuring out how to manage multiple
> > callouts using acquire_timer0(), which is something like below.
> > 
> > 
> > Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as
> > the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and
> > c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing
> > though the queue to update the time tags on the callouts.
> > 
> > (footnote: I'd better write in TeX :-<)
> > 
> > Queueing a new callout c' to be made in t' involves a problem to find the
> > maximum j (which is an integer, j >= 0) satisfying a constraint
> > 
> > 	t' > \sum_(k=0)^(j) dt_rem(c_k)
> > 
> > where the right hand side of the inequality is the time span after which
> > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1))
> > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0).
> > 
> > In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then
> > acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is
> > the difference of callout times, so they need not be updated on every clkintr().
> > 
> > 
> > Although the computational cost in clkintr() is generaly O(1), the queueing cost
> > is O(I). Not sure whether we can reduce it or not (will it really make a trouble?)
> > 
> > 
> > How does it sound?
> 
> If I understand this correctly, you are suggesting that we program timer0
> so that we only take interrupts when a finetimer is due to fire? If so,
> then it sounds very good. The idea of taking 6000+ interrupts/sec made me
> uneasy, even though most would return without doing any work.
> 
> --
> Doug Rabson				Mail:  dfr@nlsystems.com
> Nonlinear Systems Ltd.			Phone: +44 181 442 9037
> 
> 
> 



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?Pine.BSF.3.95.990708112244.25198C-100000>