Quadrature

[GKDarin]

I have been searching the web looking for examples to try to implement the QEI functions.

The chunk of code below, gets you the encoder position and was mostly copied from a message on the ArmExpress Site.

The QEICAP in the Print Routine will report the number of pulses seen in the Time period specified in QEITIME and QEILOAD.


#include "LPC17xx.bas"

' Quadrature Encoder Interface Testing Program 7/19/12 DG
DIM POSITION As Integer
Dim RPM as Integer

SUB INIT

SCB_PCONP = SCB_PCONP or (1<<18) 'enable QEI bit in power/clock register (PCONP)
PCB_PINSEL3 = PCB_PINSEL3 or (1<<8) 'Set pin P1.20 mode for PH A
PCB_PINSEL3 = PCB_PINSEL3 or (1<<14) 'Set pin P1.23 mode for PH B

QEICON = QEICON or 1 'clear position
QEIMAXPOS=256 'The number of Pulses for one revolution of the encoder.

QEITIME=10000000 'Initial Sample time for
QEILOAD=10000000

ENDSUB

MAIN:

INIT

Do
POSITION = QEIPOS
Print POSITION,QEICAP
WAIT (100)

Loop


END


I'm trying to find the RPM of the encoder shaft, the documentation below describes a Variable PCLK.

My question today is:

Is there a variable in LPC17xx.bas that contains this clock value?

RPM = (PCLK * QEICAP * 60) ÷ (QEILOAD * PPR * Edges)
where:
• PCLK is the peripheral clock rate for the QEI block. See Section 4.7.3 for more on the
possibilities for PCLK).
• QEICAP is the captured velocity counter value for the last velocity timer period.
• QEILOAD is the velocity timer reload value.
• PPR is the number of pulses per revolution of the physical encoder used in the
application
• Edges is 2 or 4, based on the capture mode set in the QEICON register (2 for
CapMode set to 0 and 4 for CapMode set to 1)

[basicchip]

PCLK is the peripheral clock. In the PROplus and SuperPRO this is 24 MHz (1/4 of the CPU clock)

[GKDarin]

How would one go about handling the timer overflow for the Velocity capture.

I am having trouble getting enough resolution out of the RPM calculation with the method in the above post.

I would like to have the RPM calculate in an INTERRUPT SUB each time the timer overflowed and store it in a RPM variable in the MAIN loop.

Even with QEITIME 's of 2,000,000, RPM measurements are incrementing in about 6 RPM increments.

Using a 256 pulse per rev encoder, testing at 0-600 rpm. The task at hand would actually only run at 0-150 rpm, or 38,400 pulses per second.

Would like to see RPM's calculated accurately measured down to 0.1 RPM.


Thanks,
Darin

[GKDarin]

Oops, that 38400 pulses per minute, 640 per second at full speed.

Actual running speed for the important measurements would be about 300 to 500 per second.

Thanks,
Darin