This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

QEIs in Velocity mode - not same counts per revolution

Other Parts Discussed in Thread: LM3S1968, TM4C123BE6PZ

I've moved code from the LM3S1968 to the TM4C123BE6PZ. I am using QEI 0 and QEI 1 in Velocity mode. QEI 0 is always half the number of counts of QEI 1 when the encoders travel the same distance. What am I doing wrong/different? Here is the initialization code:

void quadInit (void)
    // Configure the encoder A & B pin for use by the QEI block. 
    // The encoders have no Index signal so those inputs are not used.
    ROM_GPIOPinConfigure(GPIO_PF0_PHA0);  // new for TM4C parts
    ROM_GPIOPinTypeQEI(GPIO_PORTF_BASE, GPIO_PIN_0);  // X encoder - channel A
    ROM_GPIOPinTypeQEI(GPIO_PORTF_BASE, GPIO_PIN_1);  // X encoder - channel B
    ROM_GPIOPinTypeQEI(GPIO_PORTG_BASE, GPIO_PIN_0);  // Y encoder - channel A
    ROM_GPIOPinTypeQEI(GPIO_PORTG_BASE, GPIO_PIN_1);  // Y encoder - channel B

    // Configure the QEI block for capturing the velocity of the encoder A
    // pin (which it does by counting the number of edges during a fixed time
    // period).  May get twice the resolution by counting both edges...
    // Assume Regulated stand-up machine until pedal test run
                             QEI_CONFIG_STALLEN | QEI_CONFIG_QUADRATURE |
                             QEI_CONFIG_FILTEN | QEI_CONFIG_NO_SWAP), 0xffffffff);
    // Set sample rate (QEI_INT_RATE)
    // (SysCtlClockGet() will return 66.667 MHz.)
    // This confuses me every time I come back to it: xQEI_INT_RATE is
    // how many times per second you want the interrupt to occur.
    // Set up for foot pedal machine
    // If no foot pedal is attached, it will change to regulated machine.
    // If display/handles ask for Presets, it will remain foot pedal machine
    ROM_QEIVelocityConfigure(QEI0_BASE, QEI_VELDIV_1, ROM_SysCtlClockGet()
                             / QEI_INT_RATE);
    // Enable the QEI blocks and the velocity capture modes.
    ROM_QEIPositionSet(QEI0_BASE,0);            // set up the absolute position counters

    // same for QEI1
                             QEI_CONFIG_STALLEN | QEI_CONFIG_QUADRATURE |
                             QEI_CONFIG_FILTEN | QEI_CONFIG_NO_SWAP), 0xffffffff);
    ROM_QEIVelocityConfigure(QEI1_BASE, QEI_VELDIV_1, ROM_SysCtlClockGet()
                             / QEI_INT_RATE);

    ROM_QEIPositionSet(QEI1_BASE,0);                  // for Pro-Stitcher record function
    // Enable the QEI velocity interrupts.


Any help would be appreciated. For now I am simply doubling the counts on the errant channel but I'd like to do it right.


  • Hello gkonzak,

    PF0 is a locked pin, so you need to unlock it first before you can Configure it

    Please see the following post



  • Crumb, I thought I looked at that. Duh!

  • Amit Ashara said:
    PF0 is a locked pin

    Perhaps not as, "locked" as claimed!  (again - why do I note these things - rarely others?)

    If truly, "locked" - how would we explain the acceptance of, "one-half" of the (likely) arriving QEI input signals?  (that's exactly as this poster reported - while PF0 remained in default NMI mode.)

    Does not this deserve some analysis - explanation?  Can PF0 truly be believed - counted upon?  Long term?

    We've long noted that setting PF0 into "Analog Comparator Output" mode works well - with NO/ZERO "unlocking."  Like good, "idol worshippers" we dutifully "unlock" - yet that appears "unnecessary" when PF0 deployed as Ana Comp Out.  We've noted this "PF0-Ana Comp Out" effect across multiple LX4F and at least one "flavor" of TM4C...

  • PF0 is only one of the two signals, but depending on the decoder design, it can either register increasing counts as PF1 pulses, or it can toggle back and forth between a + count and a - count (proper gray scale encoding). I found the decoders on the LM3S and now TM4C parts to be of the former variety and serviceable for my needs. But yeah, seems it could use some tweaking. I'm sure there are bigger fish to fry like those large Flash and RAM parts promised last year for 2nd quarter this year. Still waiting...