Repository navigation
Can a “touch prompt” variable be added to control a GPIO output high or low? #116
Description
Activity
Thanks for the detailed write-up. A real capacitive touch area is a good idea, and the firmware already supports it with no new variable: use a GPIO presence input instead of BOOTSEL.
PRESENCE_PIN=<gpio> PRESENCE_ACTIVE_HIGH=1 cargo build --release -p firmware
The board-TOML equivalent is
[presence] source = "gpio",pin = <gpio>,active_high = true. See docs/hardware.md for the knobs and docs/build.md for turning the ELF into a flashable image.A TTP223 with its default options (TOG=0, AHLB=0: direct mode, active-high push-pull output) connects straight to that pin. Keep it powered all the time and wire Q to the GPIO. You need no transistor and no BOOTSEL.
I'd rather not add a
TOUCH_IOthat powers the sensor only during a prompt:- The presence input is read outside prompts too. N taps while idle type the OTP from slot N, as on a YubiKey, and a sensor that is off between prompts breaks that.
- After power-on the TTP223 ignores touch for about 0.5 s while it calibrates. A finger already on the pad gets calibrated in, so every prompt would start with a dead window.
- The datasheet warns that a fast-changing supply can cause false detections. The presence wait reads the input as soon as it starts, so a switch-on glitch could count as a touch nobody made. On an authenticator that is a security bug.
- It saves nothing: the TTP223 draws about 1.5 µA. An unpowered chip whose output sits on a live line also gets powered through its protection diodes.
Wiring the sensor to BOOTSEL does work, and touches outside a prompt are harmless there. A GPIO is still the better choice. BOOTSEL is the flash chip-select, so a push-pull output needs a series resistor or an open-drain stage. And a touch while plugging the key in drops it into the USB bootloader.
If you build it, please report back how it behaves on your PCB.
Thanks for the detailed write-up. A real capacitive touch area is a good idea, and the firmware already supports it with no new variable: use a GPIO presence input instead of BOOTSEL.
PRESENCE_PIN= PRESENCE_ACTIVE_HIGH=1 cargo build --release -p firmware
The board-TOML equivalent is[presence] source = "gpio",pin = <gpio>,active_high = true. See docs/hardware.md for the knobs and docs/build.md for turning the ELF into a flashable image.A TTP223 with its default options (TOG=0, AHLB=0: direct mode, active-high push-pull output) connects straight to that pin. Keep it powered all the time and wire Q to the GPIO. You need no transistor and no BOOTSEL.
I'd rather not add a
TOUCH_IOthat powers the sensor only during a prompt:- The presence input is read outside prompts too. N taps while idle type the OTP from slot N, as on a YubiKey, and a sensor that is off between prompts breaks that.
- After power-on the TTP223 ignores touch for about 0.5 s while it calibrates. A finger already on the pad gets calibrated in, so every prompt would start with a dead window.
- The datasheet warns that a fast-changing supply can cause false detections. The presence wait reads the input as soon as it starts, so a switch-on glitch could count as a touch nobody made. On an authenticator that is a security bug.
- It saves nothing: the TTP223 draws about 1.5 µA. An unpowered chip whose output sits on a live line also gets powered through its protection diodes.
Wiring the sensor to BOOTSEL does work, and touches outside a prompt are harmless there. A GPIO is still the better choice. BOOTSEL is the flash chip-select, so a push-pull output needs a series resistor or an open-drain stage. And a touch while plugging the key in drops it into the USB bootloader.
If you build it, please report back how it behaves on your PCB.
That is also a good approach. As I mentioned earlier, even without adding any new variables, the same effect can be achieved by using a touch IC directly. My earlier idea was just more complicated: at the time, I wanted the touch IC to operate only when there was a touch prompt. Given the characteristics of the TTP223, using it that way could indeed be problematic. My previous plan was to experiment with the TTP223 first, and if it really turned out to be problematic, switch to a tiny MCU such as the FT62E210. Using a PRESENCE_PIN variable while keeping the touch IC continuously powered is also a very good option, and it keeps the firmware sufficiently lean.
Area
Build / provisioning
The problem
Suppose the new feature variable is named TOUCH_IO.
After adding this TOUCH_IO variable, true capacitive touch can be achieved either by redesigning the PCB and adding a dedicated capacitive touch IC, or by choosing a small MCU with capacitive touch capability. This makes up for the RP2350's lack of dedicated hardware capacitive-touch GPIO pins.
I plan to make a new RP2350 PCB to implement real capacitive touch, instead of using buttons to simulate touch. I found that adding a GPIO that is controlled to output high or low only when there is a “touch prompt” would perfectly solve this problem. This is just like a real YubiKey, which has a “golden area” touch region. With this TOUCH_IO variable, when building the firmware, the TOUCH_IO variable specifies one of the IOs from 0..29 and whether it should be high or low. Then, during firmware runtime, whenever a touch button is needed, it quickly drives this specified IO high or low. With this IO, many things become possible. For example, I can add a TTP223, which is a capacitive-sensing-based touch detection IC. Or I can use a tiny MCU with capacitive touch capability, such as the FT62E210. Both are in SOT23-6 packages, are very small, and are very inexpensive, around ten to several tens of cents. With such an IC added, the specific workflow is as follows: build the firmware with the TOUCH_IO variable; when the firmware needs a touch during runtime, it quickly drives the specified IO high or low to drive a transistor or MOSFET, which indirectly controls the touch IC to start working. After our finger touches the PCB’s “golden area,” the IC controls the BOOTSEL pin to achieve the touch-button effect. This simulates a real button press, and all of this is automatic, very fast, and very reliable.
Actually, it is also possible not to add the TOUCH_IO variable, and instead directly use the capacitive touch IC to control the BOOTSEL pin to achieve the touch-button effect. The only issue is that the touch IC would then be uncontrolled: every time a finger touches the PCB’s touch area, it would pull the BOOTSEL pin low once. However, frequently pulling the BOOTSEL pin low while the firmware is running normally does not seem to cause any problems. If this feature would be relatively complex to implement, it can also be considered for omission.
Proposed shape
The GPIO controlled by the TOUCH_IO variable is used to drive a transistor or MOSFET, so it cannot be a PWM output; it only has high or low output states, specifically specified when building the firmware. This also requires TOUCH_IO_ACTIVE_HIGH.
Alternatives considered
No response