quadrature encoder

Since your question is severely short and lacking the most basic details to even start concocting any meaningful reply, I can only suggest you this: http://bfy.tw/3bkD

One hint, though: usually the Code Composer Forum is not where example code is made available - the device forums are more suitable for that.

I need to find velocity,position and direction of a motor.But my code is not giving currect velocity.I have given the code
below(for TM4C129NCPDT)Can you please help me with this code?

volatile int qeiPosition,qeiDirection,qeiVelocity;
int main(void)
{

SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN |SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOL);
SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI0);
GPIOPinConfigure(GPIO_PL1_PHA0);
GPIOPinConfigure(GPIO_PL2_PHB0);
GPIOPinTypeQEI(GPIO_PORTL_BASE, GPIO_PIN_1 | GPIO_PIN_2 );
QEIDisable(QEI0_BASE);
QEIIntDisable(QEI0_BASE,QEI_INTERROR | QEI_INTDIR | QEI_INTTIMER | QEI_INTINDEX);


QEIConfigure(QEI0_BASE, (QEI_CONFIG_CAPTURE_A_B | QEI_CONFIG_NO_RESET | QEI_CONFIG_QUADRATURE | QEI_CONFIG_NO_SWAP), 10000000);
QEIEnable(QEI0_BASE);


QEIPositionSet(QEI0_BASE, 5000000);
QEIVelocityConfigure(QEI0_BASE,QEI_VELDIV_1,100000);
QEIVelocityEnable(QEI0_BASE);


while (1)
{
qeiPosition = QEIPositionGet(QEI0_BASE);
qeiDirection=QEIDirectionGet(QEI0_BASE);
qeiVelocity=QEIVelocityGet(QEI0_BASE);
}
}

Hi,

As mentioned before, unfortunately we here in the CCS forum are not the best place to provide advice on application code. I will then move this thread to the Tiva device support, as the experts and the community there will be able to provide more insightful answers.

Regards,
Rafael

Hello Jithin,

QEIEnable(QEI0_BASE); should be the last API execution when configuring the QEI peripheral

Also what is the input to the QEI looking like? Also is Velocity read out the only issue or is Position and Direction also not being read out?

Regards
Amit

"Also what is the input to the QEI looking like? Also is Velocity read out the only issue or is Position and Direction also not being read out?"

For example - can you better describe your "homework assignment?"

Hello Amit,

The input to the QEI is from 2  HES sensors.

irection and position is working fine.Velocity is the only issue issue.

Also if I put QEIEnable(QEI0_BASE); at the  end then QEIPositionSet function is not executing.

so I have written like this

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

QEIVelocityConfigure(QEI0_BASE,QEI_VELDIV_1,100000);

QEIVelocityEnable(QEI0_BASE);

QEIEnable(QEI0_BASE);

QEIPositionSet(QEI0_BASE, 5000000);

Also can you tell me more about QEIVelocityConfigure function and its arguments.I read the peripheral driver library

but i am not getting it completly .

Hi Amit.

I do not use APIs. I use direct register access programming method.
Following may be helpful to you. It gives rpm, position and velocity correctly.
Mostly pseudocode will be helpful.

void QEI_Init(void)
{
unsigned long delay;
SYSCTL_RCGCQEI_R|=(1<<0); // enable QEI Module 0 clock
SYSCTL_RCGC2_R |= 0x00000008; // 1) D clock
GPIO_PORTD_LOCK_R = 0x4C4F434B ; //Unlock PD7
GPIO_PORTD_CR_R = 0xF0; // allow changes to PD7-4
GPIO_PORTD_AMSEL_R = 0x00; // 3) disable analog function
GPIO_PORTD_PCTL_R = (GPIO_PORTD_PCTL_R&0x00FFFFFF)|0x66000000; // 4) GPIO clear bit PCTL
GPIO_PORTD_DIR_R &= ~((1<<7)|(1<<6)); // 5) PD7,PD6 input
GPIO_PORTD_AFSEL_R |= (1<<7)|(1<<6); // 6) no alternate function
GPIO_PORTD_DEN_R = 0xF0; // 7) enable digital pins P7-4

//pd6,7
QEI0_CTL_R |=(1<<3)|(1<<4)|(1<<5) ; //enable capture mode, reset mode, velocity mode
QEI0_MAXPOS_R = 0x00000F9F; // maximum position for my 2048 ppr encoder
QEI0_LOAD_R = 20000000; // load value to calculate rpm
QEI0_CTL_R |= (1<<0); // enable qei module 0.
}

Hello Ishan

While DRM code works for you, I (and others on the forum) disagree with the use of it unless required for a very strong reason. The code may be simple looking but as you build on this code, it is very tough to maintain and debug.

Regards
Amit

"Disagree" is a strong word. All have preferences. I wanted to study 32-bit ucontroller so I did it. You are ryt about " The code may be simple looking but as you build on this code, it is very tough to maintain and debug."

Pseudocode represents exactly what your APIs do. Don't see DRM if you do not want.

Hello Ishan

I need to clarify that, TivaWare uses register macro definition and not DRM, but then the API are tried and tested over time and not something developed recently.

Anyways, since you have noted that I am using strong words (since I have seen the same argument for use of DRM) not to your liking, I would gladly not interrupt your posts and thoughts.

Regards
Amit

May I add a voice (and vote) in support of Amit's position?   And - if anyone is entitled to "disagree" w/the general use of "DRM" - that person clearly is Mr.  Ashara.  

This forum is tasked w/serving a large volume of users - anything which complicates, extends, & forces extra effort upon Amit - cannot be good.   Long ago we were taught to, "reason/probe toward the limit."   (this w/in college chemistry)   Adapted here - should the majority of users adopt your (preferred) DRM code style - Amit's (and other's) response rate will spectacularly decline.   Can that be good?

Now there are times when fast code, or more compact code provides key advantage.   But in your example - the "one-time" set-up/config of QEI Registers - that benefit pales.   (and the degree of difficulty/complexity rises, exponentially.)

As Amit noted - the API is broad, extensive, and supremely "time-tested."    And DRM?    Every use proves an adventure - prepare to spend vast (added) amounts of time turning MCU manual pages - in search of the "exact" Registers which are required.   And then, "Read, Understand, and Program - each/every one of those (mostly) 32 bit registers - to perfection.

As a small, tech biz owner - staff/I apply the, "Ten foot pole rule" to DRM.     (i.e. Kidz - Do NOT try this (DRM) @ home!)

Perhaps "disagree" was too "gentle" a word...

Hello Amit,
I am working with Jithin k joy, we need the QEI for measuring the speed of a motor coupled with two Hall effect sensors. The Magnetic wheel has 36 poles. The Sensors will give signals of 90-degree phase shifted waveform as required by QEI.
My doubt is how fast can the velocity be calculated? Because the motor is running at 0 to 2000 or 3000 RPM Max.
If the velocity calculation happens very fast, the number of interrupts will be too low to calculate.
for example, as I calculated, if my motor is running at 10000RPM, I will get only 12 interrupts in 1ms time frame( rising edge and falling edge interrupts of both sensors). As the motor is only at 3000RPM Max, I will get only 3 are 4 interrupts in 1 ms time. this resolution is too low to calculate the velocity.

No.Of poles in magnetic disk = 36
total rising and falling edge interrupt of 2 sensors = 36*2= 72
At 10000RPM no of interrupt per minute = 10000*72 = 720000
At 10000RPM no of interrupt per millisecond = 720000/(60*1000) = 12
Thus approximately at 3000RPM, I will get only 3 or 4 interrupts in 1ms.If the velocity calculation happens still faster, velocity can't be updated properly.

For still slower speed no interrupt will come in 1ms and the velocity calculation is not possible.

Am I Correct? 

Please Clarify my doubts.

Thanking you in advance.
SubaAnanthan T

and for still slower speed no interrupt will come in 1ms 

subaananthan T said:

No.Of poles in magnetic disk = 36
total rising and falling edge interrupt of 2 sensors = 36*2= 72

Pardon - but believe I've spotted a rather large mistake.   Is it not true that ONE magnet - passing one hall sensor - will generate TWO Interrupts?      If so - your "72" result is one-half of that expected!

You argue that, "Velocity can't be updated properly" w/3 or 4 interrupts in 1mS.    Yet you do not define that (ever) elusive, "Proper Update!"

My firm has produced advanced BLDC Motor Control Systems for past 5 years - we find 1mS update rate adequate - in most all circumstances.

In the event 1mS proves inadequate - would not your INCREASING the number of hall sensors be an (obvious) and simple, means of improvement?