• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 1322 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

QEIVelocityGet() Pulses vs. Edges

Vadim Lazarev
Prodigy 60 points
Other Parts Discussed in Thread: EK-TM4C123GXL

Hello everyone :)

I’m using QEI peripheral on ek-tm4c123gxl and TivaWare v2.1.3.156.

Overview of problem:

When following the API instructions to calculate velocity, the result is double of what is expected.

Detailed problem description:

The API documentation entry for QEIVelocityGet() states that, “The value returned is the number of pulses detected in the specified time period.” This function returns the contents of register QEISPEED. The datasheet description for QEISPEED register (page 1321) similarly states that it contains “the number of velocity pulses counted in the previous velocity timer period.”

But the “Functional Description” of QEI (section 21.3 on page 1308) of the datasheet states that “The edge count from the previous time period is available to the controller via the QEI Velocity (QEISPEED) register. . . . As soon as the current time period is complete, the total number of edges counted in that period is made available in the QEISPEED register”.

So when I divide by number of edges per revolution instead of pulses, the answer matches my calculations from the oscilloscope readings. 1 pulse = 2 edges.

Or maybe I’m missing something else entirely?

Thanks for your feedback.

  • 0
    TI__Guru**** 244400 points
    Hello Vadim,

    What is value of the QEICTL register that you are using and what signals from the QEI module are connected (PhA and/or PhB and/or Idx)?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 60 points

    Thank you for such a quick reply.

    QEICTL register returns the following: 0bx00000000000000000000000000101001 when polled with HWREG(QEI0_BASE + QEI_O_CTL);

    I am using PhA and PhB, but not the Index signal.

    These are some of the main configurations:

    SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN); // SysCtlClockGet() yeilds 50,000,000

    GPIOPinTypeQEI(GPIO_PORTD_BASE, GPIO_PIN_6 |  GPIO_PIN_7);

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

    QEIVelocityConfigure(QEI0_BASE, QEI_VELDIV_1, 10000000);

    QEIPositionSet(QEI0_BASE, 500);

  • 0 in reply to Vadim Lazarev
    Guru 117855 points

    May I commend poster for a simply terrific, well thought, and attractively presented posting. Very well done.

    PD_7 is "in play" here - and is not that pin one of two - "delightfully burdened" w/NMI as its default? (there's no mention of that pin's "unlocking.") Yet - w/the report of, "Double the expected number" pin PD_7 appears to be properly configured.

    Language is very important - pulses and edges have distinct meaning - one wonders if the tech writer(s) [driven hard by marketing] may have (at least once) confused the two.

    If possible - can you connect to & properly drive the "Index" input.   (we realize that your encoder (or similar) may not include such - yet that index signal does prove of value - and should be added to determine if it prevents your noted "double count.")

    As a past tech writer - it may be that different individuals produced the MCU manual and later - the API.   (I suspect that's likely)   And - under time crunch - the (real) meaning of "pulse vs. edge" may have been confused...

  • 0 in reply to Vadim Lazarev
    TI__Guru**** 244400 points
    Hello Vadim

    In addition to what cb1 has mentioned, the fact that the GPIOPinConfigure is not there is also strange. I hope the above code was just copy-paste and not the actual code.

    Also did you replace QEI_CONFIG_CAPTURE_A_B with a single edge capture?

    Regards
    Amit
  • 0 in reply to cb1_mobile
    Prodigy 60 points

    Thank you cb1 for your feedback!

    Pin PD_7 has indeed been unlocked.

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY; 
HWREG(GPIO_PORTD_BASE + GPIO_O_CR) |= 0x80;
HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;

    As time permits, I will try incorporating the index signal.

  • 0 in reply to Amit Ashara
    Prodigy 60 points

    Thanks again, Amit.

    Yeah, pins have been configured. I should have probably included more than just snippets of code from the start. 

    GPIOPinConfigure(GPIO_PD6_PHA0);
GPIOPinConfigure(GPIO_PD7_PHB0);

    Changing _A _B to _A halves the output of QEIVelocityGet(QEI0_BASE); but I still have to divide by the halved number of edges instead of halved number of pulses to match my oscilloscope reading.

    I’m getting consistent results now, so I’m good to go.
    Thanks for all the help everyone!

  • 0 in reply to Vadim Lazarev
    TI__Guru**** 244400 points
    Hello Vadum

    PD7 is a locked pin. Have you unlocked the pin before re-configuring it for QEI? Please see the following post for more details

    e2e.ti.com/.../374640

    Regards
    Amit
  • 0 in reply to cb1_mobile
    Guru 47900 points

    cb1_mobile said:
    PD_7 is "in play" here - and is not that pin one of two - "delightfully burdened" w/NMI as its default?

    Issue identified far earlier...

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1

    Yes. My post was a re-emphasis of your observations

    Regards
    Amit