Make PIC simulate binary up/down counter - how to calculate how fast can it count?

[dw_picbasic]

Hello All,
I have a theoretical question about guesstimating how fast an input signal a PIC can track.

I'd like to experiment with an 18pin PIC - such as the PIC6F627A
I'd like to simulate a binary up/down counter
But this counter will keep track of degrees - with a max value of 359
Which means it needs to role over when > 359 and role over when < 0

The input signal to track will be a standard A/B encoder signal requiring 2 input pins.
The output will be PORTB's 8 pins, and one pin from PORTA to function as 9th bit.
9 bits can hold our expected values.

The PIC will be running with internal oscillator at 4mhz
Is there a way I can guesstimate how fast an encoder pulse the PIC will be able to accurately track?
Thanks in advance! :-]
dw


A description of the process follows:

PORTA will have 2 input pins with alias names = Pin_A, Pin_B
PORTA will have 1 output pin with alias name = bit9
PORTB will have 8 output pins

main:

'Here we remain in a loop until Pin_A clock input goes high
while pin_A = 0
wend

'We are now here because pin_A clock input went high starting a clock cycle
'------------------------------------------------------------------------

if pin_B = 1 then counter = counter + 1
if pin_B = 0 then counter = counter - 1
if counter > 359 then counter = counter - 360
if counter < 0 then counter = counter + 360
if counter > 255 then HIGH bit9 else LOW bit9
PORTB = counter && 255

'We now wait for pin_A clock input to go LOW
'In order to be ready for its next clock cycle
'---------------------------------------------
while pin_A = 1
wend

'we are now here because pin_A has gone LOW and is now ready for its next cycle
'Start over and get pin_A next clock cycle

goto main

[richard]

some thoughts, in my experience decoding quadrature signals that way usually miscounts when small back forward movements and or freq direction
changes occur. plus you only get a quarter of the possible resolution , edge detection on both channels is a better method
i might add your method will be intolerant to any noise [contact bounce] too
you could try these ideas and maybe tweak a little more speed.

PORTB = counter && 255 is not really correct , && is a logical AND you need a BITWISE AND
PORTB = counter & 255
or
PORTB = counter.lowbyte
or since its an 8bit chip
PORTB = counter , would do but may get a warning about low byte value being used

since the count can only inc/dec by 1 count you can simplify to this

if pin_B = 1 then counter = counter + 1
if pin_B = 0 then counter = counter - 1
if counter.15 then counter = 359
if counter > 359 then counter = 0

bit9 can be simplified to this

bit9=counter.8


making

if pin_B = 1 then counter = counter + 1
if pin_B = 0 then counter = counter - 1
if counter.15 then counter = 359
if counter > 359 then counter = 0
bit9=counter.8
PORTB = counter.lowbyte

[dw_picbasic]

Thank you Richard,
Could you take a moment to describe what happens with edge detection on both channels?

Sincere thanks!
dw

[richard]

every edge [transition] is a decodable step for the encoder


you catch each step with an edge triggered pin interrupt, you need a better chip , 16f1825 or something useful

[HenrikOlsson]

We had a similar discussion not that long ago, might be worth revisiting.
It's important to remember that one usually want to do more than JUST keep track of an enocder and that has to be accounted for. Anyway, here's a link to that thread: http://www.picbasic.co.uk/forum/show...ght=quadrature

[dw_picbasic]

We had a similar discussion not that long ago, might be worth revisiting.
It's important to remember that one usually want to do more than JUST keep track of an enocder and that has to be accounted for. Anyway, here's a link to that thread: http://www.picbasic.co.uk/forum/show...ght=quadrature

Thank you Hendrik.
That gave me a lot to think about.
One of the examples in that thread has the pic checking for 4 possible conditions of two bits, and remembering the last condition of those two bits.
With my experiments so far - I haven't found that to be necessary in order to maintain accuracy.

I have a pic that simulates the output of an encoder, starting with pulse periods of 15ms.
It produces 180 cycles in the CW direction - then pauses - and then produces 180 cycles in the CCW direction.

After each CW/CCW process - it starts over - but with a little shorter pulse period.
I then monitor my programs decoder output on an LCD display.
If all goes well - it starts at 0 - goes to 180 counts and then returns to 0.

I know when the processor is starting to loose track when the LCD displays bad numbers.
So far I've been able to accurately track pulse periods down to 5milli-seconds.
That may in fact be satisfactory for my usage - but I'm still playing with other options.

[dw_picbasic]

Richard - thank you for pointing me to that PIC!!!
I was going to ask about newer PICs with internal OSC running at higher speeds
But I hadn't even imagined one running at 32Mhz

Very sweet!!
And thank you for the emphasizing catching each edge with an ONCHANGE interrupt.
I'll be doing some further research on that - especially with a faster device!

Sincere thanks :-]