You don't need a separate chip. THe PIC can count pulses very easily. This is an incremenetal encoder only? Just ticks for every X degrees of rotation, identically whether it's CW or CCW? Just to let you know, one encoder won't be enough to help your robot from not veering off course.

Since your PIC doesn't have a capture compare module, you COULD connect the encoder to an interrupt pin and just have it increment a value every time the interrupt is activated. OR you could make it easy and use Timer0 as a counter rather than a timer:

PAGE 21: http://ww1.microchip.com/downloads/e...Doc/35007b.pdf
It tells you how to use Timer0 as a counter rather than a timer- the counter is incremented based on input pulses on the RA4 pin.

Yeah, one encoder on one wheel is kind of like God giving you two legs, but making one of them numb all the time. One encoder will give you purely distance readings. The problem with one "assymetric" encoder is that if the robot veers/turns, it will affect your readings (one wheel travels less or more during turns).

If you use one encoder, it's better to stick it on a single passive wheel centered somwhere on the midline between the two powered wheels. That way, if the robot veers or turns, your distance readings are still accurate. Bottom line- you want your encoder arrangement to be symmetric so they are not affected by turns. So one one encoder in the center, or two either side of the centerline is fine. But one on a single side is not.

Do what you want though, it may be the case that the encoder is designed just for that motor and must stay with it and you don't want to buy a second encoder for the other motor (plus there is only one Timer0 pin to work with so you can't use that method with two encoders). You could use the tricycle formation though. This would allow the use of one motor-mounted encoder, but would require a steering servo.

Don't use the interrupt. Use Timer0. It's should be more straightforward and take less code plus it won't bog down your processor with interrupts since (I assume) it's designed to run in the background. As opposed to interrupts which will continually interrupt your program flow. Also, if for some reason your PIC is clocked ultra slow and the wheels are spinning ultra fast (or the encoder outputs many many ticks per revolution), you might actually miss ticks...which build up onto the already attrocious odometric error from wheel slip.