LM3s8962 interrupt enabling/disabling/ignoring/allowing

[David-n-MO]

Labview 2009 and related ARM module with a Luminary 3s8962 board.

I'm trying to "gate" the interrupt on and off using the interrupt ignore and allow functions and find it is taking upward of 30milliseconds after an allow before the isr actually runs...  

...So, I enable a hardware gate, Allow the interrupt, let the ISR run a few hundred times, Ignore the interrupt and disable my gate.  And I want the ISR to run only while my hardware gate is enabled.

Also, if I don't enable the interrupt in the "manage Interrupts" section of the build specs I can't get the ISR to run even when using the interrupt Enable funct ion.

Solutions people???

Thanks,

David

[NicB]

---

David-n-MO wrote:

I'm trying to "gate" the interrupt on and off using the interrupt ignore and allow functions and find it is taking upward of 30milliseconds after an allow before the isr actually runs...  

---

It could take longer than 30 ms, depends on what is actually triggering that interrupt.

I don't understand very well your issues. What is HW and what is SW?

You can start the application with interrupt disable and enable later programmatically.

[Jon_S.]

Hello David,

I have some additional questions for you.  First, how are you measuring the 30 ms delay?  Also, are you going to be turning the interrupt on and off multiples times throughout the program or just once.  Also, can you post the VI that you are trying to run?

[David-n-MO]

Since this little uController doesn't have an FPGA  it isn't fast enough, even with microsecond timing, to do what I need, so I had to add some hardware to do it.  After posting the other night I realized I should be doing the enable gating in that hardware and have done so.  But I still would like to know why the allow or ignore interrupt functions take so much time.  I would  think they are like hardware enables and active immediately.

Regarding your questions Jon, I'm measuring the delays with an oscilloscope on gpio pins .  I was going to enable and disable the interrupt for every sample, but now since the triggering the interrupt is controlled by the hardware I can leave it permanently enabled. 

But now that I have the interrupt triggering I'm having trouble signaling that the ISR has run.  The send occurrence at the end of the ISR doesn't work because the the wait on occurrence times out.  The attached jpg show the relevant parts of the VIs.

Thanks,

David

So much to learn... So little time.

Message Edited by David-n-MO on 09-21-2009 08:20 PM

[NicB]

I had built the attached project just to show David that measuring execution time with the scope don't give always accurate results. Basically, he placed a VI along with two EIO/LEDs on a Flat Sequence with three frames. Watching pin changes gives the execution time of the VI but also EIO and part of the flat sequence.
However, my project uses a timer to show the cons (the main VI is simple and does not further comments).

Some results:

Of course, enabling interrupts in C code is faster, but it doesn't matter any more if couple interrupts are enabled:

(Sorry David, it never takes 30 ms)

The are some good news: we can still use old (8.6) ARM Global Interrupt Disable.vi, ARM Global Interrupt Enable.vi, ARM Interrupt Disable.vi, ARM Interrupt Enable.vi.
Note: use global ones only for short time, in critical sections of your code.

P.S. I would use the new 2009 VIs (without ARM prefix) only if I'll plan to disable interrupts for seconds, as in attached project. With other words, the new VIs disable only interrupts used in LabVIEW, which might be useful in some particular cases.

[David-n-MO]

Your post is instructive and I appreciate the thought you put into it. But it missed the point of my question.  The 30ms delay I  think I was seeing was from the time the interrupt was enabled to when the ISR began to run.  Not the execution time of the interrupt enable.  I used gpio pins with the oscilloscope because some of those pins control the hardware, ie. The interrupt line, and to make sure the ISR was actually running.  After I'm satisfied the debug pins and code go away.

Regarding the occurrence problem... As with the interrupt problem I bypassed it by replacing the occurrence with a global variable and poll it <shudder!!!>.   Does anyone know why the occurrence isn't working??

Thanks,

David

[NicB]

Troubleshooting firmware with LED/scope is an old but still a good method. Actually, the scope may be useful in the real system (e.g. if the system is a power supply).
Still, despite of the slow enable/disable functions, the 30 ms cannot have its roots elsewhere, but in your application (perhaps, other ISRs with the same priority are running).
Occurrences are working just fine in interrupts.

Message Edited by NicB on 09-22-2009 05:35 PM