Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

interrupt duration

Altera_Forum
Honored Contributor II
1,232 Views

I wonder, how long I have to set an interrupt. For one clock cycle, until there is some response, ... Has anyone a clue?

0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
491 Views

if you talk about a pio, the external signal must be active for some clock cycles (don't know  

exactly how much) to get sampled. 

 

if you talk about a user component: 

 

that's tthe way I do it: 

 

in a user component, I have a bit in a register (flipflop) which is set to generate  

an interrupt (signal irq); 

in the interrupt service routine, I clear this bit by writing to the irq-register of 

the component; 

so irq signal of the user component stays active until it's service routine is called.
0 Kudos
Altera_Forum
Honored Contributor II
491 Views

I'm talking about UL. 

 

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  

in a user component, I have a bit in a register (flipflop) which is set to generate 

an interrupt (signal irq); 

in the interrupt service routine, I clear this bit by writing to the irq-register of 

the component; 

so irq signal of the user component stays active until it&#39;s service routine is called.[/b] 

--- Quote End ---  

 

 

Thats exactly how I do it, too. So, there is no shorter way?
0 Kudos
Altera_Forum
Honored Contributor II
491 Views

What do you need a shorter way of. If the signal stays on or not, will not change anything on the time needed to process the interrupt.  

 

Or is it the following you need to know : how much cycles does it takes for the cpu itself from a high on an interrupt pin to the first instruction sitting at the nasys_execption_address??  

 

Well, that is a thing I also wants to know.  

 

 

 

Stefaan.
0 Kudos
Altera_Forum
Honored Contributor II
491 Views

You must keep your interrupt signal asserted until it is cleared by a software action. 

 

Most hardware uses a write to a bit in a register to clear the interrupt, but some (for example the UART read interrupt) uses a read from a particular register (which can be faster but is harder to debug). 

 

If you deassert the interrupt line before software has had a chance to deal with it then you have sent what is known as a "spurious interrupt".  

 

The HAL software will spin in the interrupt handler when it gets a spurious interrupt to make it obvious that your system is broken (its easier to debug synchronisation problems if the bug always happens rather than just one time in 100).
0 Kudos
Reply