What I wanted to do was minimize the calculations on the MCU. What about reading off an available 16bit timer ? Do you think Il still need the direction ?
Its for speed calculation.
No you don't really need the direction info for speed control, but you still need a count when in reverse (if you need speed control in that situation at least).
Given the CPR (50 to 1024, depending on your specific model), you shouldn't need more than an 8 bit timer, as long as you choose the timing accordingly.
A small interrupt routine could handle this easily, without much load on the controller. If you make a qualified evaluation that says it would be a close shave, a faster controller is cheaper than buying specialized circuits (or use a 6- or 8 pin controller as a decoder to unload the main controller.
To get the speed, just time the intervals between pulses. Depending on how many counts/rev. the encoder gives, you can count just the rising edge on A (1*CPR), both rising and falling edge on A (2*CPR) or both edges on both A and B (4*CPR).
The time between pulses will be the reciprocal of speed (i.e. the faster you go, the less time between "clicks".
As I mentioned, a running average on a few samples will avoid any jerkiness, should any appear.
Another way of averaging is to always count two ticks, but swapping out the oldest sample and replacing it with the newest (this can be expanded if needed), or a logarithmic decaying average, where samples matter less and less,the farther back in time they are (but that's probably overkill for this app.).
If you want to keep it outside the '128, a 6-pin controller (going at less than $0.40) will be a better solution than a specialized IC that may soon become a rarity (i.e. no or very expensive replacement) - plus you'll know how it works down to the least bit of code.