Site Map | Contact Us
Quantum Leaps - innovating embedded systems Call us toll-free!
Quantum Developer Zone
Quantum Leaps Discussion Forum

Search the Forum for answers or post your questions to the
Quantum Leaps community


Return to Website

  First
  Prev
  Reply
  Forum
Next  
Last  
Search this Forum:  
Viewing Page 1 of 1 (Total Posts: 2)


Author Comment    
Petr Racansky

petr.racansky@honeywell.com


Jul 17, 07 - 10:10 AM
How to safe post or publish from interrupt?

Hi Miro,

I have an event driven application in non preemptive QP environment.
This application is stated by level change in input pin.
I use an interrupt to wake up micro and send QP event to active object.
Active object receive this event and set up his own timer to keep him alive until he process the event.

The interrupt event causes only a transition form IDLE state of active object. So when this event comes during the processing it can be simply dropped.
The pin interrupt is disabled when active object leave IDLE state by an EXIT action. It prevents QP from unnecessary processing.

The issue is that there is some time between interrupt routine and EXIT action of active object. So in fact several interrupt events can be added it to the QP queue before pin interrupt is disabled. And it can cause overflow -> assertion -> program failure.

I decide to post an event and disable the pin interrupt directly in interrupt routine. Now it can happen only once and can not overflow the queue. When active object end its work it goes back to IDLE state and enable interrupt in ENTRY action.

My colleagues suggest that I should disable pin interrupt in active object to lave full control of events in active object. But I don’t how to handle the overflow in this case.

Imagine for example situation with mechanical relay contacts which can generate many edges in short time during the swathing.

What do you thing about that? Do you have any suggestions?
Miro Samek

www.quantum-leaps.com


Jul 17th, 2007 - 7:29 PM
Re: How to safe post or publish from interrupt?

Petr,

I think that your solution to mask the further PIO interrupts from the ISR is OK. The QF framework gives you a guarantee of event delivery, so one event generated from the ISR is enough to reliably drive the application.

Obviously, the PIO interrupt must be un-masked before you go back to sleep. I'm not sure where the best place in the code to do so would be. Certainly the entry action to the IDLE state is one candidate. The other option is un-masking the PIO interrupt from the QF_onIdle() callback just before going to sleep. At this point you establish the conditions for waking up, so it will be perhaps logical to un-mask PIO at this time.

I also understand the concerns of your colleagues. They want the "interrupt resource" to be entirely encapsulated inside a dedicated active object.
However, I'm not sure that the interrupt mask is the same kind of resource as memory, or an I/O port. Interrupt mask seems to me more like a system-wide resource (a bit like a CPU register).

Anyway, I think that there is not a clear cut here, but your solution is the simplest and perhaps most robust.

Miro


  First
  Prev
  Reply
  Forum
Next  
Last  


powered by Powered by Bravenet bravenet.com