Lpc2000

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@i...> wrote:
>
> We've just discovered come characteristics of the external
> interrupt lines on the LPC213x parts (probably other parts as well, 
> though not on the newer ones like the LPC214x), which I think is
> worth sharing  with people here.
> 
> Our basic requirement is to have an external signal generate an 
> interrupt to signal a once-off event. We configured P0.20 as EINT3 
> to generate an edge-triggered interrupt on a falling edge. This
> works just fine. The problem is that we also want to be able to
> read the state of the pin at any time. 
> 
> The first point to note is that you can't read the state of a pin 
> when it's configured as an external interrupt: we read it 
> consistently as 0, even though it is normally held high. This is 
> indicated in a statement in the User Manual, in the section on the 
> Pin Connect Block ("Selection of a single function on a port pin 
> completely excludes all other functions otherwise available on the 
> same pin"), though we only spotted this after we'd spent a while on 
> figuring out what was wrong (maybe an additional statement in the 
> External Interrupt description would help here?).
> 
> Anyway, our work around was to temporarily reconfigure the pin as 
> GPIO, read its value, and reconfigure back as EINT3 whenever we 
> wanted to read it. This works just fine.
> 
> However, it introduced problem number two: depending on the mode of 
> the interrupt and the state of the pin, the action of changing it
> to GPIO and back again can itself generate a (spurious) interrupt. 
> That is, you can get an interrupt even though there's been no
> transition on the actual pin. We then changed the function to do
> the read, so that it disabled interrupts, switched the pin to GPIO, 
> read the value, switched to EINT3, reset the pending interrupt
> generated and re-enabled interrupts. Again, this works, if a bit
> long-winded.
> 
> However, on thinking about it, what would happen if a real state 
> transition happened when all this was going on? My strong suspicion 
> is that there's potential for a race-condition to exist, even if
> only for a short time.
> 
> Because of pressure of time, we've had to rethink how we're
> handling this, and for now, we're not using interrupts for the
> function any more: we now poll the pin, leaving it as a GPIO input. 
> I'm sure there is some other work around to this issue (it's
> probably preferable to use level sensitive interrupts in any case).

Or route the signal to a GPIO pin in addition to the EINT pin.

Or use a timer capture pin, and let it generate a capture interrupt 
on both rising and falling edges of the pin, and keep track of the 
pin value in the interrupt handler. (And be aware of the TIMER.1 
errata.)
  
Karl Olsen