Engineering Department wrote:
>
> > From: Bob Fehrenbach
>
> <Describes linear method to go faster the longer a button is held>
>
> > The problem with this approach is that, even after juggling min_period,
> > max_period and delta, I have never arrived at a combination that "felt
> > good".  While I understand that this is a subjective call, I am
> > curious how others handle this problem and what they though of their
> > results.  It would seem that there is a better way.
>
> Bob,
>
> It may be that a linear ramp to a faster incrementing rate
> just doesn't fit your expectations.  I ended up using
> a log scheme for ramping the rate when I wrote some
> 8088 code that let the user scroll through *lots* of
> text.  Users seemed to like that.
>
> However, that sort of sillyness is out of the question
> on a PIC if you are squeezed for clock cycles or space.

Silly Logarithms on a cycle-starved PIC? Hmmm, check out:

http://www.interstice.com/~sdattalo/technical/software/pic/piclog.html

At 103 cycles worst case it's not too unreasonable.

> Perhaps you could double the rate every so often
> to get somewhat the same effect, or maybe make
> a small table of rates.

But are you talking about logarithms or powers now? The table solution
seems like a very reasonable approach. So far those of you who
have suggested this accelerating repeat rate have only mentioned
the time constant associated with the initial key press. However,
I would think that a time constant associated with the key release
would be useful too. This way if you release the key some where in
the middle and decide to back space or press the same key again then
you wouldn't have to wait for the repeating to take affect. The
same table could be used for the key press and for the release.

Scott