lpc1343 Capture Concern :(

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

lpc1343 Capture Concern :(

410 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ub3r on Sun Jul 08 03:06:28 MST 2012
Greetings,

Ive set up the capture on the 1343 like so:

LPC_SYSCON->SYSAHBCLKCTRL |= (1<<7);//enable clock CT16B0
//init io CT16B0_CAP0
LPC_IOCON->PIO0_2 = (1<<1)|(2<<3);     //CT16B0_CAP0 & pullup

LPC_TMR16B0->CTCR = 0;                //use timer mode
LPC_TMR16B0->CCR  = (1<<2)|(1<<0);          //rising, interrupt
RISING = 1;

LPC_TMR16B0->PR  = 71;                //prescaler 71
NVIC_EnableIRQ(TIMER_16_0_IRQn);         //enable interrupt
LPC_TMR16B0->TCR  = 1;    



Basically i want to read the input pulse width. Ranges from 1000us to 2000us.

My capture interrupt is below:
//read width
void TIMER16_0_IRQHandler(void)
{
if(LPC_TMR16B0->IR & (1<<4))            //capture interrupt?
{
LPC_TMR16B0->IR |= (1<<4);            //reset capture interrupt

if(RISING)//Rising Edge
{
LPC_TMR16B0->TC = 0;                    //reset timer
LED_ON;

LPC_TMR16B0->CCR  = (1<<2)|(1<<1);             //falling
RISING = 0;
}

else//Falling Edge
{
P_WIDTH = LPC_TMR16B0->CR0;        //read time
LED_OFF;

LPC_TMR16B0->CCR  = (1<<2)|(1<<0);             //rising
RISING = 1;
}
}                                         //end capture interrupt
}


Basically, on the rising interrupt im clearing the timer, and on the falling interrupt I'm capturing the timer value in P_WIDTH.

My only concern is if the interrupt is delayed due to some other interrupt, TC wont be cleared exactly on the rising edge, and I will have a slight inaccuracy, which i don't want.

How can i overcome this??
0 Kudos
7 Replies

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ub3r on Wed Jul 11 21:34:50 MST 2012

Quote: elef
ub3r, i had the same problem. I'm used to having more advanced timers on my MCU's where you can also clear the timer on capture.
Anyways, easy solution, but it uses more memory (a tiny bit of ram and flash, but i assume you have heaps spare):
[B]Don't clear the timer.[/B] Each time you enter the interrupt, subtract the previous interrupt value from the new one. Then save the new one to overwrite the old one before you exit the interrupt.
Then you might need to take care when it wraps around, but if you use "unsigned short int" (size needs to match your timer size, so unsigned int for 32 bit timer) you should be ok...



Very good idea. Ill try implement it in the next few days and let you know how i go. :)
0 Kudos

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by elef on Tue Jul 10 16:50:58 MST 2012
ub3r, i had the same problem. I'm used to having more advanced timers on my MCU's where you can also clear the timer on capture.
Anyways, easy solution, but it uses more memory (a tiny bit of ram and flash, but i assume you have heaps spare):
[B]Don't clear the timer.[/B] Each time you enter the interrupt, subtract the previous interrupt value from the new one. Then save the new one to overwrite the old one before you exit the interrupt.
Then you might need to take care when it wraps around, but if you use "unsigned short int" (size needs to match your timer size, so unsigned int for 32 bit timer) you should be ok...
0 Kudos

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by frame on Mon Jul 09 06:24:06 MST 2012
From my understanding, you still have a 12 clock cycle jitter.

If your high-priority Timer16 interrupt arrives during another interrupt of lower priority, the context is not saved again, 'skipping' this 12 clock cycles you usually need when interrupting normal user code.

Am I correct ?
0 Kudos

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ub3r on Sun Jul 08 04:22:23 MST 2012
Zero your my Hero :D :D.
Thx for the confirmation.
0 Kudos

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Sun Jul 08 04:14:49 MST 2012

Quote: ub3r
My understanding is that we still have to wait (even when we set a high priority) until the CPU exits the current ISR... Which can cause a slight delay depending on the size of the current ISR. 

Or am i wrong??



High priority interrupts interrupt low priority interrupts :rolleyes:

Also mechanisms like "Late Arriving Interrupt" are reducing your interrupt latency :)

There are several pictures at arm.com showing this NVIC features.

See also http://support.code-red-tech.com/CodeRedWiki/ArmCpuInfo
0 Kudos

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ub3r on Sun Jul 08 03:23:50 MST 2012
My understanding is that we still have to wait (even when we set a high priority) until the CPU exits the current ISR... Which can cause a slight delay depending on the size of the current ISR. 

Or am i wrong??
0 Kudos

365 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Sun Jul 08 03:11:19 MST 2012
Interrupt priority :confused:

See: http://knowledgebase.nxp.com/showthread.php?t=2876
0 Kudos