Reply
Posts: 5
Registered: ‎02-27-2017

CPT112S: how to get current state after event buffer overflow

[ Edited ]

The CPT112S event buffer might overflow, resulting in some events to get lost. This can be detected by evaluating the packet counter.

 

As it's not possible to know which events got lost, for a driver to successfully recover, it needs to retrieve the current state of the sensors.

 

How can a driver retrieve the current state of the sensors?

The datasheet doesn't mention a way, so my actual question is: how can a driver recover after an event buffer overflow?

Posts: 492
Registered: ‎02-04-2013

Re: CPT112S: how to get current state after event buffer overflow


hroosen wrote:

 

 

How can a driver retrieve the current state of the sensors?

The datasheet doesn't mention a way, so my actual question is: how can a driver recover after an event buffer overflow?


It sounds like you can't fully recover from the buffer overflow.  Perhaps if you used touch timeouts, you'd at least know after the timeout period had elapsed, that all sensors would return to untouched state.  Then any new state updates would be transitions from untouched state.

 

I'll check with the Interface team to see if there's a recommended method to handle this overflow.

 

Best regards,

Chris

Posts: 492
Registered: ‎02-04-2013

Re: CPT112S: how to get current state after event buffer overflow

I have confirmed with the interface team that there is no supported method to retrieve the current state of the CPT112S sensors.  You would generally assume that all sensors are in the untouched state, but this is not always the case.

 

The key is to prevent the buffer overflow by making sure to read the I2C data regularly.  I would recommend using an interrupt on the host device to make sure the buffer doesn't overflow.

 

Best regards,

Chris

Posts: 5
Registered: ‎02-27-2017

Re: CPT112S: how to get current state after event buffer overflow

Hi Chris,

 

Thank you for your reply. I'm already using an interrupt in my driver. I just wanted to have a good fall-back strategy in case packets get lost. As the hardware has no interface to support this I'll have some fall-back strategy implemented in software, which is far from ideal :-( unfortunately.

 

If the interface team is thinking of adding functionality to the host-interface it would be good to consider this. Also it would be great if the host-interface would have functionality to read out the device's configuration (like: how many buttons are configured, slider max value, etc), or even a way to change parameters...

 

Thanks,

Henri