[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PortA Interrupt Handling



Hi,

I had thought of this hardware solution, and it does intrigue me in the
absence of an obvious software solution.  My plan is to use 5 pins of PortA
as interrupt pins.  Since they are all multiplexed through the same
interrupt vector, how would I know which pin caused the interrupt.  It seems
awfully tricky to try to time the monoflop so that the pin is high when the
interrupt routine gets around to reading the port, and low before the
interrupt routine exits.

Also, is there any guidance as to the statistics of the delay between the
pin going high and the interrupt routine being called.  I feel that
depending upon the amount of code that has done the save_flags(), cli() -
restore_flags() code, this time could vary wildly.

//
Greg

-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
Behalf Of Gerhard Großberger
Sent: Saturday, November 10, 2001 6:12 AM
To: dev-etrax@xxxxxxx.com
Subject: AW: PortA Interrupt Handling


Hi,

i would suggest to solve this problem by a simple external hardware. It's
much
simpler and less time consuming than spending hours to make a work around.

You can use a simple monoflop (e.g. the 74HC123) and set its pulse time to a
very short period (should be less than your interrupt handler needs to
finish but
long enough to get the interrupt handler activated) - may be appr. 100us or
even less are ok.

Wish you success,
Gerhard

-----Ursprüngliche Nachricht-----
Von: owner-dev-etrax@xxxxxxx.com]Im">mailto:owner-dev-etrax@xxxxxxx.com]Im
Auftrag von Greg Cannon
Gesendet: Freitag, 09. November 2001 17:50
An: dev-etrax@xxxxxxx.com
Betreff: PortA Interrupt Handling


I need about 4-5 external interrupts, and I was planning on using PortA to
do this.

I have written driver code that successfully gets an interrupt on PortA.
However, since PortA is level, I will continue to get interrupts until the
external pin goes low.

My general strategy for dealing with this is

enable the interrupt
at the interrupt, disable further interrupts
have the interrupt schedule a tasklet to poll for the line to go low
once the line goes low, reenable the interrupt

My strategy fails; if I use a loop/check/sleep mechanism in the tasklet, the
developer board locks up. (If I remove the sleep loop, everything works
fine, but the tasklet always fires before the interrupt line drops).  I am
dealing with levels that may stay high for a second, so it is not feasible
to stay in the interrupt.

Is there a software solution to using PortA interrupts?

Is there any plan to make a part with edge sensitive interrupts?

//
Greg