www.coridium.us/forum

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)

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

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

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