Race condition

[MarkJeronimus]

Sometimes, when the IRQ pin is low and when (X,Y) is sampled, it's not (000, FFF) but one of the coordinates is invalid. What probably happens is that IRQ goes high after it is sampled, then Y goes to FFF before (X,Y) is sampled. What I read is (<something not 000>, FFF), and the mouse jumps to the bottom of the screen momentarily. Sometimes the ISR function ends while IRQ is still asserted, and no amount of dragging causes the ISR to start up again (you have to lift the pen first). Veru rarely Y is valid and X=000.

[Tomasz-Mankowski]

I do not know If I fully understand you but I think the problem lies not only in sampling of the resistance data, and weird values (I did not have such weird values as you described) but in physical behaviour of the the pen and resistive panel. It is the same story as the bouncing of regular button, when pressed the signal changes multiple times causing trouble with handling the interrupt. In ideal solution after the interrupt the timer should be fired and then in timer handler the gpio should be checked if pen is still pressed (or if it was pen lifting). Only then the averaging sampling should occur. I did not wanted to play with posix timers as I have not done it before, so initially I wend for brute force solution. If you add a small wait just after the penInterrupt you should nearly always get a 100% score...I think. 2017-05-09 18:03 GMT+02:00 MarkJeronimus <notifications@github.com>:

…

Sometimes, when the IRQ pin is low and when (X,Y) is sampled, it's not (000, FFF) but one of the coordinates is invalid. What probably happens is that IRQ goes high after it is sampled, then Y goes to FFF before (X,Y) is sampled. What I read is (<something not 000>, FFF), and the mouse jumps to the bottom of the screen momentarily. Simetimes the ISR function ends while IRQ is still asserted, and no amount of dragging causes the IRQ to start up again (you ahve to lift the pen first). Veru rarely Y is valid and X=000. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQXXJwbO6c0SlKp_u9P28pBfZ0NsVKC_ks5r4I5CgaJpZM4NViHT> .

[MarkJeronimus]

This is me lightly dragging across the screen in a snake pattern. Sometimes the pen actually lifts up and creates an interruption in the line, but sometimes a line is interrupted with a hard (X, FFF) value. In this case the Y value is an average of 9 samples (See pull request #1), one of which is Ymax.

[MarkJeronimus]

I suggest entering a permanent loop instead of relying on the interrupt. It will always sample at regular intervals, and if there's a valid measurement (>50% of N samples of both P6 and coordinates is valid), will it press down, and only when this percentage drops <50% it will lift up the pen. The measurement of both P6 and/or coordinates should ideally be done atomically.

[Tomasz-Mankowski]

I did not have this problem with my brute force solution. I think for your averaging solution a proper debounce of interrupt pin have to be implemented in order to properly solve the problem you have had shown on the photo above. Sure the code can be moved to main program loop, I initially started with interrupt style as I wanted to use timers finally. But still the debounce of the pin have to be implemented. I think the problem is that data should not be sampled during bouncing of the pin. Internally, for ADS device, the irq pin is connected with the ADC signal source switch somehow and sampling it during raising or falling irq edge corrupts the data, so you get a "half" result. Try, for an experiment, adding and additional wait time just before sampling the data, I think it should help.

[MarkJeronimus]

I had the problem with your near original code, with only the delays changed from 100000 to 10000. When I had Terminal Emulator open (maximized) and traced circles on the screen, occasionally the selection would extend to the bottom and stay here, and I couldn't explain it then. Try that.