Sign in

username:

password:



Not a member?

Search 68hc12



Search tips

Subscribe to 68hc12



68hc12 by Keywords

68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Ads

Discussion Groups

Discussion Groups | 68HC12 | 9S12DG256 Quadrature Encoder Support.

Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).

Re: 9S12DG256 Quadrature Encoder Support. - linktek - Jun 4 15:33:00 2003

Hi,

You can implement a simple "no missing states" QD using a 74XX74 D-type
latch. Feed sya a into D and input B into CLK and also to a interrupt pin
on your micro. Feed Q into a input pin on your micro. Connect PRE and CLR
on the 74XX74 to Vcc.

This way, with a interrupt you can pretty much examine the direction very
accuratly. Also pulse input will give you "length" count and pulse length
will give you "speed".

I implemented this on a ships main trawl warps for large fishing ships.The
net is attached on both end with 2 drums of cable, these cables works
syncronously. Just imagine the cable going out over a 1km length and when
hauled back in, it reads different lengths............"oops captain, I can
explain.......have you ever heard of quadrature encoding, eh?"

This implementation stood the test of time. With TIs little logic you can
buy a single tiny D-latch these days. All you still need is filtering.

Gogetit

Frank ----- Original Message -----
From: "John Dammeyer" <>
To: <>
Sent: Friday, June 04, 2004 11:47 AM
Subject: RE: [68HC12] 9S12DG256 Quadrature Encoder Support. > Hi William,
>
> Well written! And even doing all this with a Micro and interrupts means
that the maximum jitter or
> encoder speed can't exceed the entire interrupt routine latency.
>
> John >
> > -----Original Message-----
> > From: William M. Derby Jr. [mailto:]
> > Sent: Friday, June 04, 2004 11:30 AM
> > To:
> > Subject: Re: [68HC12] 9S12DG256 Quadrature Encoder Support.
> >
> >
> > The problem is that a valid "count" consists of a complete
> > sequence of A and
> > B pulses - you can't just take an arbitrary edge and be done
> > with it! There
> > are a bunch of pathological cases that real encoders produce
> > have that will
> > mess up the "simple" solution. (This would be the voice of
> > experience.)
> >
> > Consider an encoder sitting still -- well actually slightly
> > vibrating like
> > everything really does. You have a A and a B output which are
> > generally
> > produced by something blocking a light. Since the output is
> > mechanically
> > generated, you can easily have the start of a count pulse say
> > A -- then the
> > encoder direction reverses and A drops - -there is no B pulse at all!
> >
> > Valid Counts:::
> > A__---------______
> > B____---------____
> >
> > or in the other direction
> >
> > A____---------____
> > B__---------______
> >
> > Singleton, non- count events......
> >
> > A____---------____
> > B_______________
> >
> > or in the other direction
> >
> > A_______________
> > B____---------____
> >
> >
> > Of course you can get a zillion of these if the encoder is
> > just sitting on
> > the edge of a transition..
> > Depending on you implementation each one may show up as a
> > count! But wait
> > there's still more.
> > You can also get non-overlapped A-B pulses if the encoder
> > rotates little
> > further before backing up..
> > This will lead to:
> >
> > A __|-------------|_____
> > B_____------_________
> >
> > or in the other direction...
> >
> > A_____------_________
> > B __|-------------|_____
> >
> > There are other cases as well -- In short, there is a reason
> > for the special
> > encoder chips (like the
> > LSI7183, which I use) and others mentioned which take care of
> > these bizarre
> > cases. Also remember that the pulse width will decrease with
> > the speed of
> > the encoder.. In extreme (high speed) cases, the pulse width
> > will dip below
> > the "allowable" pulse width (300ns on the 7183) and be
> > considered noise and
> > thrown out! If your encoder moves really fast in one
> > direction and slow in
> > the other, the position will appear to back up, each time the machine
> > cycles!
> >
> > Bill
> >
> >
> > ----- Original Message -----
> > From: "Gary Olmstead" <>
> > To: <>
> > Sent: Friday, June 04, 2004 11:03 AM
> > Subject: RE: [68HC12] 9S12DG256 Quadrature Encoder Support.
> >
> >
> > > I'm not clear on what the big deal is. Two inputs, one
> > interrupt. At
> > > every (choose one) falling/rising edge, generate an interrupt which
> > > examines the level of the other input. One level
> > increments a counter,
> > the
> > > other level decrements the count. Shouldn't take long,
> > even at 20K Hz.
> > >
> > > And the problem is.....?
> > >
> > > Gary Olmstead
> > > Toucan Technology
> > > Ventura CA
> > >
> > >
> > > At 09:05 PM 5/31/04, you wrote:
> > > >John,
> > > >
> > > >I too have found this very annoying shortcoming on HC12
> > counters. The
> > > >320F24x is far nicer ;-)
> > > >
> > > >The only solution I have thought of, but not tested is to use a
> > > >PIC12C508 or ATtiny12 (I have code for the PIC) to decode
> > the quadrature
> > > >into count and direction. The outputs of this device are
> > > >up-clock/down-clock. Then feed these clocks to the alternate pulse
> > > >accumulators (PA and PB) on a 9S12D device. The pulse accumulator
> > > >difference is the current count. The tricky bit seems to
> > be that you
> > > >would need to reset these counters before they overflow
> > (no big deal),
> > > >but making the read-reset operation indivisible to the
> > external clock
> > > >may lead to lost counts.
> > > >
> > > >My application can require 10KHz to 20KHz counting, so
> > interrupts put a
> > > >very heavy load on the processor.
> > > >
> > > >I will be curious to know how you solve the problem.
> > >
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------To
> > learn more
> > about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > --------------------~-->
> > Yahoo! Domains - Claim yours for only $14.70
> > http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/dN_tlB/TM
> > --------------------------------------------------------------
> > ------~->
> >
> > --------------------------------------------------------To
> > learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
> --------------------------------------------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links





(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )


Re: 9S12DG256 Quadrature Encoder Support. - Author Unknown - Jun 4 17:35:00 2004

I have used the US Digital 7266 encoder chip... dual 24 bit counters
internally, hooks up on the 8 bit bus as a memory mapped peripheral. Check it out [Non-text portions of this message have been removed]




(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: 9S12DG256 Quadrature Encoder Support. - William M. Derby Jr. - Jun 7 10:13:00 2004

Hi,

(Regarding the D-flip-flop implementation)

I think Murphy invented encoders......

This is exactly the design I started with - and got burned bad! In my
singleton "B" example, you will get extraneous pulse counts from this
circuit. In this case, the encoder is riding on the "B" pulse rise
transition. As I said earlier, this problem comes up when you are sitting
still, and riding a transition edge so you may not have seen it if your
encoder resolution is coarse and you are generally moving -- in your
example, you may have not seen it if the drum was always moving one way or
the other - or if you don't look at the encoder when it isn't moving.. Then
again you may have seen it - once - but it never repeated so you ignored it.
The problem is that it follows from the physical design of standard encoders
that sooner or later they will produce one or all of these bizarre effects -
unless the physical design of the thing being measured prevents the problem.
(which may be the case for your drums -- or you may be..ahem.. "lucky" --
well captain, it worked for years..) The resolution of the encoder
magnifies the odds of the problem because the transitions occur more
frequently but the basic problem can/will occur on the coarsest of encoders
under the right conditions -- you just have to stop at just the right
spot.....

I didn't really cover all the bizarre sequences you can get but they all
revolve around the mechanical production of the pulses. There is no point in
the sequence where you can't suddenly stop and jitter back and forth over a
transition -- 3 out of 4 transitions are vulnerable - AND the sequence can
backup at any point in the sequence -- adding more transitions, then
reverse again, etc... Here are a few more nasty ones...

Rotating past A rise, into the B pulse, then backing up, then forward, back,
forward, etc..
(This riding the rising edge of B)

A: __|-------------------......
B: ____|--|__|--|__|--|__.. Rotating past A rise, through B rise and jittering on the Falling edge of
A..
(This riding the falling edge of A)

A: __|---------|__|--|__|--|__|----......
B: ____|--------------------------

(This will also generate a zillion counts in the above circuit when moving
in the opposite direction) In short - don't underestimate this as a problem when throwing in that
encoder interface..
- just because it hasn't happened yet doesn't mean it can't.
-Bill

----- Original Message -----
From: "linktek" <>
To: <>
Sent: Wednesday, June 04, 2003 4:33 PM
Subject: Re: [68HC12] 9S12DG256 Quadrature Encoder Support. > Hi,
>
> You can implement a simple "no missing states" QD using a 74XX74 D-type
> latch. Feed sya a into D and input B into CLK and also to a interrupt
pin
> on your micro. Feed Q into a input pin on your micro. Connect PRE and CLR
> on the 74XX74 to Vcc.
>
> This way, with a interrupt you can pretty much examine the direction very
> accuratly. Also pulse input will give you "length" count and pulse length
> will give you "speed".
>
> I implemented this on a ships main trawl warps for large fishing
ships.The
> net is attached on both end with 2 drums of cable, these cables works
> syncronously. Just imagine the cable going out over a 1km length and when
> hauled back in, it reads different lengths............"oops captain, I can
> explain.......have you ever heard of quadrature encoding, eh?"
>
> This implementation stood the test of time. With TIs little logic you can
> buy a single tiny D-latch these days. All you still need is filtering.
>
> Gogetit
>
> Frank > ----- Original Message -----
> From: "John Dammeyer" <>
> To: <>
> Sent: Friday, June 04, 2004 11:47 AM
> Subject: RE: [68HC12] 9S12DG256 Quadrature Encoder Support. > > Hi William,
> >
> > Well written! And even doing all this with a Micro and interrupts means
> that the maximum jitter or
> > encoder speed can't exceed the entire interrupt routine latency.
> >
> > John
> >
> >
> >
> > > -----Original Message-----
> > > From: William M. Derby Jr. [mailto:]
> > > Sent: Friday, June 04, 2004 11:30 AM
> > > To:
> > > Subject: Re: [68HC12] 9S12DG256 Quadrature Encoder Support.
> > >
> > >
> > > The problem is that a valid "count" consists of a complete
> > > sequence of A and
> > > B pulses - you can't just take an arbitrary edge and be done
> > > with it! There
> > > are a bunch of pathological cases that real encoders produce
> > > have that will
> > > mess up the "simple" solution. (This would be the voice of
> > > experience.)
> > >
> > > Consider an encoder sitting still -- well actually slightly
> > > vibrating like
> > > everything really does. You have a A and a B output which are
> > > generally
> > > produced by something blocking a light. Since the output is
> > > mechanically
> > > generated, you can easily have the start of a count pulse say
> > > A -- then the
> > > encoder direction reverses and A drops - -there is no B pulse at all!
> > >
> > > Valid Counts:::
> > > A__---------______
> > > B____---------____
> > >
> > > or in the other direction
> > >
> > > A____---------____
> > > B__---------______
> > >
> > > Singleton, non- count events......
> > >
> > > A____---------____
> > > B_______________
> > >
> > > or in the other direction
> > >
> > > A_______________
> > > B____---------____
> > >
> > >
> > > Of course you can get a zillion of these if the encoder is
> > > just sitting on
> > > the edge of a transition..
> > > Depending on you implementation each one may show up as a
> > > count! But wait
> > > there's still more.
> > > You can also get non-overlapped A-B pulses if the encoder
> > > rotates little
> > > further before backing up..
> > > This will lead to:
> > >
> > > A __|-------------|_____
> > > B_____------_________
> > >
> > > or in the other direction...
> > >
> > > A_____------_________
> > > B __|-------------|_____
> > >
> > > There are other cases as well -- In short, there is a reason
> > > for the special
> > > encoder chips (like the
> > > LSI7183, which I use) and others mentioned which take care of
> > > these bizarre
> > > cases. Also remember that the pulse width will decrease with
> > > the speed of
> > > the encoder.. In extreme (high speed) cases, the pulse width
> > > will dip below
> > > the "allowable" pulse width (300ns on the 7183) and be
> > > considered noise and
> > > thrown out! If your encoder moves really fast in one
> > > direction and slow in
> > > the other, the position will appear to back up, each time the machine
> > > cycles!
> > >
> > > Bill
> > >
> > >
> > > ----- Original Message -----
> > > From: "Gary Olmstead" <>
> > > To: <>
> > > Sent: Friday, June 04, 2004 11:03 AM
> > > Subject: RE: [68HC12] 9S12DG256 Quadrature Encoder Support.
> > >
> > >
> > > > I'm not clear on what the big deal is. Two inputs, one
> > > interrupt. At
> > > > every (choose one) falling/rising edge, generate an interrupt which
> > > > examines the level of the other input. One level
> > > increments a counter,
> > > the
> > > > other level decrements the count. Shouldn't take long,
> > > even at 20K Hz.
> > > >
> > > > And the problem is.....?
> > > >
> > > > Gary Olmstead
> > > > Toucan Technology
> > > > Ventura CA
> > > >
> > > >
> > > > At 09:05 PM 5/31/04, you wrote:
> > > > >John,
> > > > >
> > > > >I too have found this very annoying shortcoming on HC12
> > > counters. The
> > > > >320F24x is far nicer ;-)
> > > > >
> > > > >The only solution I have thought of, but not tested is to use a
> > > > >PIC12C508 or ATtiny12 (I have code for the PIC) to decode
> > > the quadrature
> > > > >into count and direction. The outputs of this device are
> > > > >up-clock/down-clock. Then feed these clocks to the alternate pulse
> > > > >accumulators (PA and PB) on a 9S12D device. The pulse accumulator
> > > > >difference is the current count. The tricky bit seems to
> > > be that you
> > > > >would need to reset these counters before they overflow
> > > (no big deal),
> > > > >but making the read-reset operation indivisible to the
> > > external clock
> > > > >may lead to lost counts.
> > > > >
> > > > >My application can require 10KHz to 20KHz counting, so
> > > interrupts put a
> > > > >very heavy load on the processor.
> > > > >
> > > > >I will be curious to know how you solve the problem.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------To
> > > learn more
> > > about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > > o learn more about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ------------------------ Yahoo! Groups Sponsor
> > > --------------------~-->
> > > Yahoo! Domains - Claim yours for only $14.70
> > > http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/dN_tlB/TM
> > > --------------------------------------------------------------
> > > ------~->
> > >
> > > --------------------------------------------------------To
> > > learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > --------------------------------------------------------To learn more
> about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
> --------------------------------------------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )