reading a 4x4 switch matrix

Status
Not open for further replies.
My 3 cents... The IR keypad has legs... presumably only one 'Mexican' player is scoring at any time , so only one keypad needed , and passed around , in this 'current' 4x4 matrix project does each player have a LCD+ keypad ? or did I totally misunderstand. ( in my experience PIC needs many Hrz to cope with IR protocol ) ...
 
Scoring is at the end of a round, after someone has played all there dominos. Whatever you haven't played counts against you. I think that's right; it's been years since I've played. Dominos can have up to 16 pips on each end. "Double nine" dominos arw pictured below.

Explaining design goals is not one of MrDEB's strengths - I expect because those goals aren't so well formulated to atart with.

 
Has to be a simple code layout?
I want to input a key (lets say 5)
then enter 2 (#2 key)
total without entering a + key etc should be 7 for the total but getting the right format?
just hacking away and hopefully get it correct??
 
forgot to post code in progress
 
Hey guys. What do you think about a design using a 0.96-inch 128 x 64 I2C OLED display (2 pins), a Rotary Encoder + switch (3 pins), and a piezo speaker (1 pin) instead of the keypad and 2x16 LCD combination for this project? An 8-pin PIC should work fine unless you need more pins for some other functions. The entire project, including a lithium-ion or similar battery, could be very compact.

At the end of each round you would use the Rotary Encoder to graphically display the Domino values and a 'short' press on the built-in switch would add the displayed Domino value to your total. Use a 'long' press to enter a menu where you can (1) adjust display brightness, (2) select "double 12" or "double 15" Domino sets, (3) adjust 'sleep' inactivity time-out, or, (4) 'clear' the total to start a new game.

While this might be considered an 'advanced' project for some and while I wouldn't be much help with Swordfish BASIC, I would be happy to contribute to the project if it uses XC8 or assembly language.

Anyway, food for thought... And my apologies for potentially adding to the length of the thread...

Cheerful regards, Mike, K8LH

 
Mike, those oLED displays are awesome and surprisingly legible for such a small size, even with small text.

But to be honest, that would be a horrible interface. Remember, each domino has a value at each end. Say you had a 9 / 16 domino. Twist the encoder looking for the 9 dot pattern. Press the encoder. Twist the encoder looking for the 16 dot pattern. Press the encoder. Try repeating that 20 or 30 times! A color display would help with pattern recognition as patterns have different colors but I'm not sure the color code is consistent.
 
There is a 1.3" OLED version , needs quite a bit of code / data , this was my SS decode method by OR ing segments into a blank frame , the IR key pad could do the double 16 domino .
 
How about a free phone app that will keep track of up to 6 players' scores?

I suspect MrDEB is having enough problems with his project that all of these other ideas may not be too helpful.

I know I have been frustrated here in the past when I've asked a question, and rather than answers to that question, I have been told that whatever I was trying to do was wrong. Not specifically what I was asking about, but the entire thing I was trying to do. Sometimes, making people aware of alternatives is good, but asking if a specific thing can be done doesn't mean the whole concept is open to re-engineering.

It's taken nearly 300 posts to get to what should be 20 lines of code, but it looks like he's almost to the end (thank whatever deity is appropriate!)... or at least to a somewhat working prototype. Maybe now is not the time to introduce a graphic LCD (with the need for font files amd graphic files or routines), IR keypads (and the need to decode IR signals) or rotary encoders (and the need to read them). Just my opinion, but if you've ever followed one of these epic threads from beginning to end, you will understand.


 
I'm just waiting on the asm file will not comply in swordfish all over again. This brings back memories.

I like the remote idea then you just need the one box in the middle and a set of remotes each there own id and use pov to display so all can see.
 
Oh, nice addition Bert! A rotating POV display in the middle of the table. What could possibly go wrong?
 
I have to agree with JonSea
but new issue has come up.
getting letters instead of numbers (A, B, C, D) when using the usart.
letters only after I go past button 9. 1 to 9 work as planed
I have a hunch it is converting the hex ?
USART.Write ("Key pressed = ", HexToStr(Keypressed), 13, 10)
trired several different ideas as well as the help file??
 
getting letters instead of numbers (A, B, C, D) when using the usart.
letters only after I go past button 9. 1 to 9 work as planed
I have a hunch it is converting the hex ?

Hex 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E.F... base 16..
 
HexToStr gives a hexidecimal number. As Ian explained, 0 - F, followed by 10 (note: one zero is not ten, it is 1×16 + 0×1).

BinToStr gives a binary number, something like %01001011.

What do you suppose DecToStr gives you?

I am certain HexToStr is in the help file. This shouldn't be difficult.

(SMH This is so ridiculous I couldn't stop from answering.)
 
Last edited:

Speaking of not thinking a project completely through....

If you remember back, in my demo program I had dimensioned KeyPressed and KeyValue. The reason I had KeyValue was that the values returned from the keypad module are 1 through 16 but a zero key is needed in dominos. Actually, you need a double zero key. An entirely blank domino is the ultimate wild card, and severly counts against you if you are holding it at the end of the game. So a returned value of 1 equates to "double zero". A returned value of 2 equates to 1 and so on. At the time I wrote my code, I recognized the need to map the keys, but I didn't carry out the thought process further than recognizing the need.


1 pressed = 0
2 pressed = 1
3 pressed = 2
• • •
13 pressed = 12
14 pressed = 13
15 pressed = 14
16 pressed = 15
?? pressed = 16

You don't have 16 values. You have 17 values!

 
Oh God, here we go...

What's double zero in decimal?
If you divide by double zero do you get double infinity?
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…