Snippet needed for Prop and the MM74C922 keypad encoder

idbruce · 2010-12-24 21:49

Hello Everyone

I need a snippet of code to interface the MM74C922 keypad encoder with the Propeller chip, or at least a little discussion about implementation.

As I understand it, the Data Available pin goes high when data is available. From there I am assuming that when a key is pressed, pins A, B, C, and D go high or low dependant upon which key is pressed and coinciding with the truth table in the data sheet. Providing that I am correct in my assumptions, how do you let the chip know that you have acquired the data and to reset.

As always, I have so kindly provided the datasheet for your viewing pleasure

Bruce

Ale · 2010-12-24 23:10

After reading (again) the datasheet... I can let you know that the chip does not care if you acquired the data or not. If you look at the diagram of page 3 you see that the only input pin (interface) is OE and that only enables the three-state drivers.

A snippet of code... how about.... one waitpeq, one out and one in ?... I'm sure you can do it yourself

have fun

JonnyMac · 2010-12-25 09:30

I don't have one of those chips but I do have a big cup of coffee and the yule log video playing on the TV. The attached program should get you started. It's very simple, intended to let you verify the hardware. Once that works you can create a more sophisticated program that buffers key press events.

Merry Christmas!

idbruce · 2010-12-25 10:35

Thanks Ale -> I was looking for a little more information though, however, the waitpeq worked out for me, as well as the waitpne. I have never used those functions before, and now that I know they exist and how to use them, I will put them to great use.

Thanks Jon -> Now that's a lot better. I have saved your snippet for future use and reference, however, by the time that I got your post, I had already created another snippet of my own. I am sure that I will use both yours and mine, because I have a very difficult user inteface to code. Each button will be able to perfom several different functions, being dependant upon which point in the program that the button is pressed. I like both of our snippets, because yours is free wheelin' and mine is confined within a cog. Thanks again Jon.

I have posted my snippet to the object exchange and attached it here for everyones viewing pleasure.

OBEX Link http://obex.parallax.com/objects/694/

Merry Christmas To All

Bruce

JonnyMac · 2010-12-25 13:03

If you're going to run the key input in its own cog you may as well go full tilt boogie with it. If you would, give the attached program a try and let me know if it works (I don't have a chip). It creates an object that captures and buffers key inputs (up to 15).

Edit: I found an error in the start() method and have corrected it (this is the problem with not having hardware to test with). Since I was getting creative, I added a couple more methods that I think may be useful and updated the demo program for the MM74C922 object. My apologies that to those that tried to use the version I posted yesterday -- it was Christmas and I was, perhaps, over-joyful!

Edit: I believe I found the error that was giving Bruce troubles; new version posted below.

idbruce · 2010-12-25 13:50

Jon -> Thanks for the additional code and yes I will certainly give it a test, however, give me until sometime later today or tomorrow. I have the Christmas duty stuff to get through. I would much rather stay and work on my project. BAH HUMBUG.

Merry Christmas Jon

Bruce

idbruce · 2010-12-26 05:21

Jon

Well that was interesting, I learned something valuable from testing your code. After testing it, I had to update my code in OBEX.

Here is what I learned. I was outputting decimal to the serial terminal and you were outputting hex. You probably already know the difference in the output, but I will share it anyway just so that others may learn from it. Here are the results:

Decimal Results: 0-15
Hex Results: 0-9 + A-F

For my application, decimal results are better for me. However, if someone is using a 4 X 4 matrix keypad similar to the one distributed by parallax and outputting to an LCD display, then hex would be best for alpha characters.

I would suggest inserting waitpeq and waitpne into your code like I did, because in your code the result is repeated while the button is held down. Since the data is latched, there should only be one character instead of a repeat. Besides that it works perfectly. Not bad for not having a chip at your disposal. Nice work!

Bruce

JonnyMac · 2010-12-26 09:49

Which version are you talking about? -- I provided two. The second, written in PASM, does in fact uses WAITPEQ and WAITPNE and also buffers the key inputs so that one can be busy and not miss any key press events. The first code was just to test hardware, the second is more a candidate for ObEx when I know it's working correctly. Note that I only put things in ObEx that are very modular and flexible, hence there test code and actual 74C922 object code (in the second post) are separate files. This lets the user display the key data in any format he/she chooses.

JonnyMac · 2010-12-26 12:04

Whoops... found an error in my start() method in the jm_mm74c922.spin file. That is fixed and I've added a couple new methods as well as a new demo. Thanks for having a look.

Updated file is posted above.

idbruce · 2010-12-26 18:44

Jon

Now you got me wondering which one I tested. I thought I tested them both.

Okay, here is the situation now.

MM74C922 Test -- V3

-- buffer empty
-- buffer empty
-- buffer empty
-- buffer empty
-- buffer empty

It just keeps repeating "-- buffer empty", irregardless of which buttons I press or how often I press. It does look like it will be a nice piece of code though. It looks as though you are storing multiple key presses in a single buffer.

I don't understand your code completely, but at a glance it appears that you are writing this code for the 74C923, instead of the 74C922.

K_MSB = 4 ' E output

E output is for the 74C923 twenty key encoder only. Additionally, the 74C922 only requires 5 pins, where the 74C923 requires 6 pins. Or perhaps I am misunderstanding your code completely.

Bruce

JonnyMac · 2010-12-26 21:39

Well, darn, I thought that would be easy. The data sheet I have shows 5 output bits -- I guess it covers both parts. I'll order a chip and get that code fixed, and adjusting "down" to the 922 is simply a matter of changing the KEYS_MASK constant (to %1111) in the PASM code.

Thanks for giving it a try.

idbruce · 2010-12-27 03:07

Jon

Yea Jon I realize it is a matter of just removing one pin

. Anyhow I like the fact that it can get data from the 74C922, as well as the 74C923, because it will give the end user more options. I was just thinking that your code should be more aptly named jm_mm74C922_or_mm74C923_test. May I suggest just adding a parameter to your start method which would specify which chip is being used, and then use a couple conditions to set your key mask.

You are welcome Jon. I am sure it will be a nice object once you get the chip and can test more easily.

Bruce

Clive Wakeham · 2010-12-29 03:16

Providing that I am correct in my assumptions, how do you let the chip know that you have acquired the data and to reset.

I am currently implementing to interface a 74C923 to the Propeller via a I2C interface chip!

In the mean time I have linked the 74C923 to a Basic Stamp (for testing purposes of the hardware). I currently have the OE (Output Enable) pin pulled high. My simple little program checks the DA pin and if high then pulls the OE pin low and then reads the data. This resets the DA pin (according to the data sheet -- and it works in my example).

My program then waits until the DA pin goes low and then loops back to wait for the DA pin to go high again. I found that this stops multiple keystrokes from holding a key down but will output the multiple keys if pressed after each other including the same key.

As for the truth table I ended up just outputting the binary codes until I set up my own truth table via a PBasic Lookup command.

At the moment I have a 4x4 keypad, but will be adding an extra row of pushbuttons for "command keys". One of these will debounce directly to a Propeller pin (like a ESC or Break key) to alert the Prop that the user wants to input via the keypad.

Regards,

idbruce · 2010-12-29 04:00

Clive - Thanks for the info

JonnyMac · 2011-01-10 11:41

Since you brought up the MM7C922 again (in another thread) I re-opened the code to see if I could find the source of the problem you reported. Found a simple typo in the PASM code; I believe it will work now. Here's the fix.

idbruce · 2011-05-29 05:25

@JonnyMac - It has been several months since we discussed this chip. I was wondering if you ever got it and experimented with it.

More particularly, I was wondering if you had the chance to experiment with the debounce and scanning capacitors. There are times when an intended single button press acts like multiple button presses and bypasses sections of code because they both require the same button press for user input (e.g. - Yes or No).

I initially used 0.1uF capacitors for both debouncing and scanning, but then increased both of these to a larger value of 1uF in an attempt to eliminate the problem, but it still bypasses the same sections of code. Since I am able to read the button presses, I assume this is more an issue of scanning than of contact bounce. I am considering another increase in value of the scanning capacitor, perhaps 10 or 20uF.

Would you have any input on this issue?

With a value of 10uF, the scan rate should be approximately 10kHz, as compared to the approximate 70Hz that it is now.

Bruce

EDIT: Perhaps changing the existing code would help.

FROM:

PUB MonitorKeypad
  DIRA[0..3]~  
  DIRA[5]~     
  REPEAT  
  
    WAITPEQ(|<5, |<5, 0)
    KeyPressed := TRUE      
    
    PressedKey := INA[3..0]      
    WAITPNE(|<5, |<5, 0)

TO:

PUB MonitorKeypad
  DIRA[0..3]~  
  DIRA[5]~     
  REPEAT  
  
    WAITPEQ(|<5, |<5, 0)          
    WAITPNE(|<5, |<5, 0)
    KeyPressed := TRUE      
    
    PressedKey := INA[3..0]

JonnyMac · 2011-05-29 05:56

I do not have that chip; I wrote the interface code for you based on the data sheet.

idbruce · 2011-05-29 06:03

Hey Jon

I'll order a chip

Sorry, I thought you may have ordered it, because it seems like it would have fit into some of your projects. It is a nice chip if I can get it to work right. I think my suggested code change might work out well.

Bruce

JonnyMac · 2011-05-29 06:18

Well, I changed my mind. I don't need the chip, and it's not available through Mouser which is where I get my parts. Sometimes you just have to suck it up and figure out for yourself, which is what you seem to be doing. I'm sure that wonderful metal and cabinet work you do doesn't come instantly, why should the electrical side of engineering?

idbruce · 2011-05-29 06:37

@JonnyMac - Thanks for the compliment about the metal and cabinet work

Just in case you do use that chip in the future, the following code change resolved my problem. This change reduced capable key press speed, but it appears to be very reliable. Additionally, as previously mentioned, I am using 1uF for both the debounce and scanning capacitors.

FROM:

PUB MonitorKeypad
  DIRA[0..3]~  
  DIRA[5]~     
  REPEAT  
    WAITPEQ(|<5, |<5, 0)
    KeyPressed := TRUE    
    PressedKey := INA[3..0]
    WAITPNE(|<5, |<5, 0)

TO:

PUB MonitorKeypad
  DIRA[0..3]~  
  DIRA[5]~     
  REPEAT  
    WAITPEQ(|<5, |<5, 0)
    WAITPNE(|<5, |<5, 0)
    WAITCNT(CLKFREQ / 4 + CNT)
    KeyPressed := TRUE    
    PressedKey := INA[3..0]

Bruce

idbruce · 2011-05-29 07:02

To All Concerned

Here is another modification that allows faster key press processing and appears to be just as reliable.

PUB MonitorKeypad
  DIRA[0..3]~  
  DIRA[5]~     
  REPEAT  
    WAITPEQ(|<5, |<5, 0)
    WAITPNE(|<5, |<5, 0)
    WAITCNT(CLKFREQ / 7 + CNT)
    KeyPressed := TRUE    
    PressedKey := INA[3..0]

Bruce

JonnyMac · 2011-05-29 07:32

As ever, I will caution newcomers NOT to embed pin #s into code -- this makes the code something less than portable and prone to bugs when projects change. Another thing that snippet doesn't indicate is that is is actually launched into its own cog using cognew. If you called this method like a regular method your program would be trapped in the repeat loop.

idbruce · 2011-05-29 07:35

Once again, you are correct Jon. Please heed Jon's warnings.

Bruce

Snippet needed for Prop and the MM74C922 keypad encoder

Comments