Rotary Encoder

[asmboy]

first comment.

if using set_tris --then declare
#use fixed IO before hand

also - using an LCD display with safety delay or
even actual hardware busy/handshake - can take
LOTs of milliseconds to execute.

you can't loop back for another look at the encoder state
at any kind of speed because your LCD display line imbedded in
the function. LCD update can be so slow as to be able to let let additional encoder states pass un-noticed.

//
if i was doing this - i'd get the encoder bits read on
a pic with portb_change interrupts.

then just call the lcd print routine from main as a separated
function to refresh the screen.

[Ttelmah]

He should use fast_io, not fixed_io.....

#use fast_io(D)

needs to be added.

However a huge amount depends on the actual speed of the encoder. 'Speed' here is the pulse rate per second. A 1000 line decoder, gives four changes per 'line', and if spun at even 100rpm will give:
(4000*100)/60 changes per second that have to be sampled. The loop needs to execute faster than this. 6666*per second. as asmboy says, for anything but a very slow encoder, the LCD is the big problem. Now the LCD code might well work for a really slow movement, with only a few lines on the encoder (a few RPM, on a 16 line encoder for example), but for anything faster or with higher resolution, the code won't work...

Solutions:
1) As Asmboy says, use a port with interrupt on change.
2) Add the logic, so the encoder can feed the internal CCP channels of the PIC (only requires a couple of logic gates - details on the Microchip site).
3) Decode externally (A chip like the LFLS7366R also adds signal filtering).

[necati]

https://sites.google.com/site/proyectosroboticos/encoder/encoder-por-software

[asmboy]

I should add that your encoder table is more complex than needs be -
due to the code method of your encoder and number of bits. ( standard incremental binary)

I greatly prefer 2-bit Gray " reflected binary code" devices.

The optically coupled types have no "bad states" or glitching
at any frequency i have ever used.

For simple +/- count applications they are beyond question
the superior solution.