IC that reads gray code from an encoder, keeps count, and gives current value

[Watth]

Hey EEfolks,
So is there a type of IC that works like a driver/peripheral (I'm not sure of the proper terminology) that

• reads gray code data from an encoder
• keeps count of the ups and downs (i.e. in a signed integer)
• can give the current value by series/parralel transmission to a µUC
• resets by %CU command
• can alret the master µCU by interrupt if the value is getting too high (or to low if negative) for the count variable

?
I explored the possibility to programm an ITtiny for this task, as it can be less expensive and perform the exact functions I want, but if there is any simple, cheap and even less voluminous solution, I'd wish to hear about it.
Thanks for reading!

[Doctorandus_P]

30 years or so ago such chips were available via normal channels.
Now they are completely obsolete, and the people who sell them also know that.

But no worries.
They're only obsolete because the world has moved on, and 2-bit grey encoders are still common.
The hardware for such encoders is integrated many microcontrollers these days. (Most of?) the STM32 microcontrollers have gray encoder functions built in in their timers for example, but other manufacturers also similar peripherals in their microcontrollers.

[Watth]

Well it is cheaper to program a µCU that includes software de-bouncer.

[voltsandjolts]

What is the electrical interface specification for your encoder?

[ledtester]

What speed will the encoders be operating at?

There was a recent discussion of reading multiple rotary encoders with an Arduino. Thread has lots of ideas including sample code:

 https://www.eevblog.com/forum/beginners/suggestion-of-methods-to-attach-8-rotary-encoders-to-an-arduino/

can alret the master µCU by interrupt if the value is getting too high (or to low if negative) for the count variable

If you use a powerful enough MCU you can combine the encoder reading with your main application. Sometimes this is the best way to proceed.

[Watth]

It's a simple ABC pin thing : https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheets/EN05.pdf.
It would be manually operated.

I'll see if I really need this when I start testing if it can be directly used by the µMC. I have no idea if monitoring the encoder would make it visibly slower, especially since the encoder would not be used most of the time, therefore ignored. Also, I still don't know if bounce management is needed at all (or can be suppressed by a simple RC circuit) with this particular encoder.

[Watth]

If you use a powerful enough MCU you can combine the encoder reading with your main application. Sometimes this is the best way to proceed.

Yup, I need to advance in my project to see if it anything more than the µCU is needed.

[ledtester]

It's a simple ABC pin thing : https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheets/EN05.pdf
It would be manually operated.

I'll see if I really need this when I start testing if it can be directly used by the µMC. I have no idea if monitoring the encoder would make it visibly slower, especially since the encoder would not be used most of the time, therefore ignored. Also, I still don't know if bounce management is needed at all (or can be suppressed by a simple RC circuit) with this particular encoder.

That encoder only has 12 pulses per revolution so it can't change that fast if you are manually operating it. Given the bounce and chattering times listed the datasheet I would just poll the encoder inputs every 10 ms.

[jmelson]

There's the LS7166 chip that has a 24-bit position counter with quadrature decode logic in front.  I had a board with that chip and it seemed to have an issue with the rollover from signed -1 to 0, or zero to minus 1.  I don't know if this was a fundamental problem with the chip or the board that it was on.

Jon

[Watth]

Given the bounce and chattering times listed the datasheet I would just poll the encoder inputs every 10 ms.

I think I'll simply implement the RC filters suggested in the datasheet.

[rstofer]

What speed will the encoders be operating at?

There was a recent discussion of reading multiple rotary encoders with an Arduino. Thread has lots of ideas including sample code:

 https://www.eevblog.com/forum/beginners/suggestion-of-methods-to-attach-8-rotary-encoders-to-an-arduino/

If you use a powerful enough MCU you can combine the encoder reading with your main application. Sometimes this is the best way to proceed.

If you follow the link above to Reply 6, I post a link to a blog that has some nice interrupt driven code:

http://blog.templaro.com/reading-a-rotary-encoder-demo-code-for-atmega328/

The point of using interrupts on switch edges is to remove the issues of bounce.  Sure, go ahead and implement the filters but the code should get the right answer anyway.

I did the same kind of thing for 2 wheel encoders on an Atmega 128 and it worked well.

The nice thing about using interrupts is that there is no polling and everything happens in the background.

OTOH, that code is going to take some studying.

I attached my code for what it is worth.  It's easier to follow but it isn't made for an Arduino.

[james_s]

The hardware for such encoders is integrated many microcontrollers these days. (Most of?) the STM32 microcontrollers have gay encoder functions built in in their timers for example, but other manufacturers also similar peripherals in their microcontrollers.

How does that work? 

[Dave8266]

The point of using interrupts on switch edges is to remove the issues of bounce.  Sure, go ahead and implement the filters but the code should get the right answer anyway.

Switch bounce is only going to be solved if your application code handles it - that's not something inherent that comes with interrupts.   
A person could have just as many (or even more) switch bounce problems with interrupts as with polling - it's all in what happens in your ISR, and what your application does when it detects a change.

For example, say I have an application that sends a text message to a mobile phone on each change of position of the rotary encoder, indicating which direction, clockwise or counter-clockwise, it was rotated.
An interrupt handler that dutifully responds to signal edges might queue up a flurry of "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" messages during the bouncing.   Sure it "got the right answer" at the end - a net change of +1 direction step - but the behavior was not at all what was expected - actual debouncing was still needed.

[Kjelt]

STM32 microcontrollers have gay encoder functions built in

How does that work? 

Probably an optical colour encoder with all the colours of the rainbow. 

[Doctorandus_P]

That encoder only has 12 pulses per revolution so it can't change that fast if you are manually operating it. Given the bounce and chattering times listed the datasheet I would just poll the encoder inputs every 10 ms.

Rotary encoder knobs can generate several hundreds of pulses per second, so sampling at 100Hz would be too slow. For rotary encoders I would go with either an ISR based approach or with a grey code compatible timer, and this needs cleanup of the signal, so I would add RC filters to the encoders.
It's quite important here that the switches of these encoders can not short the filter capacitor. Small ceramic capacitors can deliver high peak currents which can (and will) damage the encoders.

I do wonder how the do this for the UI for oscilloscopes, which can have 10 or more of such rotary encoders.

[Dave8266]

Rotary encoder knobs can generate several hundreds of pulses per second, so sampling at 100Hz would be too slow.

They can in a general sense...  but for a tiny 5mm encoder with physical detents, only 12 steps per revolution, and specified bounce and chatter of up to 5ms each, I'm with ledtester on this one.  This just isn't an encoder you would use for a "hundreds of pulses per second" type of application.   One might choose to sample faster anyway, to give some extra data to work with for debouncing, but if you have to wait for it to stabalize, the mechanical limitations will ultimately dictate the maximum reliable rotation speeds.

I do wonder how the do this for the UI for oscilloscopes, which can have 10 or more of such rotary encoders.

I've never studied a scope schematic, but shift registers and polling makes simple work of large numbers of encoders.   The oscilloscope case is a favorable one too, because there is a presumption that the operator is human - ie, unlikely to turn any knob excessively fast, and unlikely to turn more than two knobs at a time.    (That's a good scenario for something using interrupts as well.)

[Watth]

I'll test it when I'll receive the encoder, and in real use condition (with and without the proposed RC filters), and check on the oscilloscope at what typical frequency the signals appear, and if there are some extra debouncing to do.

[james_s]

I do wonder how the do this for the UI for oscilloscopes, which can have 10 or more of such rotary encoders.

Tektronix used a separate microcontroller on the front panel that reads the encoders, scans the buttons and operates the indicator LEDs. I don't know what other manufactures do. Haven't there been teardowns and examination of the some of the popular entry level scopes?

[BeBuLamar]

The link for the datasheet is broken for me so I can't read it. Is it an absolute encoder or incremental? If it's incremental it wouldn't have gray code.

[Watth]

Does it work now?
https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheets/EN05.pdf
It is incremental with 2 bits Gray code.

[BeBuLamar]

I have never heard of 2 bit gray code. Reading the datasheet I would call the output quadrature.

[Dave8266]

I have never heard of 2 bit gray code. Reading the datasheet I would call the output quadrature.

Is this one of those "All thumbs are fingers, but not all fingers are thumbs" situations?

Just like how a four-position quadrature encoder is both incremental and absolute...