On Monday 01 May 2006 08:42 pm, rtstofer wrote:
--- In Electronics_101@..., "Roy J. Tellason"
<rtellason@...> wrote:
On Monday 01 May 2006 12:48 pm, Stefan Trethan wrote:
On Mon, 01 May 2006 18:39:33 +0200, rtstofer <rstofer@...> wrote:
Among other things, if you build a software state machine to track the
changes, debouncing will be automatic. Sure, you may bobble between A
is high, B is high back and forth with A is low, B is high (or A is
high, B is low) (in other words both sides of the transition) but it
doesn't matter because only one line is changing states - you wont go
from A is high, B is high to A is low, B is low.
You aren't transitioning far enough to upset the count or miss a
detent position. But you can detect the difference between increase
and decrease.
Yes, even I managed to make the software for a encoder of this type
work, and that says something!
Good thinking really that quadrature stuff...
Yes...
What platform did you make that software for?
You may find the code in avrlib useful in designing this type of
interface:
Rather than downloading the whole mess, which would be a bit slow on dialup,
I went to the online html documentation link, and selected encoder.c and
encoder.h and downloaded the documentation and source pages for both of
those. I hope that's what you were referring to. :-) The encoder.h source
in particular has a nice explanation in there showing waveforms and such, and
explains just how it is that they deal with processing the inputs from the
device.
I know nothing at all about these processor chips, but I can read c well
enough to see what they're doing there, which is pretty nifty from what I
see so far.
The avrlib implementation is fully interrupt driven from both input
phases and works on a variety of AVR devices. It is written in C.
Depending on the size of the AVR device, more than one encoder can be
connected.
That's interesting too -- would that depend on how many interrupt inputs you
had available or how fast the chip in question could handle one and therefore
be likely to be able to deal with more than one?
I know *nothing* about these parts -- is there any place in particular where
you could point me to that would get me going? I'm familiar with a bunch of
way earlier chips, stuff like the 8080, 8085, z80, 68xx, 65xx, and similar,
but just haven't kept up. (Like I *really* need another thing on my plate,
which is already pretty full. :-)
That said, the overall state transitions can be coded in any language
but the idea of using interrupt inputs is a good one. It is not
possible to determine when a phase change may occur.
Yeah, I looked at that bit in the header file and it made immediate sense to
me. Not a bad approach at all. I'll have to look it over and study it in
some detail and see how they're handling the rest of it besides the input...
I don't always use avrlib but I have been know to parphrase the code.
Even convert it to an ARM processor.
I don't know about those, either.
A while back I thought that maybe I oughta start catching up on this newer
stuff. So I subscribed to the piclist. But there was way too much OT stuff
in there even after I'd supposedly configured their end to not send me all
that stuff... So I gave up on that list. Maybe one of these days I'll run
across a better (more focused) source of info.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
