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

Hi,

I'm trying to count pulses from wheel encoder. I'm using ICC12 and
MC9S12DP256. The problem I'm having is that the result (PANC1) does
not make any sense. The number are not in sequence.(ex. 179, 254, 18...)
here is my code, Please help.

#include
#include

void initialize(void);

void main(void){
initialize();
while (1){
printf(" %u \r",PACN1);
}
}

void initialize(){
DDRT = 0x00; /* configure all timer port pins for input */
TCTL4 = 0x04;
ICPAR = 0x02; //set PACN1 to count W.E
}



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

Without looking too into depth on this, I would take a wild guess that the
pulses are overflowing faster than printf() can put them out. Try converting
the register yourself to a set of characters directly which will improve
performance, and you may see what you expect. Printf() is notoriously
resource hungry.

-Mark

_____

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
y...@pacbell.net
Sent: Thursday, November 16, 2006 3:05 PM
To: 6...@yahoogroups.com
Subject: [68HC12] Pulse accumulator 9sdp256

Hi,

I'm trying to count pulses from wheel encoder. I'm using ICC12 and
MC9S12DP256. The problem I'm having is that the result (PANC1) does
not make any sense. The number are not in sequence.(ex. 179, 254, 18...)
here is my code, Please help.

#include
#include

void initialize(void);

void main(void){
initialize();
while (1){
printf(" %u \r",PACN1);
}
}

void initialize(){
DDRT = 0x00; /* configure all timer port pins for input */
TCTL4 = 0x04;
ICPAR = 0x02; //set PACN1 to count W.E
}

[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 )

--- In 6...@yahoogroups.com, "Mark Wyman" wrote:
>
> Without looking too into depth on this, I would take a wild guess
that the
> pulses are overflowing faster than printf() can put them out. Try
converting
> the register yourself to a set of characters directly which will improve
> performance, and you may see what you expect. Printf() is notoriously
> resource hungry.
>
>
>
> -Mark
>
>
>
> _____
>
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On
Behalf Of
> yklein@...
> Sent: Thursday, November 16, 2006 3:05 PM
> To: 6...@yahoogroups.com
> Subject: [68HC12] Pulse accumulator 9sdp256
>
>
>
> Hi,
>
> I'm trying to count pulses from wheel encoder. I'm using ICC12 and
> MC9S12DP256. The problem I'm having is that the result (PANC1) does
> not make any sense. The number are not in sequence.(ex. 179, 254, 18...)
> here is my code, Please help.
>
> #include
> #include void initialize(void);
>
> void main(void){
> initialize();
> while (1){
> printf(" %u \r",PACN1);
> }
> }
>
> void initialize(){
> DDRT = 0x00; /* configure all timer port pins for input */
> TCTL4 = 0x04;
> ICPAR = 0x02; //set PACN1 to count W.E
> }
>
>
>
> [Non-text portions of this message have been removed]
>
Hi Mark,

I didn't know that, but the speed of the pulses is very slow, 1sec so
the printf will have enough time. Can it be that what I'm seeing is
the time between pulses?

Yuval



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

Another possibility is bounce.

During the transition of your wheel sensor, there may be a lot more edge
occurrences than you expect, so rather than a single count as expected, you
may be getting hundreds of them. You may have to write code to "filter out"
the higher frequency event noise. Use can use a timer interrupt to clear a
mask flag which is set by the wheel interrupt which prevents a count
increment in your accumulator. The first instance of the interrupt when the
mask flag is set is the only one that increments your accumulator. Each
successive interrupt from the wheel resets the timer countdown back to some
countdown value (filter coefficient), so if the timer hasn't had a chance to
clear the flag yet (timer not down to zero) this is desirable to filter
these edges.

-Mark

_____

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
yklein2004
Sent: Saturday, November 18, 2006 4:26 PM
To: 6...@yahoogroups.com
Subject: [68HC12] Re: Pulse accumulator 9sdp256

--- In 68HC12@yahoogroups. com, "Mark
Wyman" wrote:
>
> Without looking too into depth on this, I would take a wild guess
that the
> pulses are overflowing faster than printf() can put them out. Try
converting
> the register yourself to a set of characters directly which will improve
> performance, and you may see what you expect. Printf() is notoriously
> resource hungry.
>
> -Mark
>
> _____
>
> From: 68HC12@yahoogroups. com
[mailto:68HC12@yahoogroups. com] On
Behalf Of
> yklein@...
> Sent: Thursday, November 16, 2006 3:05 PM
> To: 68hc12@yahoogroups. com
> Subject: [68HC12] Pulse accumulator 9sdp256
>
> Hi,
>
> I'm trying to count pulses from wheel encoder. I'm using ICC12 and
> MC9S12DP256. The problem I'm having is that the result (PANC1) does
> not make any sense. The number are not in sequence.(ex. 179, 254, 18...)
> here is my code, Please help.
>
> #include
> #include void initialize(void);
>
> void main(void){
> initialize();
> while (1){
> printf(" %u \r",PACN1);
> }
> }
>
> void initialize(){
> DDRT = 0x00; /* configure all timer port pins for input */
> TCTL4 = 0x04;
> ICPAR = 0x02; //set PACN1 to count W.E
> }
>
> [Non-text portions of this message have been removed]
>
Hi Mark,

I didn't know that, but the speed of the pulses is very slow, 1sec so
the printf will have enough time. Can it be that what I'm seeing is
the time between pulses?

Yuval

[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 )

--- In 6...@yahoogroups.com, "Mark Wyman" wrote:
>
> Another possibility is bounce.
>
>
>
> During the transition of your wheel sensor, there may be a lot more edge
> occurrences than you expect, so rather than a single count as
expected, you
> may be getting hundreds of them. You may have to write code to
"filter out"
> the higher frequency event noise. Use can use a timer interrupt to
clear a
> mask flag which is set by the wheel interrupt which prevents a count
> increment in your accumulator. The first instance of the interrupt
when the
> mask flag is set is the only one that increments your accumulator. Each
> successive interrupt from the wheel resets the timer countdown back
to some
> countdown value (filter coefficient), so if the timer hasn't had a
chance to
> clear the flag yet (timer not down to zero) this is desirable to filter
> these edges.
>
>
>
> -Mark
>
>
>
> _____
>
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On
Behalf Of
> yklein2004
> Sent: Saturday, November 18, 2006 4:26 PM
> To: 6...@yahoogroups.com
> Subject: [68HC12] Re: Pulse accumulator 9sdp256
>
>
>
> --- In 68HC12@yahoogroups. com, "Mark
> Wyman" wrote:
> >
> > Without looking too into depth on this, I would take a wild guess
> that the
> > pulses are overflowing faster than printf() can put them out. Try
> converting
> > the register yourself to a set of characters directly which will
improve
> > performance, and you may see what you expect. Printf() is notoriously
> > resource hungry.
> >
> >
> >
> > -Mark
> >
> >
> >
> > _____
> >
> > From: 68HC12@yahoogroups. com
> [mailto:68HC12@yahoogroups. com] On
> Behalf Of
> > yklein@
> > Sent: Thursday, November 16, 2006 3:05 PM
> > To: 68hc12@yahoogroups. com
> > Subject: [68HC12] Pulse accumulator 9sdp256
> >
> >
> >
> > Hi,
> >
> > I'm trying to count pulses from wheel encoder. I'm using ICC12 and
> > MC9S12DP256. The problem I'm having is that the result (PANC1) does
> > not make any sense. The number are not in sequence.(ex. 179, 254,
18...)
> > here is my code, Please help.
> >
> > #include
> > #include
> >
> > void initialize(void);
> >
> > void main(void){
> > initialize();
> > while (1){
> > printf(" %u \r",PACN1);
> > }
> > }
> >
> > void initialize(){
> > DDRT = 0x00; /* configure all timer port pins for input */
> > TCTL4 = 0x04;
> > ICPAR = 0x02; //set PACN1 to count W.E
> > }
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> Hi Mark,
>
> I didn't know that, but the speed of the pulses is very slow, 1sec so
> the printf will have enough time. Can it be that what I'm seeing is
> the time between pulses?
>
> Yuval
>
>
>
> [Non-text portions of this message have been removed]
>
Sounds like the problem I have, I'll try it. Do know what is
reasonable countdown time?



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

--- In 6...@yahoogroups.com, "Mark Wyman" wrote:
>
> Another possibility is bounce.
>
True.

> During the transition of your wheel sensor, there may be a lot
more edge
> occurrences than you expect, so rather than a single count as
expected, you
> may be getting hundreds of them.

I would be very surprised if there were "hundreds". I would be
surprised if there were dozens. I vote for the printf. They are
notorious for taking forever to execute. Even allowing for whatever
the baud rate is on the serial link, printf still takes a ridiculous
amount of time to execute.

Gary Olmstead
Toucan Technology
Ventura CA

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

--- In 6...@yahoogroups.com, "garyolmstead" wrote:
>
> --- In 6...@yahoogroups.com, "Mark Wyman" wrote:
> >
> > Another possibility is bounce.
> >
> True.
>
> > During the transition of your wheel sensor, there may be a lot
> more edge
> > occurrences than you expect, so rather than a single count as
> expected, you
> > may be getting hundreds of them.
>
> I would be very surprised if there were "hundreds". I would be
> surprised if there were dozens. I vote for the printf. They are
> notorious for taking forever to execute. Even allowing for whatever
> the baud rate is on the serial link, printf still takes a ridiculous
> amount of time to execute.
>
> Gary Olmstead
> Toucan Technology
> Ventura CA
>
Hi Mark,

I understand the problem with printf. My question is if there are 100
slots in the wheel encoder and I'm turning it half a cycle why should
the number jump to 197? even if the printf is slow it should still
present the correct count in the end.



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

You can make use of big capacitor at the input to filter out the pulses.

-Nitesh.

________________________________

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf
Of Mark Wyman
Sent: Monday, November 20, 2006 9:32 PM
To: 6...@yahoogroups.com
Subject: RE: [68HC12] Re: Pulse accumulator 9sdp256

Another possibility is bounce.

During the transition of your wheel sensor, there may be a lot more edge
occurrences than you expect, so rather than a single count as expected,
you
may be getting hundreds of them. You may have to write code to "filter
out"
the higher frequency event noise. Use can use a timer interrupt to clear
a
mask flag which is set by the wheel interrupt which prevents a count
increment in your accumulator. The first instance of the interrupt when
the
mask flag is set is the only one that increments your accumulator. Each
successive interrupt from the wheel resets the timer countdown back to
some
countdown value (filter coefficient), so if the timer hasn't had a
chance to
clear the flag yet (timer not down to zero) this is desirable to filter
these edges.

-Mark

_____

From: 6...@yahoogroups.com
[mailto:6...@yahoogroups.com ] On
Behalf Of
yklein2004
Sent: Saturday, November 18, 2006 4:26 PM
To: 6...@yahoogroups.com
Subject: [68HC12] Re: Pulse accumulator 9sdp256

--- In 68HC12@yahoogroups. com, "Mark
Wyman" wrote:
>
> Without looking too into depth on this, I would take a wild guess
that the
> pulses are overflowing faster than printf() can put them out. Try
converting
> the register yourself to a set of characters directly which will
improve
> performance, and you may see what you expect. Printf() is notoriously
> resource hungry.
>
> -Mark
>
> _____
>
> From: 68HC12@yahoogroups. com
[mailto:68HC12@yahoogroups. com] On
Behalf Of
> yklein@...
> Sent: Thursday, November 16, 2006 3:05 PM
> To: 68hc12@yahoogroups. com
> Subject: [68HC12] Pulse accumulator 9sdp256
>
> Hi,
>
> I'm trying to count pulses from wheel encoder. I'm using ICC12 and
> MC9S12DP256. The problem I'm having is that the result (PANC1) does
> not make any sense. The number are not in sequence.(ex. 179, 254,
18...)
> here is my code, Please help.
>
> #include
> #include void initialize(void);
>
> void main(void){
> initialize();
> while (1){
> printf(" %u \r",PACN1);
> }
> }
>
> void initialize(){
> DDRT = 0x00; /* configure all timer port pins for input */
> TCTL4 = 0x04;
> ICPAR = 0x02; //set PACN1 to count W.E
> }
>
> [Non-text portions of this message have been removed]
>
Hi Mark,

I didn't know that, but the speed of the pulses is very slow, 1sec so
the printf will have enough time. Can it be that what I'm seeing is
the time between pulses?

Yuval

[Non-text portions of this message have been removed]

[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 )

It could be a combination of both, but if the wheel is turning slowly, the
detector could reside in a "grey" area, where noise is generating the
additional counts, not just a switch closure. The filter I presented (though
not spelled out very well) can remove this type of "bounce". A capacitor put
in the right place can lower the noise as well, but won't get rid of all of
the mechanical bounces as these may be slow. It is hard to help debug a
system like this without knowing the hardware.

All I know is those cheap dial encoders for user interfaces could give me
upwards of 50 bounce events per edge during slow rotation, and those things
are a nightmare when you want to also be able to sense fast actual events
also. I finally have a fail-safe routine that works all of the time on these
devices, but it took a few ideas and tries to get it working correctly with
minimum overhead. It is based on the example below and a few other tricks.

char permitCount;

Int Clearmasktmr;

_interrupt void Timerint() {

If (!permitCount) {

If (Clearmasktmr == 0) {

permitCount = true;

} else {

Clearmasktmr -= 1;

}

}

}

_interrupt void accumulate() {

If (permitCount) {

Accumulate += 1;

}

Clearmasktmr = 100;

permitCount = false;

}

_____

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
garyolmstead
Sent: Monday, November 20, 2006 2:36 PM
To: 6...@yahoogroups.com
Subject: [68HC12] Re: Pulse accumulator 9sdp256

--- In 68HC12@yahoogroups. com, "Mark
Wyman" wrote:
>
> Another possibility is bounce.
>
True.

> During the transition of your wheel sensor, there may be a lot
more edge
> occurrences than you expect, so rather than a single count as
expected, you
> may be getting hundreds of them.

I would be very surprised if there were "hundreds". I would be
surprised if there were dozens. I vote for the printf. They are
notorious for taking forever to execute. Even allowing for whatever
the baud rate is on the serial link, printf still takes a ridiculous
amount of time to execute.

Gary Olmstead
Toucan Technology
Ventura CA

[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 )

--- In 6...@yahoogroups.com, "yklein2004" wrote:
>
> I understand the problem with printf. My question is if there are 100
> slots in the wheel encoder and I'm turning it half a cycle why should
> the number jump to 197? even if the printf is slow it should still
> present the correct count in the end.
>
You would have to examine the library routine for printf. I have not
done this for this particular compiler, so the rest of this answer is
based on my experience with printf in general.

In particular, most printf routines that I have used disabled all
interrupts while they executed. The whole program came to complete
stop while printf ran.

The easy thing to do, of course is to slow down the wheel so that the
wheel interrupts are (1/baud rate * number of characters to print)
apart. Don't forget to allow for the CR+LF.

If you can't do that, you have to write your own print routine.
Create a queue, and queue handler routines, convert the count to
ASCII, and finish with an SCI Tx routine. It isn't as bad as writing
your own printf, because the input format is fixed.

Gary Olmstead
Toucan Technology
Ventura CA



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

--- In 6...@yahoogroups.com, "Mark Wyman" wrote:
>
> All I know is those cheap dial encoders for user interfaces could
give me
> upwards of 50 bounce events per edge during slow rotation, and those
things

I admit to being surprised. Thank you for that information; I suspect
it will come in handy someday.

Gary Olmstead
Toucan Technology
Ventura CA



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

--- In 6...@yahoogroups.com, "garyolmstead" wrote:
>
> --- In 6...@yahoogroups.com, "Mark Wyman" wrote:
> >
> > All I know is those cheap dial encoders for user interfaces could
> give me
> > upwards of 50 bounce events per edge during slow rotation, and those
> things
>
> I admit to being surprised. Thank you for that information; I suspect
> it will come in handy someday.

Even handier will be to keave these cheap pulse generators at Tandy and use a proper encoder.

Cheers,

Theo



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

--- In 6...@yahoogroups.com, "theobee00" wrote:
>
> --- In 6...@yahoogroups.com, "garyolmstead" wrote:
> >
> > --- In 6...@yahoogroups.com, "Mark Wyman" wrote:
> > >
> > > All I know is those cheap dial encoders for user interfaces could
> > give me
> > > upwards of 50 bounce events per edge during slow rotation, and
those
> > things
> >
> > I admit to being surprised. Thank you for that information; I suspect
> > it will come in handy someday.
>
> Even handier will be to leave these cheap pulse generators at Tandy
and use a proper encoder.
>
> Cheers,
>
> Theo
>
Theo,

When you are in school, and money is a big issue, you get the cheap
encoders and work around them.

Yuval



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

True, it would be nice to be able to select a decent dial encoder, but you
take a massive jump in price from $2-3 to $10+. This especially hurts when a
little code can save you $8 per unit. I forgot to mention that a large part
of bounce on these is due to the mechanics of having a relatively heavy knob
attached to the shaft. Since there isn't any proper mechanical dampening the
weight of the knob allows the shaft to oscillate in and out of its detent
rest position a few times before settling. Each time it "oscillates"
mechanically you get a series of bounce events and that is where the 50
comes from. A different knob yields differing results.

The first code I wrote for it was with no knob, it worked great
on the bench. Your finger flesh makes great mechanical dampening. Put the
thing in a case with a knob and suddenly my count was going all over the
place unpredictably. I quickly discovered the problem, but it was
embarrassing as is typical when you demo a unit.

-Mark

_____

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
theobee00
Sent: Wednesday, November 22, 2006 10:36 AM
To: 6...@yahoogroups.com
Subject: [68HC12] Re: Pulse accumulator 9sdp256

--- In 68HC12@yahoogroups. com,
"garyolmstead" wrote:
>
> --- In 68HC12@yahoogroups. com, "Mark
Wyman" wrote:
> >
> > All I know is those cheap dial encoders for user interfaces could
> give me
> > upwards of 50 bounce events per edge during slow rotation, and those
> things
>
> I admit to being surprised. Thank you for that information; I suspect
> it will come in handy someday.

Even handier will be to keave these cheap pulse generators at Tandy and use
a proper encoder.

Cheers,

Theo

[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 )

> -----Original Message-----
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com]
> On Behalf Of yklein2004
> Sent: Wednesday, November 22, 2006 4:56 PM
> To: 6...@yahoogroups.com
> Subject: [68HC12] Re: Pulse accumulator 9sdp256
> When you are in school, and money is a big issue, you get the cheap
> encoders and work around them.
>
> Yuval
>

If the encoder is of type SPDT (one connection to +5%, one to GND and one to
input pin) you will probably avoid the problem by using a standard
"debounce" circuit using two NAND gates or a single noninverting gate with a
feedback resistor from output to input. It is a nice solution because it
does not limit the max frequency as filtering with capacitors will do.

http://www.ganssle.com/debouncing.pdf

Anders


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

--- In 6...@yahoogroups.com, "Mark Wyman" wrote:
>
> True, it would be nice to be able to select a decent dial encoder,
but you
> take a massive jump in price from $2-3 to $10+. This especially
hurts when a
> little code can save you $8 per unit. I forgot to mention that a
large part
> of bounce on these is due to the mechanics of having a relatively
heavy knob
> attached to the shaft. Since there isn't any proper mechanical
dampening the
> weight of the knob allows the shaft to oscillate in and out of its
detent
> rest position a few times before settling. Each time it "oscillates"
> mechanically you get a series of bounce events and that is where the 50
> comes from. A different knob yields differing results.
>
> The first code I wrote for it was with no knob, it
worked great
> on the bench. Your finger flesh makes great mechanical dampening.
Put the
> thing in a case with a knob and suddenly my count was going all over the
> place unpredictably. I quickly discovered the problem, but it was
> embarrassing as is typical when you demo a unit.
>
>
>
> -Mark
>
>
>
> _____
>
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On
Behalf Of
> theobee00
> Sent: Wednesday, November 22, 2006 10:36 AM
> To: 6...@yahoogroups.com
> Subject: [68HC12] Re: Pulse accumulator 9sdp256
>
>
>
> --- In 68HC12@yahoogroups. com,
> "garyolmstead" wrote:
> >
> > --- In 68HC12@yahoogroups. com,
"Mark
> Wyman" wrote:
> > >
> > > All I know is those cheap dial encoders for user interfaces could
> > give me
> > > upwards of 50 bounce events per edge during slow rotation, and
those
> > things
> >
> > I admit to being surprised. Thank you for that information; I suspect
> > it will come in handy someday.
>
> Even handier will be to keave these cheap pulse generators at Tandy
and use
> a proper encoder.
>
> Cheers,
>
> Theo
>
>
>
> [Non-text portions of this message have been removed]
>
Thanks to everyone, I used your advice and I de-bounced the encoder
output. it's working now.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

--- In 6...@yahoogroups.com, "yklein2004" wrote:
>
> --- In 6...@yahoogroups.com, "theobee00" wrote:
> >
> > --- In 6...@yahoogroups.com, "garyolmstead" wrote:
> > >
> > > --- In 6...@yahoogroups.com, "Mark Wyman" wrote:
> > > >
> > > > All I know is those cheap dial encoders for user interfaces could
> > > give me
> > > > upwards of 50 bounce events per edge during slow rotation, and
> those
> > > things
> > >
> > > I admit to being surprised. Thank you for that information; I suspect
> > > it will come in handy someday.
> >
> > Even handier will be to leave these cheap pulse generators at Tandy
> and use a proper encoder.
> >
> > Cheers,
> >
> > Theo
> >
> Theo,
>
> When you are in school, and money is a big issue, you get the cheap
> encoders and work around them.

Indeed, with the cheapies it helps to have a lot of hysteresis on the input amplifier for a start, some circuits have a tendency to oscilate when on the margin.

Slowing the input down with a few caps is next, the limit is the max speed, put in the biggest cap that still allows your maximum expected.

Good luck.

Cheers,

Theo



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

theobee00 wrote:
> --- In 6...@yahoogroups.com ,
> "yklein2004" wrote:
> >
> > --- In 6...@yahoogroups.com ,
> "theobee00" wrote:
> > >
> > > --- In 6...@yahoogroups.com ,
> "garyolmstead" wrote:
> > > >
> > > > --- In 6...@yahoogroups.com ,
> "Mark Wyman" wrote:
> > > > >
> > > > > All I know is those cheap dial encoders for user interfaces could
> > > > give me
> > > > > upwards of 50 bounce events per edge during slow rotation, and
> > those
> > > > things
> > > >
> > > > I admit to being surprised. Thank you for that information; I
> suspect
> > > > it will come in handy someday.
> > >
> > > Even handier will be to leave these cheap pulse generators at Tandy
> > and use a proper encoder.
> > >
> > > Cheers,
> > >
> > > Theo
> > >
> > Theo,
> >
> > When you are in school, and money is a big issue, you get the cheap
> > encoders and work around them.
>
> Indeed, with the cheapies it helps to have a lot of hysteresis on the
> input amplifier for a start, some circuits have a tendency to oscilate
> when on the margin.
>
> Slowing the input down with a few caps is next, the limit is the max
> speed, put in the biggest cap that still allows your maximum expected.
>

As a conclusion: You learn more with cheap hardware!

/Lennart

> Good luck.
>
> Cheers,
>
> Theo
>



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

--- In 6...@yahoogroups.com, Lennart Lindell wrote:
>
> theobee00 wrote:
> >
> >
> > --- In 6...@yahoogroups.com ,
> > "yklein2004" wrote:
> > >
> > > --- In 6...@yahoogroups.com ,
> > "theobee00" wrote:
> > > >
> > > > --- In 6...@yahoogroups.com ,
> > "garyolmstead" wrote:
> > > > >
> > > > > --- In 6...@yahoogroups.com ,
> > "Mark Wyman" wrote:
> > > > > >
> > > > > > All I know is those cheap dial encoders for user interfaces could
> > > > > give me
> > > > > > upwards of 50 bounce events per edge during slow rotation, and
> > > those
> > > > > things
> > > > >
> > > > > I admit to being surprised. Thank you for that information; I
> > suspect
> > > > > it will come in handy someday.
> > > >
> > > > Even handier will be to leave these cheap pulse generators at Tandy
> > > and use a proper encoder.
> > > >
> > > > Cheers,
> > > >
> > > > Theo
> > > >
> > > Theo,
> > >
> > > When you are in school, and money is a big issue, you get the cheap
> > > encoders and work around them.
> >
> > Indeed, with the cheapies it helps to have a lot of hysteresis on the
> > input amplifier for a start, some circuits have a tendency to oscilate
> > when on the margin.
> >
> > Slowing the input down with a few caps is next, the limit is the max
> > speed, put in the biggest cap that still allows your maximum expected.
> > As a conclusion: You learn more with cheap hardware!

Yup, mainly how to get rid of all these grey hairs:-)

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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