ISR vs. Timer

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AT32UC3L

 

Hi there,

 

Currently I am trying to measure the time consumption of an interrupt routine. How I (want to) do it:

 

1. Setting up a measurement unit using the timer/counter block TC0 CH1. With this TC the time of any kind of routine shall be measured by starting and than stopping its clock and then reading the value of its register (.cv => counter value);

2. Setting up an ISR of which the execution time shall be measured. The ISR shall be triggered by an external signal (I am using ExtInt1 for this purpose).

 

Well, having this set up it didn't work out as I thought.

 

Now, my question is: While processing the ISR, this will not affect any timer (in my case TC0 CH1)?!

 

My understanding is, that the timer/counter is running independently of the processor, so if an ISR is being processed it doesn't affect it. But what I currently see is, that the TC0 CH1 seems stop counting up while the ISR is being processed. It still can be a bug in my application. But after 3 hours seraching I still couldn't find any wrong implementation. Therefore I posted this question.

 

Cheers

 

Last Edited: Tue. Aug 27, 2019 - 07:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why dont you continue here:

 

https://www.avrfreaks.net/forum/...

 

you have a lot of threads, all connected to interrupt handling and ISR ? better to have it all in one place.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Not part of the Issue:)

 

Thanks for your input.

you have a lot of threads, all connected to interrupt handling and ISR ? better to have it all in one place.

Because the question resp. the focus of problem is an other one. The other one is about getting more necessary information where the datasheet leaks. This one here is about a specific understanding of how interrupt are supposed to work.

I hardly try to not mix different issues into the same. They are both about ISR thats true. But if topics shall be summarized into the same space, AVRFREAKS shall provide a dedicated space for ISR issues.​​​​​​​

Last Edited: Tue. Aug 27, 2019 - 09:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A thing I found is, that the external interrupt doesn't react on changing the edge detection configuration:

 

	eic_options_t eic_options = 
	{
		eic_options.eic_mode   = EIC_MODE_EDGE_TRIGGERED,
		eic_options.eic_edge   = EIC_EDGE_FALLING_EDGE,
		eic_options.eic_filter = EIC_FILTER_ENABLED,
		eic_options.eic_async  = EIC_SYNCH_MODE, /* For Wake Up mode, initialize in asynchronous mode */
		eic_options.eic_line   = EXT_INT_TIME_MEAS_LINE
	};

Changing the "eic_edge" to "EIC_EDGE_RISING_EDGE" the interrupt is still triggered on the falling one. frown??

 

This is my code: 

/**
 * \file main.c
 *
 * \brief Timing Measurement
 *
 */


#include <asf.h>


/*=== Interrupt Routines =====================================================*/

__attribute__((__interrupt__))
static void Isr_External_Signal_Input(void)
{
	eic_clear_interrupt_line( &AVR32_EIC, AVR32_EIC_INT1);
	
	/* ... doing stuff ... */
}


/*=== Public Functions =======================================================*/
int main (void)
{	

	eic_options_t eic_options = 
	{
		eic_options.eic_mode   = EIC_MODE_EDGE_TRIGGERED,
		eic_options.eic_edge   = EIC_EDGE_FALLING_EDGE,
		eic_options.eic_filter = EIC_FILTER_ENABLED,
		eic_options.eic_async  = EIC_SYNCH_MODE, /* For Wake Up mode, initialize in asynchronous mode */
		eic_options.eic_line   = AVR32_EIC_INT1
	};


	
	Disable_global_interrupt();
	

	/* Initialize interrupt vectors. */
	INTC_init_interrupts();

	INTC_register_interrupt(&Isr_External_Signal_Input , AVR32_EIC_IRQ_1          , AVR32_INTC_INTLEVEL_INT0);
	
	
	Enable_global_interrupt();
	


	/*--- EIC0 ---*/
	eic_init(&AVR32_EIC, &eic_options,1);
	eic_enable_line(&AVR32_EIC, AVR32_EIC_INT1);
	eic_enable_interrupt_line(&AVR32_EIC, AVR32_EIC_INT1);
	
	
	while (1)
	{
		/* ... doing stuff ... */
	}
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But what I currently see is, that the TC0 CH1 seems stop counting up while the ISR is being processed.
The timer will keep counting inside an ISR until you do something to it.


Quote:
Changing the "eic_edge" to "EIC_EDGE_RISING_EDGE" the interrupt is still triggered on the falling one.
What signal do you have connected to that external input ?, you might be getting contact bounce.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since the interval of the ISR isn't going to change, make a temporary version of the program that sets a port bit at the beginning of the IRQ and clears it at the end of the IRQ.  Compile it, and connect a digital oscilloscope channel to this port bit pin.   Set the trigger to be the rising edge of this port bit pin.  Run the program, and trigger the IRQ.  Measure the interval that the port pin is high. 

 

If you don't have a $300 digital oscilloscope, use a $8 logic analyzer (USB, Saleae clone) to measure the interval.   Now that you know the IRQ length, remove the port bit set/clear code from your program.

 

Do things the easy way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@mikech

Thankx for your feedback. The input signal is a simple digital output signal from the uC it self (PB08 is feeding PB09, it's just for "getting know how to deal with that device" purpose. So nothing to think more about it.). And I checked it out with an oscilloscope. So the flanks/shapes are in good condition yes.

 

@Simonetta

Thankx for your feedback as well. The idea is to be able to determine process consumption not only on an interrupt routine but on any kind of code (e.g. for purpose of code vs. efficiency). Sometimes its just very handy to have facts if one argues about code efficiency. And for that I don't want to install a (even tiny) logic analyzer (I have a Saleae Logic 8 ->I recommend smiley) and setup a pin for that. Talking about efficiency. It might would have been faster to do so for this specific problem. But having a coded framework that is easy to implement, one will be much faster than setting up any more hardware.