Can I Disable Touch Screen Sampling on an Internally Generated Event?

We’ve designed a product which uses a BeagleBone Black with a resistive touch screen. The BBB controls some external hardware which is designed to generate large amounts of EMI. When gating is on, the hardware resonates at around 200 kHz, most likely with large amounts of harmonics. When gating is off, the hardware is off and not generating substantial EMI.

At the moment gating is enabled, the EMI starts and the touchscreen gets a phantom press. Gating can be as low as 3 Hz (50% duty cycle?) and you can hear a “tick tick tick” sound at 3 Hz. At every “tick”, the cursor jumps to a random position. At 100% duty cycle or at very high gating frequencies, the touchscreen behaves normally.

Is there a way to disable touchscreen sampling for a short time period when the gate signal (generated by the BBB) is asserted?

Use an interrupt maybe to tell SW to ignore? Might slow things down.


Probably, but I'd try to fix the hardware first.

It sounds like the EMI itself isn't directly causing the phantom touch,
but the act of turning the EMI generator on causes the problem. I
suspect you have some nasty spikes getting into the power rails that
could cause you problems in the future. At the very least, I'd want to
understand the mechanism causing the phantom touches before just
assuming they are harmless and masking them via software.

Use an interrupt maybe to tell SW to ignore? Might slow things down.

Is it really that simple? Is there just a port, or a named pipe, or some shared memory location that you can write to to briefly disable the touchscreen? I can imagine that it wouldn’t be too difficult to shut down a driver, or tell X-Windows (forgive me, I’m not very BBB literate just yet having barely used one so far so my terminology may be off) to stop using it for long periods of time. I’m just wanting to shut it off a few milliseconds before turning on our EMI generator and turn it back on a few seconds after that.

Real solution is to fix the issue. You just asked how to trigger a shutdown which was my answer. That would not be my solution.Shutting down a touchscreen for x amount of ms will be tough to do…


The power rails are solid, to our knowledge. The BBB has been powered from different power supplies than the EMI generating hardware as well as a battery. Our scope captures don’t show anything definitive on the power rails, but it is kind of clouded by the fact that the scope is affected by the EMI as well. My cell phone’s capacitive touchscreen, unplugged and 15 feet away, goes haywire when this EMI monster is turned on.

Real solution is to fix the issue.
Agreed. The trouble is figuring out how to fix the solution. We could run the BBB off of a battery, put it in a Faraday cage, and optically couple the gate drive to the BBB, but then you couldn’t get to the touchscreen. The issue at hand is that the system is designed to generate large amounts “energy” (e.g. EMI) so we can’t solve it by reducing the EMI.

Shutting down a touchscreen for x amount of ms will be tough to do.
Thanks, that is what I figured. Bare metal programming, this would be simple. But with an OS in the way, maybe not so much.