A generic VHDL touch controller – add capacitive buttons to any FPGA | Hacker News Reader

A generic VHDL touch controller – add capacitive buttons to any FPGA

github.com

77 points_quarks_17 comments

Unfortunately, this RC rise time method has quite a number of issues with interference (which is quite common, if you have a switching charger attached or a GSM cell phone nearby). Some form of demodulation (or even dual slope conversion) will greatly improve real world performance. A wide variety of algorithms are also required to minimize false activation and "stuck" buttons in the presence of noise/moisture.

I would recommend that those looking for good solutions for capacitive buttons search the literature. There are quite a few articles from ~2000 (and patents expiring) that describe unencumbered IO based methods of sensing... although many require more than one IO per sensor or some method of multiplexing.

This expired (2019) patent comes to mind: https://patentimages.storage.googleapis.com/52/dc/c3/005f65c...

In full disclosure, I'm listed on other capacitive sensing patents, but many do not expire for several more years.

It seems that the best method to use with non-specialized GPIO is the charge transfer. Instead of using a resistor, charge a sampling capacitor.

The presentation below deals with a specialized block, but the only major change is using hardware for cycle counting and multiplexing a single sampling capacitor.

https://www.st.com/content/ccc/resource/training/technical/p...

Charge sampling is nice because it effectively puts a (leaky) integrator into the measurement narrowing the band. It looks like the ST solution requires an internal mux to share the storage/sampling cap, which may be present in your micro-controller/FPGA, but isn't quite so standard. The cited patent (above) actually shows how to reuse IOs to get a pair of sensors on a pair of IOs (and a shared component cap), which is fairly efficient for charge transfer.

However, be careful of IP... I can only really recommend OpenSource implementations that read directly on out of coverage patents. There are even sigma-delta and other relatively narrow-band IO based solutions, but they may carry IP risk.

I was about to link Atmel QTouch, they do the same thing with plain vanilla GPIO, but annoyingly do not provide the exact sequence of operations as ST presentation does. But they seem to be equivalent.

This chip on the diagram is ATTiny in disguise - just rearrange the cap and no special hardware needed: https://eu.mouser.com/new/microchip/atmel_qtouch/

Just to clarify, Atmel acquired the company and expired IP that I cited above. They may continue to use it in some portion of their IC portfolio.

I'm confused. Is this a system to be able to add buttons to FPGA's through their logic gate sort of system? Do you plug the buttons into a particular "slot" or something?

This is a library you run on your FPGA.

When you are making a circuit board, you can make a big pad of exposed copper and connect it to one of the I/O pins on the chip.

You can then use that pad as a button, instead of buying a button and soldering it to the board

But don't do this unless you have to, since a button is a hundred times more reliable and easier to use. (Buttons actually provide tactile feedback, for one....)

can't you provide electrical feedback?

In terms of stuff lighting up? Sure. In terms of something the finger pressing the button can feel, no. It's completely impossible with a cap-touch button, a problem also shared with piezo buttons. And a major reason they are very annoying to use.

I feel like I saw this concept recently (big exposed conductive pads) as a way to generate random numbers (Ben Heck's recent YT video about his lanyard game).

Does this work for portable devices? If the device is moved around wouldn't C_base change?

Yes (usually temperature drift is a bigger issue), generally there is some (moderately complex) low pass filter that maintains a relatively stable baseline and recovers gracefully (no false positive, minimal false negative) from noise/moisture/thermal and other adverse events.

One interesting case is buttons in your pocket or face down on a desk. This is made more complex when low power requirements are made (e.g. lower sampling rate). A second is breathing on a very cold device. There are guarding methods that reduce the effect of moisture, but they may also run into IP challenges.

How can you maintain a baseline for C_base if somebody keeps touching the pad while moving?

You cannot really maintain that. The controller has to adapt. That is what the two reset signals are for. The synchronous one can be trigger by application logic (for example some sort of timer) to re-calibrate the touch controller.

Intentional user input has fairly consistent characteristics, as do each of a variety of noise/drift/interference sources. The key is to safely and accurately recognize/estimate each of those to remove or report them. I suspect now people would prefer to use some form of machine learning, but realistically there are fairly low expected power requirements, which make that difficult. There's also a battle between low latency stateless techniques and more stateful techniques that require rapid recovery when they get something wrong.

I love VHDL!!!

Reply on news.ycombinator.com