reading a 4x4 switch matrix

Status
Not open for further replies.
DIM Keyvalue AS BYTE Really simple you didn't use it LOL
So your all saying its short for saying...you didnt use the working code examples? .

You need to know basic error messages, no idea if its in SF but stuff like syntax errors, you have to know what they mean or your not going anywhere.
 
It really doesn't mean nothing all it's saying is he had a variable named Keyvalue and he didn't use it LOL
 
Here his code no Keyvalue used
Code:
DEVICE=18f2420
CLOCK = 8 ' Tell the compiler what we will be setting the clock to (Mhz)
CONFIG MCLRE = OFF
'CONFIG fOSC = INTIO67 ' Internal oscillator, IO on pins 6 and 7
'INCLUDE "INTOSC8.bas"
'config "InternalOscillator.bas" 
'#option LCD_DATA = PORTC.4
'#option LCD_RS = PORTC.0
'#option LCD_EN = PORTC.1
INCLUDE "SetDigitalIO.bas" // Include this file when we compile so that we can use keywords like 'setalldigital'
INCLUDE "utils.bas"
INCLUDE "convert.bas" //xxxxx 
'INCLUDE "LCD.bas" 
INCLUDE "keypad16pullup.bas"
INCLUDE "usart.bas"
DIM Keypressed AS BYTE
DIM Keyvalue AS BYTE
SetBaudrate(br4800)
DELAYMS(5000)
USART.Write ("Test program",13, 10, 10)
WHILE 1 = 1
Keypressed = keypad16.Value
IF Keypressed <> 0 THEN
USART.Write ("Key pressed = ", HexToStr(Keypressed), 13, 10)
END IF
WEND
 
He also didnt use three working examples of code, but he did get a few error messages for those lol

Jon you had your meds yet and come back?
 
I can't get strong enough meds any more. The MrDEB. help desk needs somebody new at the helm.

Yes, I dimensioned KeyValue at Byte with the thought I would need to translate keys but they were in the expected order so I didn't need to.


The "Variable declared but never used" isn't actually an error message. It's an advisory message that means exactly what it says. Usually it's not a problem, but it could be a problem showing you mispelled a variable name or something like that.
 
I decided to use the perf board with the 18F4321 mounted on it, change the keypad back to the B port, burn the pic and remove the Pickit2 and connect a battery pack.
After about an hour getting all my wholesale changes back to where they should be I still had an issue getting the LCD to display correctly.
BAM! I had printed out the "hello World" code and started comparing to what I had on the screen. I discovered I had the OPTIONS for the Lcd after the DIM statements. Corrected and now the dang code works. Not sure of which keypad pins are rows and colums but got it working. I even included a blinking Led to confirm the pic is working as required.
My next plan is to map out what each key outputs and and have the LCD display desired info.Thanks for all the suggestions
Oh yea the compiled code uses 1013 prg bytes and 100 variable bytes
 
It is a Dominoes counter for playing Mexican train.
When a player gets caught with LOT's of dominoes they need to add them all up for their round score (there are 13 rounds in one game when playing with a double 12 set of dominoes).
Now I need to figure out how to add up each keypress for a total without any extra + key. We plan to maybe start playing a double 15 set of dominoes so the 4 x 4 keypad is all used up.
While working on this code I came up with DIYing the membrane keypad (search google) and having the keypad, LCD, and pic all on one printed circuit board.
Thanks for all the help
 
Oh my goodness! I searched for 'Mexican Train' and I'm so embarrassed. I had no idea there were so many games for dominoes. Have I led a sheltered life or what?

So your project is for keeping score after each round through the thirteen rounds? If you have time, I'd love to hear more...

Cheerful regards, Mike
 
Speaking of keypads... I've used an inexpensive IR Remote (below) with a custom keypad overlay on a couple projects. It cost about $1.12, including shipping, and it only requires a single pin on the host for a TSOP4838 or similar IR Receiver IC. If you have an LCD 'backpack' (serial or I2C) you'd only need another one or two pins on the host to drive the LCD.

Food for thought... Regards...



 

Attachments

  • 12F1822 NEC IR Decoder.asm
    14.4 KB · Views: 273
Last edited:
Thanks Mike. YES Mexican Train is a really fun game. We play two times a month here in town.
Keeping score is a chore at best especially if you get stuck with a bunch of dominoes. And to add insult to injury, if you get stuck with the double blank, add 50 points to your score.
What I am trying to do at this point is have each player with a calculator (this project) that adds up their dominoes each round and the LCD to display total of each round and total score of all played rounds.
The I2C idea would save having to assemble several calculators but may add to the confusion that already exists when playing?
I have a game hub that has LED switches instead of using tiny plastic pieces.
 
So each player has one of these "calculators" which has an LCD and a 16-key keypad. At the end of each round each player would use his "calculator" to tally his/her points for that round. The "calculator" also shows the cumulative points up to the last (thirteenth) round.

May I ask how you're planning the keypad, please? I reason you'll need '0' through '9' keys, a couple operator keys, and perhaps a 'clear' or 'start' key. What are the other key functions and why do you think 16 keys may not be enough? Also, are you using a standard 2x16 HD44780 type LCD?

<added>
here's another IR remote I've used in the past. I think it was a couple dollars.

 
Last edited:
Each player would have a calculator that has 16 keys. Each key will represent one half of the dominoes spots (a 12 / 5 domino as an example)
player presses the 12 key then the 5 key (the keys will have the domino face on it as well as the spots color.
there will be no + key just domino faces 1 to 15 and a double blank key.
Each caculaor will have a standard 2x16 HD44780 type LCD and 16 keys
Originally was going to have PCboard silkscreened with dominoes faces but after researching I discovered a DIY membrane keypad is fairly easy to make after a printed circuit board is designed which I basically have half done. Some acetate sheet, aluminium tape and a color laser printer should do the deed hopefully.
 
Mike,
This thread got started just 3 weeks ago, and now with your suggestions I believe we can get to over 500 posts before the end of the month. So come on everyone! Let's get that post count up.

Total lack of understanding of Mike's solution was demonstrated when MrDEB focused on the "I2C idea" which is but an incidental, unrelated and unnecessary part of using IR keypads. I think 500 posts is far too optimistic if he decided to try that route!

I'm just here for the popcorn now.
 
MrDEB (and gang). I apologize for asking so many questions. I'm just trying to understand the design goals a little better.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…