Why is the touchscreen input glitching when switching control modes?

Oct 18, 2026 Last reply: 11 hours ago 6 Replies

First reply

ScoutGravel

I ran into almost this exact thing on a handheld controller build. The lag only showing up on your heavy control screen is a big clue. On my setup the problem was the display redraw itself. When I switched to the screen with all the live gauges and buttons, the ESP32 was…

Read the full reply

I'm working on this custom RC setup, trying to get the ESP32 to manage a functional display for a remote robot. It's a dedicated board design, using the ESP32 to handle the screen UI and the main Arduino for the command logic. The setup works fine when I'm just running basic monitoring screens, checking battery life or system status. But as soon as I try to switch the display to a primary control screen, like initiating drive mode, the touch inputs start lagging or just drop out completley. It feels like the processors are fighting over the communication stream.



I've checked the wiring and the library calls seem okay, but when the system switches from the monitoring state to the active control state, the lag gets worse. Does anyone have experiance with the timing conflict when you load a heavier UI state onto the microcontroller?


I ran into almost this exact thing on a handheld controller build. The lag only showing up on your heavy control screen is a big clue. On my setup the problem was the display redraw itself. When I switched to the screen with all the live gauges and buttons, the ESP32 was redrawing the whole screen every loop pass, and the touch controller sits on the same bus as the display in a lot of these modules. So every big redraw was starving the touch reads. The fix was to only redraw the parts of the screen that actually changed, and to check for a touch event before doing any drawing at all. That alone cut the lag way down.

The other thing to look at is the link between the ESP32 and the Arduino. If the Arduino is pushing status updates continuously and the control screen needs faster updates, the serial buffer between them can back up and everything starts feeling sluggish. I throttled my updates so status data only got sent every couple hundred milliseconds, and I made the messages short and fixed length so they were easy to parse fast. Worked way better than I expected.

One more thing worth checking: power. A screen doing heavy redraws pulls more current than an idle status screen, and if your regulator is allready close to its limit the touch controller gets flaky right when you load it up. Mine behaved exactly like a timing bug but it was realy a brownout. Worth scoping or at least measuring before you chase software ghosts any further.

Still pretty new here so hope this lands right, but I had a similar headache on a little greenhouse monitor I built, diferent setup but same feeling of everythign bogging down when the screen got busier. What helped me was moving the touch checking into its own timing slot instead of letting it run loose in the main loop. I just gave it a fixed little window every cycle and the response got way more predictable. Out of curiosity, how are you handling the screen switching itself? I never worked out if mine was better clearing everything first or just layering the new stuff on top, and it sounds like you might have already found out the hard way.

Not buying the brownout theory from that first reply. If the touch chip was actually browning out you'd see ghost presses or the whole controller resetting, not just laggy response that lines up with one screen. Mine did something similar once and it turned out the control screen code was blocking on serial reads waiting for the Arduino to answer, so the loop just stalled until data showed up. Easy way to check, add a timestamp print in your main loop and watch how long each pass takes when you switch screens. If the gap between prints jumps, it's your code waiting on something, not the power rail.

The second reply about giving touch its own timing slot matches what I saw on my own controller project. I used a timer interrupt on the ESP32 just for polling the touch chip, separate from the main loop where all the screen drawing and radio stuff happened. Buttons felt instant even while the display was busy updating gauges. Before that, a busy frame could swallow a tap entirely. If your library allows it, that split is the cleanest fix I found.

On my pinball score display project the thing that finally cracked it was a cheap logic analyzer off ebay, like ten bucks. Clamped it on the bus while the heavy screen loaded and you could literally see the touch chip getting squeezed out during every big transfer. That picture settled the arguement in my head fast. What fixed it for me was moving the touch chip onto the second hardware bus the ESP32 has, so the display and the touch controller stopped sharing a wire. If your module breaks those pins out it's a five minute change and worth trying before you restructure any code.

Update: moved the touch polling into its own interrupt like the fourth reply suggested, and inputs are way more responsive now even on the drive screen. Still got a hiccup though, the screen redraw itself is eating enough time that gauges stutter. To the first poster, did you end up only redrawing the parts that change, or the whole frame?

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required