Jon Elson wrote:
> Chris Radek wrote:
>> On Sat, Aug 11, 2007 at 10:08:09PM -0500, Jon Elson wrote:
>>> Hmm, ppmc has an unscaled delta output, which is handy for
>>> tuning. If the canonical encoder interface has a velocity, then
>>> I should put this into the ppmc encoder function.
The software encoder counter generates its velocity output by
capturing time and position at each encoder count, and then
doing "velocity = (change in position) / (change in time).
That is a non-trivial change to any hardware encoder counter,
unless it already captures timestamps along with counts.
>> While you're in there, it would be also be nice if you could have an
>> x4-mode switch per encoder too. I ran into this when helping set up a
>> jog wheel on one of your encoder inputs (it counted 4 times per
>> click of the wheel). The x4 should default to on for compatibility.
> Gee, couldn't you just set the desired scale factor for this?
Yes, but that allows the jogwheel user to "tease" the wheel between
the detents and get four distinct steps. The x1 mode only counts
one time for each detent. (IMO x1 is ONLY interesting for jogwheels,
virtually every other application wants higher resolution, not lower.
> Or, you want the delta to be able to be scaled, too? Hmm, I'll
> have to see what the canonical encoder does.
Its not a scale factor - if it was I would agree with you that you
just change the scale. It literally only counts ONCE per full
quadrature cycle. That represents a hardware change, not just a
driver change. It is up to you whether you want to make that kind
of a change - obviously people who already have your board wouldn't
be able to benefit without replacing the PROM.