Lpc2000

Good suggestions.

Routing to a 2nd pin is probably safest. Problem is we're short on 
pins and also would prefer not to re-spin the board at this late 
stage of our development.

On the 2nd suggetsion, I'd be curious to know if the capture pins 
behave the same as the EINT pins (i.e. you can't read their state 
when configured as a capture pin). My guess (and it's only a guess) 
is that it's likely they would.

Best option is probably to use one of the later devices: aparently on 
these the IOPIN register always reflects the actual pin state.

Brendan

--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@p...> wrote:
>
> --- 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
>