I wonder, how long I have to set an interrupt. For one clock cycle, until there is some response, ... Has anyone a clue?
連結已複製
4 回應
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.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's service routine is called.[/b] --- Quote End --- Thats exactly how I do it, too. So, there is no shorter way?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.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).