Quadrature Encoder Interface output frequecy On Tm4c123gh6pm and Comparison with timer Edge-Count Mode.

Hello Ishan

Do you mean QEI sampling frequency?

Regards
Amit

Hey Amit.
Yes I am talking about sampling frequency of QEI. My system frequency is 80 MHz.

Hello Ishan,

The QEI works of the system clock, so I am not sure why it would be lesser than a Timer working on the same system clock?

Regards
Amit

Morning Amit,

As you know - firm/I work w/multiple ARM MCUs from several vendors.    And - in general - I agree w/poster - some timing penalty is imposed by the MCU's internal QEI resolution implementation.   (this is noted upon multiple vendor's offerings - not just yours)

Now - for a more "in-depth" & educational method - 2 or 3 "spare" MCU GPIOs - set-up as outputs - could be programmed as "pseudo QEI" and fed - in parallel - to (both) the QEI phase inputs AND an MCU's Timer.   In this manner - any difference between QEI & Timer would "Quickly/Easily" reveal.   

As "What's Unclear" post nears 26K "views/visits" (highest ever, this forum) I've suggested an App Note detailing the programming of a TM4C to realize this "pseudo QEI" capability.   (in the past - we simulated "Hall Sensor" signaling - both @ 120 & 60° (electrical) - via a far simpler, 8 bit MCU!)   

Better understanding always flows from "better tools and/or methods" - be they physical or software.   Believe this "points" in that direction...

Hello cb1,

Yes, I did read the updated post last evening and I do agree that something on the lines of a QEI generator as a test engine for QEI before interfacing an encoder wheel would be a good diagnostic/development tool.

And I am taking into account the fact that 3 QEI posts arrived in 24hrs, but at this moment would not commit to a time frame for the app note and its dev code due to the overwhelming tasks at hand that need attention.

Regards
Amit

Yes Amit - thank you. Of course, "three quick arriving QEI posts" cannot justify an, "Immediate call to action." But - logged into our, "What's Unclear" repository - posters have the chance to agree or reject - all comments are welcome.

As firm/I most always intend - having such a focused QEI App Note (w/code & explanation) actually will "lighten the burden" upon you! Many times we've noted that posters just require a (reasonable) example - with a related narrative - and then they are, "Good to Go!"

I do believe that the "parallel" exciting of (both) QEI inputs and Timer (almost) qualifies as "inspired." That's surely the best way to determine "if" and by "what degree" the QEI count differs from Timer's.

Hello cb1_mobile.

Is there a solution to make QEI match Timer sampling frequency? How to implement "pseudo QEI" ?

My friend - give me an hour or so to "escape" client's facility - and arrive home office. It's raining now - and temperature is predicted to drop shortly to "single digits." There are some (unqualified & unkind) who characterize my driving skills as "not so good" yet when ice lurks - I'd vote w/them. (from the safety of roadside ditch)

Follows a general MCU procedure to generate, "QEI style" outputs - 90° out of phase - for introduction into an (internal) or external QEI decoder.

Assumed is a 90° phase shift, 50% duty cycle - use of a single, MCU Timer, and the presence of 2 GPIO pins configured as outputs.   (3rd required should QEI Index be required)

Now class - who can tell us why, "360 was chosen as the number of degrees w/in a circle?"   (ANS: 360 is the smallest integer which is evenly divisible by "so many" other integers... i.e. by 2, 3, 4, (even 5!), 6, (not 7), 8, 9, 10, 12, (15 surprisingly), 16, 18, 20, 24, 30, 36, 40, 45, 60, 72, 90...)

So we begin by choosing some integral multiple of 360 to serve as our "Phase A, QEI frequency generator.   (i.e. 3,600, 36,000 both fit w/in a 16 bit counter)

• devise program code to detect 1/4, 1/2 and full timer count.   (i.e. 900, 1800, 3600 counts if the 3600 max timer value was chosen)
• enable the timer/counter to count up
• Clear the Timer/Counter - then Set Phase A output bit, clear Phase B output bit     ***   this represents QEI Code start instruction
• upon detection of the "quarter count" max timer value, set Phase B output bit
• upon detection of the "half count" max timer value, clear Phase A output bit
• upon detection of the "three quarter count" max timer value, clear Phase B output bit
• upon detection of the "full count" max timer value - loop to "QEI Code start"

  Normally this will yield an acceptable Quadrature output.   The detection of those four, critical timer values may be handled w/in an interrupt - that same interrupt may be "reloaded" w/"next critical timer count" values.

  Via use of that Timer's Pre-scaler and/or injection of an external frequency signal - this "pseudo QEI Generator's" frequency may be selected.

  I do not pretend nor offer that this method achieves the highest degree of accuracy - refinements are possible - yet this should prove, "Good for Gov't Work."   (if you like your QEI - you can keep your QEI! ... ... (maybe... sometimes...)   Use - as forum "boilerplate states" - is at your risk...

There is a hw decoding solution that feeds into a timer. I suspect you're better off using the built in peripheral but here's an outline.

First you can determine direction by using one phase as the clock on a d flip flop, the other as data. The output changes polarity depending on direction.

You can then simply use a counter to determine speed/ distance.

There is a digital filter technique that eliminates edge noise as well at the expense of missing counts on direction changes. The idea is you use each edge on phase a to clock the data on phase b and vice versa. This removes multiple edge transitions quite effectively.

Robert

I initially ran across this in a 80C196 user manual.

Hopefully you avoided the freezing rain. I drove through some 8 hours of that over the holidays. Accumulated nearly a cm of ice on the front of the car

Robert

ApparentlyI read the last question wrong.

Bonjour Monsieur,

Unfortunately freezing rain & horizontal snow was my plight.   Tried to, "get a jump" on next week - accomplished that - but quadrupled commute time on return.

Prior to seeing your (latest... Apparently...) post I was going to note:

Dear Forum readers (landing here)

Poster Robert provides an "auxiliary means to "help" the MCU decode & process a QEI signal.

Poster cb1 (i.e. this guy) provides a method to program your MCU (any MCU) to generate a "pseudo QEI" output pulse train - which can then be routed into the MCU's QEI inputs.   The merit of this approach is that, "Everyone (then) tests/verifies from a common (and known) beginning.   Goal is to reduce the burden upon Amit.

One hopes the general code approach will see (few) implementations via DRM!

Agreed on that and hoping also that gentle admonitions to avoid modifying the registers not be met with complaints of harsh treatment.

Robert

Thank you Robert and cb1. I shall try these out a couple of months later.

Merci et bon chance my friend, Ishan.  

In closing, "KISS" = API = "Faster, Easier, Better" Program Code.    Did we say "Far more robust, too?"

Managed to, "Stay on the icy road" (due to the API).   Noted multiple others, (sideways - in ditches) - each flying, "Viva DRM" as their "Rescue pennant..."   (rumor has it (apologies to Adele) that AAA and Amit's, "rescue hot-line" were both, "Off the hook busy...")