Added support for XPT2046 touch screens as own module

[Starofall]

I integrated the source from the referenced github projects into the nodemcu-firmware.
This offers fast and efficient access to the touch display on a nodemcu.

Especially as many ILI9341 (which is supported by the ucg lib) displays uses the XPT2046 for touch.

[Starofall]

A relevant point might be, that part of the source code I used is GPL at the moment. If this is a problem I would ask the creator to change it to enable an integration.

[devsaurus]

ICACHE_FLASH_ATTR is redundant since the default mapping for nodemcu firmware is flash. Please remove these attributes.

[devsaurus]

So far I checked just some formal coding aspects.

PR is missing an API documentation in docs/en/modules (see Writing Documentation) together with some Lua example that shows how to use this module. Once it's available we can better understand the design.

[Starofall]

I just added the documentation and modified the source code.

[jmattsson]

The GPL aspect is unfortunate, let's see what their response is.

@TerryE I guess this is another reason why it would be good to have a separate repo for non-core modules.

[TerryE]

I also don't like a contaminating nature of GPL. Anyone who uses a GPL component has to adopt GPL for their own product licence. Maybe we need an external_gpl folder to contain such components, so that firmware builders can simply remove this folder if they don't wish to be bound by GPL.

I note that the PHP project takes a harder line: they don't allow GPL source in the core code base for this reason.

[devsaurus]

As far as I understand, the API suggests that the user has to poll for position updates. What I'm missing is a callback mechanism so that the application gets triggered when the screen is touched. This would better fit the event-driven approach of the Lua firmware in my opinion.
The datasheet shows that the controller supports an interrupt request output - mapping this to a GPIO interrupt which would allow to fire a callback on Lua side. This could be implemented with gpio.trig() on user side, but seems to be a bit tricky since the interrupt has to be disabled during communication.

What is your view here - Let the user handle interrupt callbacks or does this need to go into the module (as it's already dealing with IRQ pin)?

[devsaurus]

averaged instead of meaned?

[devsaurus]

On a general aspect, this PR adds a controller of what I'd call the touchscreen or pointer class. How about having this class as a single module and specific controllers derive from it? These would then all implement methods of a common API.

What's the position of other contributors?

[jmattsson]

This could be implemented with gpio.trig() on user side, but seems to be a bit tricky since the interrupt has to be disabled during communication.

To me this strongly implies that it should be internal to the module.

How about having this class as a single module and specific controllers derive from it?

The theory sounds good. I haven't got any driver-level hands-on experience with even a single touch-screen controller, so I'm not in a good position to assess feasibility of it.

[marcelstoer]

Let the user handle interrupt callbacks or does this need to go into the module

Needs to go into the module.

How about having this class as a single module and specific controllers derive from it?

Thanks for that feedback, I had meant to raise that as well but you beat me to it. From a Lua developer's perspective touch support should IMO work like U8G/UCG - you select the module and the appropriate driver.

[marcelstoer]

@Starofall does the feedback from us committers make sense to you? Do you think you can incorporate the requested changes?

[Starofall]

@marcelstoer I first wanted to wait for an ok from the library creator to fix the licensing problem.
But having a general interface for all touch screens sounds like a good idea.

[marcelstoer]

I'm glad the licensing issue got resolve so effectively.

[marcelstoer]

No feedback from PR author in a long time, pity -> closing