CAF Click Detector events too slow (latency)

[neo_here]

Hi, 

I have been testing the CAF click detector module and I find that any event callback after the click event takes almost 1000ms. That is the time between the actual click and the event trigger in the configured module seems too long. 

I've played around with the timeout configs but the events still seem to take too long. 

Is there a way to make it more responsive without implementing a custom solution? 

[neo_here]

Hi Swathy, 

I was able to mess around a bit more, found that the button events themselves have a latency of about 500ms which adds to the click detector latency. 

I was looking through buttons.c and wondering if the reason they're delayed is because of the usage of delayable work units.

static struct k_work_delayable matrix_scan;
static struct k_work_delayable button_pressed;

I'm wondering if the delay is caused due to the kernel context switch from sysworkq at -1 priority to a delayable work unit. 

[neo_here]

Looks like most of the delay is caused due to the the code written to prevent debouncing and ghosting. 

At stock configs for 

#define SCAN_INTERVAL CONFIG_CAF_BUTTONS_SCAN_INTERVAL
#define DEBOUNCE_INTERVAL CONFIG_CAF_BUTTONS_DEBOUNCE_INTERVAL

I see the scan function being called anywhere from 20-100 times. Which adds varying amounts of delay before the events are sent out. Every call of scan_fn adds about 3-4ms of delay. 

static void scan_fn(
struct k_work* work)

[neo_here]

Specifically this condition

if ((is_pressed != was_pressed)
&& (is_pressed == is_raw_pressed)
&& (evt_limit < CONFIG_CAF_BUTTONS_EVENT_LIMIT))
{
}

(is_pressed != was_pressed) this condition takes about 20-100 scans to evaluate to true. With the scan interval set to 2ms, is this amount of settling time normal ? I'm guessing this delay depends on what kind of debouncing we have on the hardware side as well ? 

[neo_here]

The debounce logic seems to be taking too much time. It would be great if someone could help me debug this.

[neo_here]

Looks like the delay is mostly because of the logger running at a much lower priority than other threads. Even with RTT you'll need to enable immediate logging to see the actual latency times. 

So testing the latency with logging is not a great idea. Although as I looked through the button debounce/ghosting logic it seems very conservative.

Anyways, hoping this helps someone.