Help on how to define 2 keypad

[stacey]

I am going to use 2 keypad on the microcontroller but having problem on declaring the keypad.

As for my knowledge, when I using one keypad

include <kbd.c>

then in the program

x=kbd_getc();

How about if I got another keypad.
How to define the second one, and how I know the input is from first or second keypad?

[Ttelmah]

Write your own driver....
Look at the kbd.c driver to see how it works, or the flex keyboard driver (in the code forum).

One possibility (depending on how large they are), is to treat the two together as a single 'larger' pad. There is nothing (for example), to prevent you having 2*2*4 keyboards, and wiring them as one 4*4 keyboard. Then the existing driver could be used, with only slight modifications (adding one more column), and depending what is in the table used to return the values, you could have keys all return different values, or the same values from some (shared 'enter' for example).

I have used this in the past, with a 4*1 keyboard, which sits alongside a display, and a 3*4 keyboard below. They are scanned as 4*4, with one key on each pad being 'enter', then 0-9, and decimal on the pad below the display, while the one beside the display has up/down, and 'select' (moves you to the next menu, while 'enter' finishes the input).

Best Wishes

[stacey]

If write my own driver mean I write a new kbd1.c right?

When read the number from keypad, you use kbd1_getchar ? Is that my understanding correct?

[Ttelmah]

You can call your own driver, whatever you want. Could be 'fred'....

However using names that relate to what things 'do', always helps keep things simpler. 'doublekeypad' might be relatively informative. As a general comment, better to use .h, for 'included' files. CCS, are a little naughty here, and using .c, gives problems with MPLAB, which by default, assumes anything called .c, is meant to be compiled separately.
If you are not including kbd.c, then you can call your function kbd_getchar, or whatever you want...

Personally, I tend to have my code always running a 'tick' usually at a rate like 50 to 100Hz, and scan keyboards in this, rather than using delays, so you have a state machine in the tick, and just set all columns 'low', and see if any row is pulled down. If not, no key.
If one is low, then you do a bit scan to identify the key, and advance a state.
Next time (debounce), if the key is still 'on', record it into a buffer, and advance a state.
Depending on the behaviour I want, I either just ignore the signal until the key is released, or may have the key automatically repeat after a number of counts. In each case the time spent in each tick is kept short. If a delay is wanted, I just exit, and do the operation on the next tick.
I tend to use ring buffers for everything, serial receive, serial transmit, SPI, keyboard, even LCD output. keyhit, then just involves testing if the keyboard ring buffer contains any characters. As already explained, you have the decision of whether to have two keyboard buffers, with separate tests on each, or just to treat the two keyboards as returning different values, and use one buffer.

Best Wishes