Touch driver in semi-polling mode

[king2]

I have touchpanel that raises EXTI interrupt when something was changed with touchpanel (pressed or depressed), but gmouse works in polling mode.

So, now I just have global variable touch_panel_pressed, and this variable sets to true when EXTI interrupt was raised.

In read_byte() I check this variable, if it is false, the function just return zero, so read_xyz() returns without actual I2C communication.

If it was true, I set variable to false and do actual reading from touchpanel, so result can match read_byte() & 0x07 condition in read_xyz(). All changes was made in my custom gmouse_lld_FT5x06_board.h.

What do you say about this approach? Is it good or I missed something important?

[inmarket]

The reason ugfx polls rather than using interrupts is because we are yet to find a chip where the interrupt works properly!

Problems we have seen...

1. Some chips don't send a release interrupt thus you never get a touch up except by polling anyway.

2. Some chips only sometimes provide a release interrupt.

3. Some corrupt the reading when they raise the interrupt.

4. Some will work ok for a while and then freeze up. Only a full power reset fixes the problem (not even a software or pin reset works)

5. Some with fifo's only interrupt when the fifo reaches a particular level which means short events can be lost.

6. Some chips will flood their fifo's in the time it takes to raise the interrupt.

7. For all chips you are relying on what the controller considers a touch. Our software level detection is MUCH better than the simple method these hardware interrupts use.

In general, they just don't work reliably.

That however doesnt mean there isn't a chip where they do work, just that we haven't found one yet.

[Joel Bodenmann]

To actually answer your question: The way you added interrupt support is fine. Given that uGFX currently doesn't provide a proper interrupt driven mouse driver (as per the reasons listed by inmarket) there's no official / better way of doing this. Adding this to the driver is the most proper way as it keeps the libraries core code unchanged.

Compared to having interrupt support directly built into the GINPUT module you don't loose much as the overhead of calling read_xyz() is very little compared to doing the actual I2C read. This is also the reason why we didn't bother adding an interface for this so far: Most touchscreen controllers provide a proper penDown signal that can be hooked up to a pin. Checking a GPIO pin is a lot faster than doing the actual I2C/SPI reading so the performance lost by polling is not that big.

Anyway, things like this are on our ultra-low priority ToDo list and are something we will definitely tackle in the future. Most likely stuff like this will be completely reworked for the 3.x release.

~ Tectu

[king2]

Thank you for describing potential problems with chips, I did not met them yet, but I will beware

I glad that I have selected right way to implement interrupt.

I think implementing entire interrupt method (without polling) is not so important, because we should implement queue of events in this case to make it right way.

I was not met any problems yet with touch, so I think it is good to have this, but while full stack events will be implemented, as well as full stack WM, and other things linked to events queues, i.e. definitely not now and not at first priority.

Thanks!