This topic explains what you need to do to property set up the kp. object. All preparations should be made with the keypad disabled (kp.enabled= 0- NO), or this setup won't work.

Mapping scan and return lines

First, you need to define the list of scan and return lines. One great feature of the kp. object is that you can assign ("map") any I/O line of your device to be a scan or return line. I/O lines serving as scan or return lines don't even have to be "together" (have consecutive numbers). Scan lines are assigned through the kp.scanlinesmapping property, return lines -- through the kp.returnlinesmapping property. For example, here is how you select lines 24, 20, and 27 to serve as scan lines, and 28, 21, and 25 to serve as return lines:

On platforms with output buffer control each scan line must be configured as output, each return line -- as input (shown in the example above).

Notice how we did not have any order in specifying return and scan lines -- this simply does not matter. Select any lines, order then in any way you want. The only limitations are:

Line numbers are platform-dependent. They come from pl_io_num found in the "Platform-dependent Constants" section of your platform documentation. The pl_io_num is a list of constants like "PL_IO_NUM_24". You cannot just drop "PL_IO_NUM_24" into kp.scanlinesmapping (or kp.returnlinesmapping). The correct way is to write "24" or use str(PL_IO_NUM_24). So, another way to do the above setup would look like this:

Notice that no matter how you set kp.scanlinesmapping and kp.returnlinesmapping, reading them will always return a simple list of numbers (shown in the example above).

Defining state transition delays

Your second step is to set proper delay times for key state transitions. Five different properties are responsible for that: kp.pressdelay, kp.longpressdelay, kp.repeatdelay, kp.releasedelay, and kp.longreleasedelay. Each property sets the transition delay time in 10ms increments. Setting a property to 0 means that the corresponding transition will never happen. Note that the maximum value for each property is 254, not 255. All five properties already have sensible default values, so you only need to change them if you don't like what we have chosen for you:

Keypad auto-disable

Finally, you can select several event/code combinations that will automatically disable the keypad. This is done through the kp.autodisablecodes property. Each time one of the pre-sent combinations of the key state and key code is detected, the kp.enabled property will be set to 0- NO, thus preventing further input until you re-enable the keypad.

This behavior can be very useful. Supposing, you have an application where you need to enter a certain code, then press <ENTER>. After you press <ENTER>, your application processes the input, which may take some time. What you often need is to prevent any further keypad input while the code is being processed. If you do not do this, the user might continue punching away and creating garbage input that your system does not need. This might even overwhelm the keypad buffer (see Servicing Keypad Events). The kp.autodisablecodes makes sure that the input stops at a certain event/code combination. Up to four such combinations can be defined.

Here is an example of how this property could be set:

Once all the properties have been preset, enable the kp. object (kp.enabled= 1- YES), and start processing keypad events.