CCS/EK-TM4C123GXL: QEI electrical interface

Hello William,

That doesn't sound right, as far as I was aware, the QEI pins should be low.

Can you share the code for the setup of the GPIO and QEI peripherals? I can test on my LaunchPad if you can offer that.

Hi Ralph,

Oh that was quick. It’s code I stole from somewhere else.

void read_Encoder(void)

{

   // Set the clocking to run directly from the crystal.

   SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

   // Enable QEI Peripherals

   SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

   SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI0);

   //Unlock GPIOD7 - Like PF0 its used for NMI - Without this step it doesn't work

   HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY; //In Tiva include this is the same as "_DD" in older versions (0x4C4F434B)

   HWREG(GPIO_PORTD_BASE + GPIO_O_CR) |= 0x80;

   HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;

   //Set Pins to be PHA0 and PHB0

   GPIOPinConfigure(GPIO_PD6_PHA0);

   GPIOPinConfigure(GPIO_PD7_PHB0);

   //Set GPIO pins for QEI. PhA0 -> PD6, PhB0 ->PD7. I believe this sets the pull up and makes them inputs

   GPIOPinTypeQEI(GPIO_PORTD_BASE, GPIO_PIN_6 | GPIO_PIN_7);

   //DISable peripheral and int before configuration

   QEIDisable(QEI0_BASE);

   QEIIntDisable(QEI0_BASE,QEI_INTERROR | QEI_INTDIR | QEI_INTTIMER | QEI_INTINDEX);

   // Configure quadrature encoder, use an arbitrary top limit of 1000

   QEIConfigure(QEI0_BASE, (QEI_CONFIG_CAPTURE_A_B | QEI_CONFIG_NO_RESET | QEI_CONFIG_QUADRATURE | QEI_CONFIG_NO_SWAP), 1000);

   // Enable the quadrature encoder.

   QEIEnable(QEI0_BASE);

   //Set position to a middle value so we can see if things are working

   QEIPositionSet(QEI0_BASE, 500);

   //Add qeiPosition as a watch expression to see the value inc/dec

//   while (1) //This is the main loop of the program

//   {

//       qeiPosition = QEIPositionGet(QEI0_BASE);

//       SysCtlDelay (1000);

//   }

}

Hello again,

Do note - crack/young staff have (already) resolved your issue - post or two up!

As we suspected - the QEI Module configuration (defaults) to 'weak pull-ups.'

Should the encoder output be push-pull - it is almost surely a stronger output - & no 'output to output' contention will result...

Hi cb1,

Excellent & prompt work by your staff, thank you!!

William,

To change the functionality, I would recommend using a GPIOPadConfigSet API call after GPIOPinTypeQEI to set the right resistor setup.

Hello cb1_mobile.

I am very grateful to your crack young staff. Forgive me if I’ve misunderstood but I think what they are saying is that if the GPIO pin has ~3.3 V on it and the output of the encoder is ~5V current will flow from the hotter to the colder?

Hello Ralph,

Staff/I note (even FASTER) forum response by YOU!

We have (much) experience w/Encoders - even now 'Design/Develop/Produce' our own.   (Magnetically based!)   (HP held the patent for 'Optically based' - for so long...)

Should poster William have, 'Read this far' - staff advises that at 'High-Speed' - the MCU's pull-up resistors prove "Too high in value" - and if (any) capacitance (even worse inductance) intrudes upon the signal path - your signals will become 'rounded' - and may be 'missed' by the MCU!   

A "Push-Pull" encoder (as we produce) is thus a superior choice when "High Rotation Shafts" are to be monitored.    (Note: most all MCUs (i.e. even from other vendors) also provide (only) high resistance, internal pull-up/down resistors - which while convenient - "Win no Awards" where performance is desired.)

Hello to our (possibly/one time) Aussie friend,

William Herschel said:

I think what they are saying is that if the GPIO pin has ~3.3 V on it and the output of the encoder is ~5V current will flow from the hotter to the colder?

It is hoped that they did (not) say that!

• While the MCU notes 'acceptance of 5V levels' - our long term testing (and that of our giant clients) - causes our 'discomfort' w/such usage.    Simple voltage divider (2 resistors) properly 'mates' the encoder's output to the MCU.   (you must implement for all 3 encoder channels.)
• We don't believe that leaving the pull-up Rs (as is) will prove harmful - but as your encoder appears "Push-Pull" (you should check, btw) no harm should result if they remain

Note that your original desire was to 'understand' the "potential for conflict between 2 voltage sources" - and crack staff has (rather convincingly) resolved that - have they not?   (i.e. time for Rewarding   (their) efforts... they even found & presented the code block focused upon your concern...)

Yes I have (Read this far) and am indebted to your great knowledge and expertise. I will monitor the signals over the speed range I intend to use.

Good that - yet ours is 'team knowledge' - I learn as much from this gifted crüe as I (attempt) to impart...

Should not our 5:33 post be 'bathed in Green' - so that (future) readers may identify that post which RESOLVED your Issue?

(Vendor/Friend Ralph was good enough to award 'Suggested' - yet the (5:33) post warrants RESOLVED - which properly rewards young staff...)

[edit]  18:55 CST - Poster William has been good enough to award, 'This Resolved' - Staff & (not quite) 'fearless' leader are thankful...

BTW I forgot to also thank you for expanding my vocabulary with the addition of crüe

William Herschel said:

expanding my vocabulary with the addition of crüe

Good that - crack staff & I are pleased and may (even) suggest the addition of "motley."     (which our majority gurl staff are 'Not' - having, "Talked their way out of (another) Speeding Ticket" earlier this morn.   With 4 of them in the car - and their penchant for 'creative problem solving' - police "warn" - then 'Send them on their (unticketed) way!'    Our few male staffers (including moi) ... would likely "Do Time" for 25+ over-limit) 

Crüe appreciates your 'award' and offers (another) encoder-based post for your 'Non-Vocabulary' (i.e. Tech) expansion!    

https://e2e.ti.com/support/microcontrollers/other/f/908/t/871858

cb1_mobile said:

Is it not likely that your "configuration of the MCU's QEI module" accounts for that?     This proves so as not all encoders provide "Push-Pull Outputs" (substituting OD "Open Drain" instead.)    As OD can only 'Pull down' the MCU's QEI hardware (thoughtfully) supplies the pull-up resistors.    (Against which - the encoder can 'Pull Down' or (even) 'Swamp' the pull-ups weak current.)

To that, I would add, that unless your quadrature-signal-producing device is another IC on the same circuit board as the MCU, I would never connect MCU pins directly to a QEI. If the pins are being exposed to a connector and the QEI is on the other end of a cable, then there should be appropriate interface electronics to clean the signals and protect against ESD and other sources of "fun."

Poster "12/twelve" (i.e. '12 squared') almost (cleverly) suggested that your encoder signals prove 'motley.'     (Would a (real) 'créatif' have 'missed' that?)

Your vocabulary additions appear to have proved worthwhile...