DPRG List  

[DPRG] easter egg of sorts

Subject: [DPRG] easter egg of sorts
From: Randy M. Dumse rmd at newmicros.com
Date: Thu Dec 5 12:56:00 CST 2002

Sluggy, the historical reason behind the appeal of these LSI chips is
releaving the micros of the real time burden of tracking the phases on
the quadrature. Some of the chips they make have built-in counters, and
can be put on the micros, bus, and just read like a register. These
completely unload the burden of quadrature from the processor.

We made a board with a bunch of LSI quadrature chips like this (LS7166
iirc) about a dozen years ago for Mike Keesling of Panavision. Well, he
was at Clairemont Camera back then. Anyway, the chips work great.

The decoder chips you mention, are an important front end to a counter.
See their counters like the LS7160 with which they could be used. With
up counters, you need to have two counters, one counting up and one
counting down, and you get your position from the difference of the two.
The decoder chips are even better with an up/down counter. Also, there
are micros which have built-in counters up counters, and even some with
up/down counters, and the quadrature decoders can be used to feed these
hardware counters as well.

As far as using the micros you mention, if you only have one quadrature
to track, and the rates are slow, and the micros isn't burdened with
other task, as you suggest, its no biggy. It's just a bit easier to read
direction and count with a micro than it is to build a quadrature
statemachine to do it.

But when you have something like half a dozen different encoders in a
system like a camera, or a camera control arm, having quadrature in the
chips to use with hardware timers, particularly if the quadrature signal
gets up to the several megahertz range... well, that's nice.

At those frequencies (i.e. 16MHz), even if programmed in assembly
language, those micros you mentioned have no hope of following even one
encoder. On the other hand, if the encoder outputs are in the few
kilohertz range, it doesn't take much of a program to follow one.

On the other hand, with the advent of some of the new motion control
oriented micros, quadrature decoders may be built in.

Our IsoPod(TM) has two hardware 32-bit, 40 MHz capable, quadrature
decoders built right into the processor. No software required, no real
time burden, Just hook up and read the value. It's all there in
hardware. Also, the timers of the IsoPod(TM) can be configured to read
quadrature directly, so you can have 6 channels of 32-bit, 40 MHz
quadrature running into the IsoPod(TM) and them being read with no
software required but set up. After set up, just read the value out of
the timer register. If anyone want to see the setup code for that, ask,
I just wrote up the code day before yesterday.


> Off the top of my head, these chips seem kind of redundant.
> Connecting a
> quadrature encoder directly to a MCU requires two I/O lines.
> Using these
> chips would also require two I/O lines. All info needed for the clock
> multiplication is provided in the A&B channels, so nothing
> exotic there.
> I think the power would be that the MCU software might be marginally
> simpler using these chips, especially for systems based on
> BASICStamp or
> other comparitively low-MIPS chips. Not sure...
> Here's an example data sheet: http://www.lsicsi.com/pdfs/LS7083_84.pdf
> Another chip that might be more useful is a series of
> brushless DC motor
> controllers. Many of those really tiny motors we want to play
> with are
> brushless DC motors. Different models of chip provide drive for high
> side or low side driven FETs or bipolar transistors as needed.
> One of the chips is a single chip solution for complete
> control of one
> motor, controlling motor speed by a voltage input, providing braking,
> tachometer output, overcurrent sensing, etc.
> Here's an example chip data sheet:
> http://www.lsicsi.com/pdfs/LS7560_61.pdf
> Sluggy!
> --
> A friend will help you move.
> A really good friend will help you move a body.
> --
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist

More information about the DPRG mailing list