EmbeddedRelated.com
Forums

Incremental rotary sensor (motor) as input to HCS12

Started by Marek Peca April 4, 2005
Dear colleagues,

I'd like to use HCS12 in one application, where the user input will
be from discrete incremental rotary sensor (in fact, HDD motor with
appropriate shaping amplifiers). It gives two logical signals, which
are phase shifted (if driven by constant velocity, shift is 90deg.):

A: 000011110000111100001111
B: 001111000011110000111100

For the maximal efficiency, it is needed to inform CPU about all
edges, ie. both falling and rising edge of both signals.

I think, that in HCS12 I could solve it be connecting both signals to
IRQ input lines (eg. port J) and when interrupt happens, to switch
active edge in port register. Is this clean solution? If you have
better idea, please, tell me. Thanks,
Marek P.


How fast does the motor turn? This will let us compute how fast the edge
interrupts arrive. What resolution do you need (in ch A pulses per rev). You can
get 4 times this by using both edges, but I'd get it working in 1x mode first
just to keep my hair from getting grayer too fast.



Or, you could connect each phase of the quadrature encoder to 2 input
lines, one programmed for a rising edge interrupt, the other for a
falling edge interrupt.

The actual encoder line count versus frequency will be very critical
if you are using this interrupt technique. Keep in mind that the
interrupt rate will be 4x the actual line count rate. If the encoder
spins fast enough, the interrupts will get too close together and the
system will saturate.

Save yourself a lot of problems by using a LS7083 decoder chip like
this, with the up and down clocks connected to 2 timer pulse
accumulators. The effective encoder count will be 1 pulse
accumulator count minus the other. This simple hardware approach
puts almost zero load on the system software, versus an overwhelming
load if you use interrupts.

http://www.usdigital.com/products/ls7083-84/

Bill T.
http://www.kupercontrols.com --- In 68HC12@68HC..., Marek Peca <marek@t...> wrote:
> Dear colleagues,
>
> I'd like to use HCS12 in one application, where the user input will
> be from discrete incremental rotary sensor (in fact, HDD motor with
> appropriate shaping amplifiers). It gives two logical signals, which
> are phase shifted (if driven by constant velocity, shift is 90deg.):
>
> A: 000011110000111100001111
> B: 001111000011110000111100
>
> For the maximal efficiency, it is needed to inform CPU about all
> edges, ie. both falling and rising edge of both signals.
>
> I think, that in HCS12 I could solve it be connecting both signals
to
> IRQ input lines (eg. port J) and when interrupt happens, to switch
> active edge in port register. Is this clean solution? If you have
> better idea, please, tell me. > Thanks,
> Marek P.



Hello,

> How fast does the motor turn? This will let us compute how fast the edge
> interrupts arrive. What resolution do you need (in ch A pulses per rev). You can
> get 4 times this by using both edges, but I'd get it working in 1x mode first
> just to keep my hair from getting grayer too fast.

I don't know exactly the number of motor poles. It's rotated by hand.
Of course I'd like to use this 4x faster design with using both
edges.

I only asked, if it is clean solution to swap in interrupt routine
bit, which determines, for which edge this interrupt line waits.
Or if there is some better solution for the HCS12.
(Of course this differ among other MCU's...)

Thanks,
MP


Thank you for your detiled response.

LS7083 looks fine, thank you for the link. In my application, the
frequency will be low (under 100Hz, I guess) and system will be very
little loaded. But anyway thanks a lot.

I think, it is better to swith IRQ line by software than to use 2
more of them :-).

Have a nice time,
Marek P.

On Mon, 4 Apr 2005, tonalbuilder2002 wrote:

>
>
> Or, you could connect each phase of the quadrature encoder to 2 input
> lines, one programmed for a rising edge interrupt, the other for a
> falling edge interrupt.
>
> The actual encoder line count versus frequency will be very critical
> if you are using this interrupt technique. Keep in mind that the
> interrupt rate will be 4x the actual line count rate. If the encoder
> spins fast enough, the interrupts will get too close together and the
> system will saturate.
>
> Save yourself a lot of problems by using a LS7083 decoder chip like
> this, with the up and down clocks connected to 2 timer pulse
> accumulators. The effective encoder count will be 1 pulse
> accumulator count minus the other. This simple hardware approach
> puts almost zero load on the system software, versus an overwhelming
> load if you use interrupts.
>
> http://www.usdigital.com/products/ls7083-84/
>
> Bill T.
> http://www.kupercontrols.com > --- In 68HC12@68HC..., Marek Peca <marek@t...> wrote:
> > Dear colleagues,
> >
> > I'd like to use HCS12 in one application, where the user input will
> > be from discrete incremental rotary sensor (in fact, HDD motor with
> > appropriate shaping amplifiers). It gives two logical signals, which
> > are phase shifted (if driven by constant velocity, shift is 90deg.):
> >
> > A: 000011110000111100001111
> > B: 001111000011110000111100
> >
> > For the maximal efficiency, it is needed to inform CPU about all
> > edges, ie. both falling and rising edge of both signals.
> >
> > I think, that in HCS12 I could solve it be connecting both signals
> to
> > IRQ input lines (eg. port J) and when interrupt happens, to switch
> > active edge in port register. Is this clean solution? If you have
> > better idea, please, tell me.
> >
> >
> > Thanks,
> > Marek P. >
> Yahoo! Groups Links >
>




I used two timer input capture pins set for any edge. A static var must
be maintained to inform the isr of one the current state of the other. I
used this method successfully with a fuzzy pid with no missed events.

Incidentally I tried my hand at this using a CPLD without a clock - what a
nightmare.

Rob
>
>
> Dear colleagues,
>
> I'd like to use HCS12 in one application, where the user input will be
from discrete incremental rotary sensor (in fact, HDD motor with
appropriate shaping amplifiers). It gives two logical signals, which are
phase shifted (if driven by constant velocity, shift is 90deg.):
>
> A: 000011110000111100001111
> B: 001111000011110000111100
>
> For the maximal efficiency, it is needed to inform CPU about all edges,
ie. both falling and rising edge of both signals.
>
> I think, that in HCS12 I could solve it be connecting both signals to
IRQ input lines (eg. port J) and when interrupt happens, to switch
active edge in port register. Is this clean solution? If you have better
idea, please, tell me.
>
>
> Thanks,
> Marek P. >
>
> Yahoo! Groups Links
>
> To >



> I used two timer input capture pins set for any edge. A static var must
> be maintained to inform the isr of one the current state of the other. I
> used this method successfully with a fuzzy pid with no missed events.

Wow, it is possible to configure timer capture input to wait for both
edges? I must look better to docs... Well, this is exactly, what I
wanted to hear, thank you.

> Incidentally I tried my hand at this using a CPLD without a clock - what a
> nightmare.

Hmmm, asynchronous automats are great. But well, they can easily
become someone's nightmare ;-).

Regards,
Marek P.


The simplest way I have come up with is a single IRQ on one line, and a
standard I/O on the other. Since a rotary dial when turned always goes
through 4 states per detent, this is very easy to accomplish.
As soon as the edge-interrupt hits, sample the I/O on the other line 16
times in quick succession, figure out if the 16 results of a high pin state
are above 12 to see what direction it was heading (arbitrary value can be
tweaked). Once you have determined the direction, you can push the event
onto a rotating buffer like keyboard events. Then disable the edge interrupt
(before you clear the flags) until a bounce time-out, usually handled by a
regular timer interrupt. 2-25mS is typical. You don't need to stay in the
edge interrupt very long, just long enough to poll the I/O pin 16 times so
it is very computationally light. You can reduce this count but it will
increase the chances of a backwards hit, but it all depends on the
mechanical nature of your device.
Bounces in these devices are horrific, especially with a heavy dial
attached, and are typically the limiting factor in how fast you can
interpret a detent occurrence. The timer that re-enables the edge interrupt
needs to have about 1.5x the maximum time you observe on a scope the
bouncing on the lines to assure proper direction detection.
I have tried several different methods of using these things, and this
method is probably the least intensive, and most reliable.
Another thing this allows is accelerations. The timer interrupt can
determine the time space between dial hits and calculate a multiplier to be
used.
-Mark
_____

From: Marek Peca [mailto:marek@mare...]
Sent: Monday, April 04, 2005 11:35 AM
To: 68HC12@68HC...
Subject: [68HC12] Incremental rotary sensor (motor) as input to HCS12
Dear colleagues,

I'd like to use HCS12 in one application, where the user input will
be from discrete incremental rotary sensor (in fact, HDD motor with
appropriate shaping amplifiers). It gives two logical signals, which
are phase shifted (if driven by constant velocity, shift is 90deg.):

A: 000011110000111100001111
B: 001111000011110000111100

For the maximal efficiency, it is needed to inform CPU about all
edges, ie. both falling and rising edge of both signals.

I think, that in HCS12 I could solve it be connecting both signals to
IRQ input lines (eg. port J) and when interrupt happens, to switch
active edge in port register. Is this clean solution? If you have
better idea, please, tell me. Thanks,
Marek P.

_____

> Terms of Service.


Mark, your system may be solid for your requirements but it is too slow
for high rpm.

My isrs execute <2usec (24MHz eclk) and compute count on every transition.
Depending on app and motor speeds the interrupt overhead may force
offloading to a co-pro. Motorola architected it's fuzzy instructions to
be interruptable so my pid and encoder isrs work very well together for my
brushed servo motors. Regards,
Rob



Ahh, that is fast. I would assume this is probably an optical device rather
than mechanical so that bouncing may not be an issue. If that is the case
then you do not need the external timer interrupt to re-enable the interrupt
after a delay, and you don't need to poll the pin either to discriminate a
bounce from a state.
If you don't need 4x the resolution that monitoring all four edges would
give you, the single interrupt and I/O would still work, you just wouldn't
need to poll the I/O pin.
VERY simple.
IRQVECTOR:

;You could branch depending on
edge selection here for 2x resolution

;In that case the I/O pin will be
inverted for the same event.

brset OPTO1,porta,OPTO_HIGH ;Heading CCW

. Queue commands/event ;Heading CW

bra OPTO_COMPLETE

OPTO_HIGH:

. Queue commands/event

OPTO_COMPLETE:

rti
_____

From: robmilne@robm... [mailto:robmilne@robm...]
Sent: Monday, April 04, 2005 2:24 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Incremental rotary sensor (motor) as input to HCS12
Mark, your system may be solid for your requirements but it is too slow
for high rpm.

My isrs execute <2usec (24MHz eclk) and compute count on every transition.
Depending on app and motor speeds the interrupt overhead may force
offloading to a co-pro. Motorola architected it's fuzzy instructions to
be interruptable so my pid and encoder isrs work very well together for my
brushed servo motors. Regards,
Rob
_____

> Terms of Service.