My pet peeve is when quadrature decoding is done in software. When done in software, the decoder frequently can't keep up, especially when the pulse rate is fast or the MCU is doing a lot of other things. I have seen many devices that use quadrature encoders on a data-entry knob, and it works fine most of the time. But the decoder would skip pulses whenever the MCU had to do something, like refresh the screen or talk over RS-232.
I do quadrature decoding in an FPGA. A 50K Gate Xilinx Spartan-3A costs less than $10 and can decode more channels than it has pins. And it'll do it with a quadrature pulse rate over 1 MHz. There are no MCUs for similar or cheaper cost that can do that.
Edit: What follows below is a summary of lots of comments, and some further elaboration on my part. Enjoy!
It's true that you can do a software approach if the pulse rate is slow enough. But when this is done, you have to make sure that the "corner cases" are covered. Things like interrupts for other peripherals (like UARTs, ADCs, etc.) can effect how often you sample the quadrature data causing the quadrature decoding process to occasionally miss pulses. These missed pulses are "ok" for some applications, like a data-entry knob, but are still annoying to me.
@Leon Heller really likes the XMOS processors for something like that. For those who don't know, the XMOS stuff is basically a simple but super fast MCU. Where most MCU's run in the <25 MIPS range, the XMOS stuff is pushing 500 MIPS. XMOS doesn't do a lot of hardware based peripherals, like UARTs. Instead they "bit-bang" it and do the UART in software. They also bit-bang things like USB and 10mbps Ethernet. Ok, I'm super-over-simplifying this, but you get the point. Here's my opinion: there are FPGA guys and there are CPU guys. If you're a CPU type of guy and don't like FPGAs then the XMOS processor might be right for you.
The topic of Gray-codes in an FPGA implementation was brought up, and implementing the up/down position counters in gray code. There are typically two reasons to use Gray-codes: if you have some asynchronous logic going on (2 or more clocks), or if you want the counters to take up less logic. Normally you wouldn't have async logic in the FPGA (other than sampling the quadrature data at the input pins), and the FPGA already has super-fast carry chains (a.k.a. binary adders). So really, under normal circumstances there isn't any need for gray-code counters for this.
You could use a CPLD for this, instead of an FPGA. This would work for 1 or 2 quadrature decoders, but as you add more decoders the interfacing to a MCU gets more complex. FPGAs are nice for this because the MCU interface could be SPI or other simple thing that doesn't take up dozens of pins on the MCU.
The "correct" way to do this in an FPGA is where the FPGA has a simple 8-16 bit counter that tracks the position. This counter is never reset after initialization, and sometimes not even then. Software (SW) would poll this position every so often, and would keep a record of the "previous position". Taking the current position and subtracting the previous position would tell the software how far the position changed.
The reason the position counter is never reset is because we're trying to avoid a "destructive read". That's when the CPU reads a register which causes something irreversible to happen-- like clearing a position counter. Sometimes destructive reads are unavoidable, like when reading a FIFO, but generally you want to avoid them. The thinking behind this is beyond this post. I tried to find a good web page that discusses them, but I failed. Sorry.
When talking about the count-rate, below, I mean how fast the position counter can go up or down. Because of the quadrature nature of the thing, the "pulse rate" is one quarter of the count rate. I'm assuming that for every full pulse we can count up/down 4 times. I know there are other ways to count (one count per full pulse), but I'm ignoring it out of principal.
Ignoring the XMOS processor (which is more like an FPGA, in the context of the next few paragraphs), MCU's are going to be limited to a max count rate of less than 500 Hz and in many cases less than 100 Hz max. Of course there might be some outliers that get higher than 1 KHz, but for most people that's hard to do. For your typical MCU you're doing good to get above 100 Hz, assuming that the MCU is not dedicated to quadrature decoding.
A typical data-entry knob has 12 to 20 pulses per revolution, or 48 to 80 counts per revolution. Assuming the knob is 1 inch in diameter, a typical but over-zealous person could get about 4 turns per second when trying to scroll through lots of data. That works out to a count rate of 192 to 320 Hz. Still within the capability of an MCU, but just barely and only with careful programming.
An FPGA, depending on exactly how the logic is written, could handle a count rates of more than 100 MHz. I've written my logic to handle count rates of up to about 50 KHz, but it can do many quadrature decoders in a very small amount of logic. In a Xilinx Spartan-3 FPGA it takes about 50 slices and 1 Block-RAM to do 32 to 512 decoders (you'll run out of pins before you run out of logic).
So, which is better, FPGA, MCU, or XMOS? As usual, it depends. It depends not only on the usual things like count rate and number of decoders, but also on what the designer is comfortable using and what else is in the system. My preference is FPGA, but that's just the kind of guy I am! :)