Multi-Threshold Touch Detection

Overview

Capacitive touch sensors are typically used to detect whether a finger is in contact with the surface or not. However, to support more advanced user interfaces, it can be beneficial in some applications to detect the contact state of a finger in multiple stages, such as distinguishing between a light touch and a firm touch. To achieve this functionality, the hardware design must ensure sufficient separation between the contact states (e.g., light touch vs. firm press). This article explains how to implement this multi-stage threshold evaluation using RM_TOUCH middleware, the CTSU driver, and the QE for Capacitive Touch.

Note:

If the difference in the measured capacitance between these states is small or unstable, implementing multi-threshold evaluation may lead to unreliable detection results and is therefore not recommended.
Capacitive sensors measure capacitance, not force. Any indication of applied force is inferred from capacitance changes caused by:
- Structural factors: When the overlay material deforms under pressure, the finger comes closer to the electrode, increasing the measured capacitance.
- Physiological factors: When pressed harder, the fingertip spreads out, increasing the contact area with the electrode and thus the effective capacitance.
This article is intended for readers who are already familiar with these software components and have experience using them in application development. If you are new to them, we recommend first reviewing following application note provided by Renesas:
https://www.renesas.com/en/document/apn/using-qe-and-fsp-develop-capacitive-touch-applications

Implementation Guidance

This application adopts a technique where multiple configurations (parameter sets) are assigned to a single touch button, and ON/OFF judgment is performed separately for each configuration.

1. Defining Multiple Configurations

First, using QE for Capacitive Touch (QE tool), you define multiple configurations for the same touch button.

Each configuration has independent settings such as threshold, hysteresis, and filter parameters.
The QE tool generates separate R_CTSU and RM_TOUCH instances corresponding to each configuration you define.

2. Sharing Measurement Results and Independent Evaluation

The Renesas touch middleware (RM_TOUCH) is designed to judge ON/OFF for one configuration at a time. To reuse a single measurement result across multiple configurations, the application must follow below sequence:

Perform a capacitive scan using one configuration, and retrieve the measurement result.
Share the results by copying the measurement result into other configurations.
Call RM_TOUCH_DataGet() for each configurations to determine their individual ON/OFF state.

This approach enables multi-threshold evaluation for a single electrode while keeping the sensor scan count to one per cycle, reducing processing load and preserving responsiveness.

Implementation Example

This section presents a practical implementation example of a two-stage touch detection application using Renesas' capacitive touch solution.

The example assumes three touch buttons, which are evaluated using two configurations:

config0: uses a lower threshold to detect light touches
config1: uses a higher threshold to detect firm touches

By evaluating the three sensor measurements with both configurations, the application can distinguish between light and firm touches.

This implementation consists of the following two parts:

1. Configuration Instance Generation Using QE for Capacitive Touch

Following the "CapTouch Workflow" provided by the QE tool, we define two configurations (config0 and config1), and the tool generates a separate configuration instance for each.

Step 1. Configuration Setup

Proceed to “Prepare a Configuration” step in the Workflow and set up the following:

Add three buttons: Button00, Button01, Button02
Add two configurations: config0, config1
In both configurations, set all three buttons to Available

Step 2. Auto tuning

Proceed to the “Start Tuning” step in the Workflow and run the auto tuning process. Even if multiple configurations are defined, auto tuning will process all configurations sequentially in a single run. For each configuration, follow the QE tool's prompts and apply the your intended finger pressure. The QE tool automatically sets the thresholds for each button in each configuration.

Step 3. Instance Generation

Proceed to “Output Parameter Files” in the Workflow and export the parameter files based on the tuning results. This operation generates instances of R_CTSU and RM_TOUCH for each configuration in the files qe_touch_config.c and qe_touch_config.h. The threshold values for each configuration are stored in global variables that are linked to each instance:

g_qe_touch_button_cfg_config0
g_qe_touch_button_cfg_config1

Importance

Each generated capacitive sensing instance includes threshold settings and parameters, such as measurement frequency (sdpa). The QE tool normally assigns the same sdpa to a button across configurations, since its physical properties do not change. However, if a button’s parasitic capacitance is close to the decision boundary for selecting the measurement frequency, the tool may assign different sdpa values between configurations. This can cause inconsistent sensitivity and reduce the reliability of multi-stage threshold evaluations. If different sdpa values are assigned across configurations, re-run tuning in Advanced Mode to ensure the same sdpa is applied consistently.

2. Application-Level Implementation

Using the two instances generated earlier—config0 (lower threshold) and config1(higher threshold)—the following describes how to implement multi-threshold touch evaluation at the application level. In this example, config0 performs scan, and config1 reuses the results. More detailed explanations for each 'Step' noted in the source code comments are provided below.

touch_instance_ctrl_t * p_touch_instance_config0_ctrl = (touch_instance_ctrl_t *) g_qe_touch_instance_config0.p_ctrl;
touch_instance_ctrl_t * p_touch_instance_config1_ctrl = (touch_instance_ctrl_t *) g_qe_touch_instance_config1.p_ctrl;
 
ctsu_instance_ctrl_t * p_ctsu_instance_no_scan_config_ctrl = (ctsu_instance_ctrl_t *) g_qe_ctsu_instance_config1.p_ctrl;
 
/* Step 1: Open both RM_TOUCH instances */
RM_TOUCH_Open(g_qe_touch_instance_config0.p_ctrl, g_qe_touch_instance_config0.p_cfg);
RM_TOUCH_Open(g_qe_touch_instance_config1.p_ctrl, g_qe_touch_instance_config1.p_cfg);
 
/* Step 2: Skip Initial Offset Tuning for no-scan side */
p_ctsu_instance_no_scan_config_ctrl->tuning = CTSU_TUNING_COMPLETE;
p_ctsu_instance_no_scan_config_ctrl->average = 1;
 
/* Main loop */
while (true)
{
    /* Step 3: Start sensor scan with config0 (scan side) */
    RM_TOUCH_ScanStart(g_qe_touch_instance_config0.p_ctrl);
 
    /* Wait for scan to complete (callback sets flag) */
    while (0 == g_qe_touch_flag) {}
    g_qe_touch_flag = 0;
 
    /* Step 4: Retrieve measurement results with config0 (scan side) */
    R_CTSU_DataGet(g_qe_ctsu_instance_config0.p_ctrl, measurement_result);
 
    /* Step 5: Insert results into config1 (no scan side) */
    R_CTSU_DataInsert(g_qe_ctsu_instance_config1.p_ctrl, measurement_result);
 
    /* step6: Evaluate touch ON/OFF for each configurations independently */
    RM_TOUCH_DataGet(g_qe_touch_instance_config1.p_ctrl, &firm_touch, NULL, NULL);  // high threshold
    RM_TOUCH_DataGet(g_qe_touch_instance_config0.p_ctrl, &light_touch, NULL, NULL); // low threshold
 
    /* Step 7: Synchronize drift correction data between instances */
    for(uint8_t i = 0; i < BUTTON_NUM; i++)
    {
        *(p_touch_instance_config1_ctrl->binfo.p_drift_buf + i) =
            *(p_touch_instance_config0_ctrl->binfo.p_drift_buf + i);
 
        *(p_touch_instance_config1_ctrl->binfo.p_drift_count + i) =
            *(p_touch_instance_config0_ctrl->binfo.p_drift_count + i);
    }
     
    /* Processing according to the intensity of the touch */
}

Step1: Open both RM_TOUCH instances

Call RM_TOUCH_Open() for both instances to initialize their touch configurations and prepare them for measurement.

Step2: Skip Initial Offset Tuning (no-scan side)

Since the instance of config1 reuses measurement results from config0, it does not need to perform its own initial offset tuning. However, the RM_TOUCH middleware requires this tuning to be marked as complete before stating ON/OFF evaluation. To skip it, manually update the instance to indicate that tuning is complete.

Step3: Start sensor scan with config0 (scan side)

Call RM_TOUCH_ScanStart() for config0, which will perform the actual capacitive measurement. Only one instance needs to start the scan since the result will later be reused by the other configuration.

Step4: Retrieve measurement results with config0 (scan side)

Call R_CTSU_DataGet() to obtain the capacitive measurement results using the instance of config0. The second argument of this function is a pointer to a buffer where the measurement results will be stored.

Step5: Insert results into config1 (no-scan side)

Call R_CTSU_DataInsert() to insert the measurement results obtained in Step 4 into the instance config1. the second argument should be the same pointer that was used as the second argument in R_CTSU_DataGet() in Step 4.

Step6: Evaluate touch ON/OFF for each configurations independently

Call RM_TOUCH_DataGet() for each instance to perform threshold evaluation based on the shared measurement data. The function stores the results in the variables passed via pointer in the second argument. A value of 1 indicates that a touch was detected on the corresponding button, while 0 indicates no touch. In this example, light_touch receives the results compared to lower threshold (config0), and firm_touch receives the results compared to higher threshold (config1). By comparing these two outputs, the application can distinguish between no touch, a light touch, and a firm touch.

Step7: Synchronize drift correction data between instances

Drift correction updates the baseline when no finger is detected, helping adapt to environmental changes. Since it runs independently per instance, baselines for the same button may diverge, reducing reliability in multi-threshold evaluations. In higher-threshold configurations, a light touch may be misjudged as "touch OFF," causing incorrect baseline updates. To prevent this, use the drift correction data from the lower-threshold configuration (config0), which more reliably detects a true no-touch state and apply it to the higher-threshold configuration (config1). As a result, both configurations share a consistent baseline, ensuring fair and accurate multi-threshold evaluation.