Pulse accumulator 9sdp256

Started by ykle...@pacbell.net November 16, 2006
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
}
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... [mailto:6...] On Behalf Of
y...@pacbell.net
Sent: Thursday, November 16, 2006 3:05 PM
To: 6...
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
}
--- In 6..., "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... [mailto:6...] On
Behalf Of
> yklein@...
> Sent: Thursday, November 16, 2006 3:05 PM
> To: 6...
> 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
> }
>
>
>
>
>
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
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... [mailto:6...] On Behalf Of
yklein2004
Sent: Saturday, November 18, 2006 4:26 PM
To: 6...
Subject: [68HC12] Re: Pulse accumulator 9sdp256

--- In 68HC12@yahoogroups.





















































--- In 6..., "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... [mailto:6...] On
Behalf Of
> yklein2004
> Sent: Saturday, November 18, 2006 4:26 PM
> To: 6...
> Subject: [68HC12] Re: Pulse accumulator 9sdp256
>
>
>
> --- In 68HC12@yahoogroups.










































































--- In 6..., "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
--- In 6..., "garyolmstead" wrote:
>
> --- In 6..., "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 can make use of big capacitor at the input to filter out the pulses.

-Nitesh.

________________________________

From: 6... [mailto:6...] On Behalf
Of Mark Wyman
Sent: Monday, November 20, 2006 9:32 PM
To: 6...
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...































































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... [mailto:6...] On Behalf Of
garyolmstead
Sent: Monday, November 20, 2006 2:36 PM
To: 6...
Subject: [68HC12] Re: Pulse accumulator 9sdp256

--- In 68HC12@yahoogroups.




















--- In 6..., "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