I'm talking to myself again, but have more info (and more questions).

It seems clear to me that the problem is the touchscreen interface. The definition of the PIRQ bit in the IO Controller manual is somewhat vague on its exact functionality, so it is difficult for me to track this down in detail.

But, I've concluded that the first touch -- the one that generates the interrupt is consistent (and probably good). The following readings seem to vary and be inconsistent. My guess is that the PIRQ pin is NOT being held as an output during this time.

The code seems to clear PIRQ as part of the is_pen_down_code and the pen_down_enable code.

FROM IO Controller DOC:

PIRQ: touch chip pen interrupt request (IRQ). The touch chip pen IRQ pin on the IO Controller initially is an input. When the pen IRQ signal goes low (on an interrupt), the IO Controller then drives the pen IRQ low as an output pin. This is the correct interrupt procedure from the component datasheet. When bit(4) of the interrupt/mask register is set to a 1, the pen IRQ pin again becomes an input. Bit(4) will need to be set back to a 0 in order to enable the pen IRQ to be an output again (and allow for another interrupt).

I assume this means that what actually happens is that when set to zero, penIRQ is an input (otherwise, you can't get an interrupt). Then, when you get the interrupt, the IO Controller automatically makes it an output.

If that is the case, then when is_pen_down exits, PIRQ is actually HIGH, not driven low as an output. (the doc does say it allows for another interrupt). In that case, current from the pullup will be causing erroneous readings. <!-- s:-( --><!-- s:-( -->

My interpretation would explain everything. The hardware automatically makes the PIRQ pin an output when an interrupt occurs. So, the first value read will be valid. But the is_pen_down code floats the pin so that subsequent reads will be invalid.

Can someone out there validate my understanding? And fix the code?

Thanks,

Ken