LPC MicrocontrollersのトピックRe: LPC1114 Timer resolution issue

LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:13 GMT

Content originally posted in LPCWare by jschimpf255 on Mon Jan 26 11:30:14 MST 2015
Hi,
I am using the the 32 bit timer03 in the chip with a 48 MHz clock, minimum resolution with a prescale of 1 should be about 20 ns. I am attempting to generate ticks at about 500 ns. I set it up like this:

Chip_TIMER_Init(LPC_TIMER32_0);

/* Timer rate is system clock rate */
timerFreq = Chip_Clock_GetSystemClockRate();

// Set up for match at 500 ns intervals

Chip_TIMER_Reset(LPC_TIMER32_0);
Chip_TIMER_PrescaleSet(LPC_TIMER32_0, 1);
Chip_TIMER_MatchEnableInt(LPC_TIMER32_0, 1);
val = (timerFreq /2000000);// 500.0 nsec = 48,000,000/2,000,000
Chip_TIMER_SetMatch(LPC_TIMER32_0, 1, val);
Chip_TIMER_ResetOnMatchEnable(LPC_TIMER32_0, 1);
Chip_TIMER_Enable(LPC_TIMER32_0);

/* Enable timer interrupt */
NVIC_ClearPendingIRQ(TIMER_32_0_IRQn);

The match value is 24 which should give me the 500 ns ticks I need.

I am using this in a program running under FreeRtos. I want to get 4 500 ns ticks to generate a waveform then I disable the timer till I need it again. I start it like this:

Chip_TIMER_Reset(LPC_TIMER32_0);
NVIC_EnableIRQ(TIMER_32_0_IRQn);

It then begins to call an interrupt routine. In that routine for testing now, I have it turn on GPIO 7 on entrance and then turn it off on exit.

When I run this and observe the GPIO 7 toggles on a scope I cannot get less than about 2.5 micro second period between the toggles. (this is trying all sorts of smaller values than 24 also) Is there some overhead in FreeRtos should I be using a different timer # or the 16 bit timers ?

Thank you very much for your help.

--jim schimpf

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:13 GMT

Content originally posted in LPCWare by starblue on Tue Jan 27 03:06:56 MST 2015
Your processor is not fast enough for that:

http://community.arm.com/docs/DOC-2607

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:14 GMT

Content originally posted in LPCWare by jschimpf255 on Tue Jan 27 10:07:18 MST 2015
Thank you very much for the very useful article.

     From the article there are about 16 (15 ?) cycles of latency for the LPC1114 which is about 320 ns. Also looking at the example in the LPC1114 manual (21.8.1 figure 81) they show an interrupt happening in 12 clock cycles (~ 240 ns). This should mean with those settings I should be able to generate an interrupt in 560 ns or even faster with prescale = 1.

     The closest time between ticks I can get is about 1400 ns. Is there additional software overhead beyond 16 cycles of latency ? Should I try to run this with FreeRtos turned off or up the priority of my timer interrupt ? I realize the latency puts a lower limit of about 320 ns but I would like to get closer than 1400 ns. Also my interrupt routine is very bare bones doing:

void TIMER32_0_IRQHandler(void) <- 16 cycles of latency to here right ?
{
// Clear status

Chip_TIMER_ClearMatch(LPC_TIMER32_0, 1);   <- This point timer should start next count ?

// Blip scope
Chip_GPIO_SetPinState(LPC_GPIO, 0, 7, 1);

Chip_GPIO_SetPinState(LPC_GPIO, 0, 7, 0);

}   <-- Does this take another 16 cycles ?

On the scope the blip is very short and there is a relatively long time before the next one. I.e. > 500 ns before the next one. (sorry don't have a picture but I can get one later.) I will put blip markers around the clear match routine and see how long that takes. I should set the GPIO 7 high on entrance and low on exit to see how long the int routine really takes.

And perhaps enable the external interrupt so I can see what that occurs and that would measure the latency.

Wow, you and the article have given me much to do with the scope.

Thank you again for your help.

--jim schimpf

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:15 GMT

Content originally posted in LPCWare by TheFallGuy on Tue Jan 27 10:14:15 MST 2015
Don't forget that the article assumes a 'perfect' (0 wait-state) memory system. When running from flash, you are going to introduce some wait states (1?) and pipeline flushes (when doing a branch etc).

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:15 GMT

Content originally posted in LPCWare by R2D2 on Tue Jan 27 10:23:06 MST 2015

Quote: jschimpf255
...have given me much to do with the scope.

Looking at the disassembly of your interrupt will surprise you how many cycles are required to set / reset your pin :O

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:16 GMT

Content originally posted in LPCWare by jschimpf255 on Wed Jan 28 02:02:56 MST 2015
Hi,
Yes I did some more testing, did not look at the timer int out pin but found that just setting/clear interrupt & clear the pin took 254 ns. When I added in the code I needed to do my work I got 2.1 us so you are quite right, need a faster processor.

Thanks again for the guidance.

--jim schimpf

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:16 GMT

Content originally posted in LPCWare by starblue on Wed Jan 28 02:34:23 MST 2015
Maybe you can do it in straight line code by counting cycles for timing (see the ARM Cortex-M0 technical reference manual). Putting the code in RAM could help to get it fast enough and remove uncertainties about wait states for flash.

Maybe you could use some hardware unit to generate your waveform, e.g. shift it out from SPI.

Maybe an SCT could do it (not available on LPC1100, but AFAIK on all newer LPC controllers).

Re: LPC1114 Timer resolution issue

lpcware — Wed, 15 Jun 2016 19:45:18 GMT

Content originally posted in LPCWare by jschimpf255 on Wed Jan 28 06:43:20 MST 2015
Hi,
I have bit banging routine now that runs ints off/Freertos off and uses inline assembly delay code. This works OK. But I want to do it a bit more elegantly.

I think I might be able to do a hybrid version, use the timer to generate a period I can get (~ 2.5 usec) and then use the asm delays inside the int routine to do the fast bit twiddling.

Will let you know how this works out....

--jim schimpf