LPC1788 Interrupt Speed Increase

lpcware · ‎06-15-2016

Content originally posted in LPCWare by irvind on Sun Dec 30 19:26:24 MST 2012
Hi,

I would need help on LPC1788 interrupt speed.

Is there any way we can increase interrupt speed of MCU? Or how to calculate interrupt speed of my MCU?

I have some missing pulse when MCU triggered with some high speed signal. If I slow down my pulse speed, I see more triggered count than using machine speed.

Currently my MCU running at 120MHz. I have changed peripheral clock from 60Mhz to 120Mhz but it doesn't help in this case.

#define PCLKSEL_Val 0x00000001 //0x00000002

Please advise. Thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Dec 31 22:55:20 MST 2012
And last but not least:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337g/DDI0337G_cortex_m3_r2p0_trm.pdf:

Quote:

Figure 5-2 shows that there is a [COLOR=Red]12-cycle latency[/COLOR] from asserting the interrupt to the first instruction of the ISR executing.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by micrio on Mon Dec 31 22:35:07 MST 2012
There are a number of factors that go into the speed that interrupts are handled.
How many registers must be pushed before the interrupt code can be run.
How is the code aligned in memory which affects how fast the cache will
operate.   How complicated is your interrupt handler.   If you are the single
the highest priority then you should not be blocked by other interrupts.

Does any code disable interrupts.   Are you using locking which might
block interrupts?   Are you calling any library functions that might block
interrupts?

That is probably not an exhaustive list but that is all that I can
think of now.   It becomes somewhat tricky when you are trying to count
machine cycle times.    You could use the CPU clock cycle counter
to help you time these things.

Pete.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by irvind on Mon Dec 31 19:47:01 MST 2012

Quote: micrio
If you are concerned if you might not be fast enough they you should try
polled mode and count the pulses. If you still miss some then either they
are too fast for a 120 MHz CPU or you have hardware problems.

If it passes that test then try your interrupt routine. If the interrupt routine
is not fast enough then try moving it into RAM which will save on the
wait states imposed by FLASH.

Best of luck,
Pete.

Thanks pete for your reply.

So there is no parameter or specification to tell the speed of GPIO interrupt?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by micrio on Mon Dec 31 14:42:26 MST 2012
If you are concerned if you might not be fast enough they you should try
polled mode and count the pulses. If you still miss some then either they
are too fast for a 120 MHz CPU or you have hardware problems.

If it passes that test then try your interrupt routine. If the interrupt routine
is not fast enough then try moving it into RAM which will save on the
wait states imposed by FLASH.

Best of luck,
Pete.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by irvind on Mon Dec 31 12:06:04 MST 2012

Quote: TheFallGuy
First, look at the maximum frequency of your pulses. Is it possible to service those quickly enough?

Next, look at your interrupt handling code. Make sure you are doing the minimum amount of processing possible.Also:
- clear the interrupt early, so another pulse can cause an interrupt
- before returning from your handler, look to see if another is pending and service it (this will save a small amount of time - although Cortex-M parts do tail-chaining, so it doesn't stack and unstack registers unnecessarily)

Hi FallGuy,

Thanks for your reply.

my input signal varies from time to time based on machine speed, so I can't give an exact speed right now. Currently I just increase a counter in ISR to check if any missing pulse.

I would like to know if any parameter to configure GPIO interrupt speed? How to calculate the fastest interrupt speed of GPIO?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Mon Dec 31 02:06:13 MST 2012
First, look at the maximum frequency of your pulses. Is it possible to service those quickly enough?

Next, look at your interrupt handling code. Make sure you are doing the minimum amount of processing possible.Also:
- clear the interrupt early, so another pulse can cause an interrupt
- before returning from your handler, look to see if another is pending and service it (this will save a small amount of time - although Cortex-M parts do tail-chaining, so it doesn't stack and unstack registers unnecessarily)