Reading Keypad MPLab Assembly

[jpanhalt]

In a previous post I showed a nice box (https://www.eevblog.com/forum/mechanical-engineering/mitutoyo-982-537-1-dro-display-with-series-572-linear-scales/msg5287843/#msg5287843  ).  I'd like to use that keypad now.  My device of choice is an enhanced, mid-range PIC16F1xxx using MPLab Assembly 8.92.

Attached are two images of how the pads are arranged according to the 9-conductor FFC numbered L to R, 1..9.  There seem to be 2 sets: SetA = conductors 1..5 and SetB = 6..9, i.e., 20 combinations for 20 keys.

In previous projects reading smaller keysets, I just converted the key/port pin to a number and used a jump table.  I could easily do the same with four jump tables or a table of tables as described years ago by Peter Anderson at Johns Hopkins.

My question: Is there a simpler, perhaps more obvious way?  I am not adverse to adding a new chip that would convert the 9-inputs to a 5-bit number.  If so, please recommend a multiplexer chip that can do that.

EDIT: Added a single table that may be clearer.

[jwet]

It depends how code starved you are.  I did a lot of assembly with <2k or ROM. 

Here is something to try perhaps, if not smaller, might be easier to understand than just a bunch of RETLW   code statements.

You can observe that all the numbers are either an 8 or a 9.  You could branch somewhere and decode the things.  Its likely that all numbers get handled the same way so after decoding them, you'll fall through to some common code (append digit).

The cursor keys are almost all 7's, you could do similar two stage decode.

You'll probably find that you end up with the same size.

Look up tables are pretty efficient, especially if you run them through a c compiler- good C compilers use tricks like folding, etc and can improve your logic.  You can do all the same in assy.

Have fun.

[jpanhalt]

I love coding in Assembly.  It's fun and relaxing.  While modern PIC's have much more room, I enjoy the challenge of keeping the code tight.  The instruction set for enhanced 16F  PIC's was improved a little. 

I just worked out a bit of code to do what I want.  Basically I need to convert a set PORT pin to a bit position, not binary value, to keep the table small.  That doesn't take a lot of code for bits 0..3 (i.e., Set B in the revised single table).  From there, it's a typical jump  table.

When I get something working, I will post it here.  Right now, it's about time to receive Sunday calls from my children and start dinner.

John

[Benta]

Dunno why you have a problem with this.
It's obviously a 4 x 5 matrix. Super easy to decode (hardware-wise).

Whether you then use the result in a table or bitwise is up to you.

[jpanhalt]

So far as I know, the PIC 16F1xxx chips do not have hardware decoding.  Can you give a simple example?  It's obvious how to do it with 2 ports and some firmware, and that is what my rough code does.

[jpanhalt]

UPDATE

I've fiddled with the 4x5 table and came up with this.  It is untested.

Code: [Select]

Keyboard
;Use hypothetical PORTB for the 4 switches of the 4X5 matrix
;after key press, jump to ISR, and process PORTB(4) and PORTC (5) 
;delay 40 msecs for debounce
 
     lsrf      PORTB,w        ;STATUS,0 has state of RB0
     andlw     0x07           ;PORTx > lsrf > if WREG,2 set
     btfsc     WREG,2         ;0001    0000   0000     
     movlw     3              ;0010    0001   0001
                              ;0100    0010   0010       
                              ;1000    0100   0011
     btfsc     PORTC,S1       
     bra       DoS1
     btfsc     PORTC,S2
     bra       DoS2
     btfsc     PORTC,S3
     bra       DoS3
     btfsc     PORTC,S4
     bra       DoS4
     btfsc     PORTC,S5
     bra       DoS5
     bra       Main           ;exit ISR or ERR --> exit ISR
DoS1
     brw                     
     bra       ESC
     bra       _SET
     bra       Num0
     bra       Num7
DoS2
     brw     
     bra       ALM               
     bra       Right
     bra       Num3
     bra       Num8
DoS3
     brw
     bra       Dec                       
     bra       ENT
     bra       Num2
     bra       Num9
DoS4
     brw
     bra       Inc
     bra       CLR
     bra       Num1
     bra       Num4
DoS5
     brw
     bra       Left
     bra       ChgSign
     bra       Num6
     bra       Num5

ESC
_SET
ALM
ENT
CLR
Right
Left
Inc
Dec
ChgSign
Num0
Num1
Num2
Num3
Num4
Num5
Num6
Num7
Num8
Num9
Err
     nop
     bra       Main


[Benta]

I don't know the PIC, nor its assembly language.

But the way to do it works like this (you need an input port with interrupt capability!)
The ports you're using must be bidirectional.

All pins from your keyboard need pull-up resistors, say, 47 kohm.

Connect 5 pins to the interrupt capable input port. Connect 4 pins to another port and set the pins to output, low.

If a key is pressed, the input port will issue an interrupt.
Wait a moment (debouncing) and read the port and store.

Reverse the ports, making the first one output, low, and make the the second port input. Read the second port and store.

End the interrupt.

You now have the coordinates of the pressed key in your 5 x 4 matrix.

Decoding it should be trivial.

[jpanhalt]

Thanks.

The PIC16F1xxx  ("Enhanced mid-range") are just 14-bit core, 8-bit MCU's, which forces quite a bit of banking and occasional paging compared to 16-bit cores, and of course real 16-bit MCU's.  They have limited math, but the instruction set is easy to remember, and they have one level of interrupt. That has not been a problem for me as a hobbyist. (The 12F5xx and 16F5xx do not have interrupts.)

I am pretty familiar with using that type of interrupt and will integrate it into my "Main" routine.  The whole purpose of this project is to control infeed of a lathe while threading, particularly while doing female threads with a small tpi (i.e., 8 tpi).  More than a decade ago, I did that with a simple dial indicator where all I monitored was to detect the change from + to -.   That worked, but was clumsy.  I am fitting those old Mitutoyo scales from my mill to my lathe, and they output the Mitutoyo SPC format in mm only.  So, there is a lot more to entering a preset and testing when that endpoint is reached.

The parts of this project are pretty much done.  Now, all I have to do is glue them together.  Overall, the Assembly code is pretty compact.  The limits are 00.000" +/- 0.0005", with a maximum of 99 cm.  The Mitutoyo scales read to 0.01 mm, but that's resolution, not accuracy.

John

[Benta]

A tip when decoding:
Use shift/rotate instructions to find the right key. That will eliminate the risk of multiple keypresses falsely/out-of-range being decoded.

[jpanhalt]

UPDATE

The algorithm was implemented on breadboard using IOC registers, but not an interrupt at this time.  That made debugging a bit easier.  In its final embodiment, it will be interrupt based, so the keyboard can be active most of the time. 

Attachments show the progress.  No picture of the solderless breadboard is included as that would be an embarrassment.  I switched to the PIC16F1783 to get 28 pins, all of which have IOC capability.  A new LCD 192x64 with SPI capability (ST7525 controller) should be here in a few days and should be mounting-hole compatible with the existing GLCD LCD.  I like that series of controller.  They are fast and generally require only one CS pin.

Attachments:
1) Faceplate of the now repurposed device shown earlier (OP320-A/OP320-A-S)
2) Keyboard pinout (Word doc)
3) Schematic (Eagle)
4) Breadboard wiring (Eagle)
5) Code (MPLab 8.92 Assembly)

EDIT: There's a typo in the 2nd attachment. A and B are reversed,  Everything was developed as shown, but I had penciled in  PORTB for A and visa versa.  When I posted here, I changed one but not the other.  I will leave it be and the error should be obvious.
EDIT2: Added attachment with dimensions for SparkFun large protoboard so FFC from keypad lines up with holes in the board.