|
I have 6 high resoloution encoders (10k lines) that I want to interface with a micro controller. I have written code to do the quadrature decoding for all the encoders but there is just no way that a poor Arduino can handle that that many encoders at any reasonable speed, let alone do anything else while keeping track of the encoders. What should I do in such a situation? Unfortunately I don't have much of a background in electronics, just in programming (just a little bit). |
|||||
|
|
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! :) |
||||
|
|
My suggestion would be to have the Arduino execute user application code, and simply talk to 3 or 6 other very low cost microcontrollers that do the quadrature decoding. The number of external micros depends on how capable they are of decoding such a high-resolution encoder at a given speed. The external micros would behave like those in mice -- they keep track of the encoder count delta since the last position query. Assuming that you're not trying to do realtime position feedback for closed loop motor control, and just want to know where each motor is at an arbitrary point in time, this could work out for you. Use SPI or I2C to talk to all of the external micros, and of course you'll need to deal with counter rollover in the event that the main controller (Arduino) doesn't request a position update at regular, guaranteed intervals. |
|||||||||||||||||
|
|
Use a $7.50 XMOS XS1-L1 chip, with six threads doing the decoding - one thread for each encoder: That leaves two threads for doing other stuff. The XK-1A board available from Digi-Key only costs 99, and comes with the XTAG-2 debugger. It's got everything you need on it Development software is free, and I think I've seen encoder software on the users forum. The 1600 MIPS XC-1A board is another option, and also costs 99. This is probably the easiest and cheapest way to do it. |
|||||||||||||||||||
|
