Frequency of operation (Vs) Charge cycle/dwell cycle times:

The library needs different charge / dwell cycles based on the operation and design. The charge/dwell cycles are determined by the QT_DELAY_CYCLES parameter defined by the user. The recommended range of charge/dwell cycle times that the user must select based on the operating clock frequency of the Microcontroller is provided in the table below.

Fine tuning of the QT_DELAY_CYCLES to match the sensor design may be done by monitoring the reference levels, and finding the charge/dwell time where the reference level has reached >99% of maximum reference value seen. For QTouch acquisition method, the reference value will decrease as the QT_DELAY_CYCLES is increased. For QMatrix acquisition method, the reference value will increase with increase in QT_DELAY_CYCLES. If the cycle time is not optimum, the design may experience temperature sensitivity.

Possible values:

The following table lists the possible values of QT_DELAY_CYCLES for both QTouch and QMatrix acquisition method libraries.

Acquisition method

Possible values

QTouch

Any value from 1- 255 for 8bit AVR

3,4,5,10,25,50 for UC3 and ATSAM libraries

QMatrix

1,2,3,4,5,10,25,50

Example:

When operating at 4 MHz, 1~10 cycle charge times are recommended (0.125us to 1.25us).

Table 2 :  Frequency of operation

Frequency of Microcontroller

(MHz))

microcontroller Cycle time

(us)

Suitable Charge Cycle times (or)

Suitable Dwell Cycle times

(us)

1

1

1 to 2 cycles (1us to 2us)

2

0.5

1 to 5 cycles (0.5us to 2.5us)

4

0.25

1 to 10 cycles (0.25us to 2.5us)

8

0.125

1 to 10 cycles (0.125us to 1.25us)

10

0.1

2 to 25 cycles (0.2us to 2.5us)

16

0.0625

2 to 25 cycles (0.125us to 1.5625us)

20

0.05

3 to 50 cycles (0.15us to 2.5us)

48

0.02083

5~50 cycles (0.104us to 1.04us)

>48

<0.02083

5 to <  50 (up to 255 cycles for 8bit AVR)

Note:

  1. 1.

    For UC3 and ATSAM devices, 1 & 2 charge cycle delay times are not supported.

If the microcontroller is only used for Touch detection then running at the lowest frequency possible for the desired touch response may provide the best power and EMC performance. If it is also used for other functions then running at a higher frequency may be necessary. In some power critical applications it may be worth switching the frequency on the fly, such as lowering the frequency during touch detect API instead of using long cycle times, and then switching to a higher frequency for non-touch code. It is necessary to carefully design timer operation when change frequencies.