Disabling touch during drawing

[Asaliii]

When I touch my of my screen's icons in the middle of drawing, it will get stuck, won't continue drawing and even doesn't work any longer.

So I want my touch event not to respond to anything while the drawing is not over. Is that possible? 

[Joel Bodenmann]

Hello @Asaliii and welcome to the µGFX community!

That really sounds like a bug in your software. That's definitely unexpected behavior. Disabling the touchscreen is a very ugly work around that won't solve your problem in the long run. I'd rather encourage you to fix the problem you're actually having. Can you tell us more about your code?

[Asaliii]

@Joel Bodenmann thank you

which part of the code would you like to know about? the screen itself?tasks?

[Joel Bodenmann]

You talk about icons. Did you write some custom widget? Are you using an existing widget with a custom rendering? Are you using existing widget code completely unmodified? Can you provide a minimum test case that allows us to reproduce the problem? Did you try to reproduce the problem when running your µGFX GUI on Windows, Linux or some other desktop system? 

Did you even try to debug the problem? Did you check for stack overflows? What kind of crash are you getting?

[inmarket]

Let me suggest you start with one of the simple gwin demos. If you are having the same problem there it gives us a good idea on where to start to debug. If the demo works without the same symptom then the problem is likely in the way you have done something that is different to the demos.  In that situation it is much harder for us to help without seeing all your code.

In this forum we help people find problems relating to the way uGFX works. We are not a general debugging service although we can offer that on a commercial basis. If you are having problems always go back to the provided demos as they are known to work well on supported platforms and are easy for us to find os related issues on other platforms.

[Asaliii]

this is the example of my icons on that screen:

I have defined my own custom drawing functions.

the screen is a little bit complicated. it read some data and images from 2 different external SPI flashes. When I run the screen on PC I don't see this issue and when I debug it, it stuck somewhere in my dma transmission functions. do definitely it's not a graphic issue. the problem is somewhere in lower level of drivers or maybe tasks priorities. 

disabling the touch for me was kind of a way to avoid seeing the issue not fixing the issue. 

 

 

[Asaliii]

or maybe I should say is there any way I can stop touchscreen from responding during drawing? 

when the drawing is not over, touch input won't work and won't make any mess. 

[inmarket]

I think just turning off the touch processing is unlikely to solve your problem.

This sounds like an interaction between your DMA and the SPI/I2C interface used by the touch.

Given the extra detail that you have now provided this is sounding like an interrupt priority issue, perhaps an interrupt stack overflow, hardware resource conflict, or something else directly hardware related and therefore outside the scope of what can be controlled by uGFX.

Turning off the touch processing by the gwin system will still leave the touch polling active and thus the problem is unlikely to go away. It is a much more difficult job to turn off touch polling as this happens at the driver level and would require custom library modifications.

If you really want to play with the touch polling (and I would suggest that you don't) - the place to look is in src/ginput/ginput_mouse.c. You will need to stop the "MouseTimer" and then correctly re-enable it again afterwards. Note that doing this will not have any affect on an interrupt driven touch device as they don't require polling. Most touch devices however are not interrupt driven (usually because interrupt capabilities on touch devices tend to be VERY buggy).

[Asaliii]

If I want to stop this timer , would that be with gtimerStop?  

I used gtimerStop before gwinshow functions and tried to start it again in operation case, but I'm pretty sure this is not the correct way to do it, right? 

[inmarket]

gtimerStop (&MouseTimer) and gtimerStart (...) to restart it.

There are 2 complications...

1. MouseTimer is local to that C file.

2. The correct parameters will need to be passed to the gtimerStart.

Let me say again, just stopping the timer is NOT a good solution and may not solve your problem. You really need to get to the bottom of what the hardware conflict is.

[Joel Bodenmann]

11 hours ago, inmarket said:

Let me say again, just stopping the timer is NOT a good solution and may not solve your problem. You really need to get to the bottom of what the hardware conflict is.

Please take that advice. Everything else is just getting you further down the rabbit hole. You might get it "working" eventually but then you'll have a non-standard version of the µGFX library which means that you can't just update to a newer version in the future that will contain bug fixes and new features. Furthermore, when you proceed with your project and you start adding other peripherals and so on you might end up getting the same lock-up again and that time you can't just modify µGFX sources to bypass the problem.

[Asaliii]

guys,

I changed my tasks priorities and it seems that my issue is solved! so I won't manipulate anything regarding to that timer.

thank you so much for your help 

[inmarket]

Great you found a solution. Well done!