|
|
View previous topic :: View next topic |
Author |
Message |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
Preps for First LCD and Keypad Project |
Posted: Mon Aug 29, 2005 9:57 pm |
|
|
Hello All,
From my recent posts you may have guessed I'm getting ready to venture into some new territory.
PIC18LF4620
16x4 LCD (Solved all the 3v issues with that)
3x5 Keypad (3 wide x 5 tall, bottom 12 standard layout, top row are soft keys below LCD)
Did some really interesting reading through the forums but still had some questions regarding layout of the board and how it will affect my code.
Key pad will be on Port B for interrupts. I like the idea of being able to detect simultaneous key presses. I didn't quite understand how to accomplish that feature as noted here:
http://www.ccsinfo.com/forum/viewtopic.php?t=19726
Also didn't understand the concept that pull-ups should be placed on the colums verses the rows (or vice versa.) I haven't found a good explanation for the design of keypad matrix and kbd.c has a bunch of new C concepts that I haven't had to use before. So I haven't been able to dissect it to understand how pad is strobed for input. (Any suggestions on reading material....for the keypad concepts that is.)
Tentative layout:
RB0 C1
RB1 C2
RB2 C3
RB3 R1
RB4 R2
RB5 R3 & ICSP
RB6 R4 & ICSP
RB7 R5 & ICSP
Still trying to figure out how to isolate the keypad from the ICSP....
LCD seems rather simple. I don't plan on multiple ports or anything complicated like that.
RD0 RS
RD1 RW
RD2 E
RD3 D4
RD4 D5
RD5 D6
RD6 D7
RC2 Vo (PWM negative voltage generator for contrast control)
So, I once again ask for the wise for any help they might have or any comments on my seemingly straight-forward approach. (I think my biggest problem at this point is the ICSP/Keypad isolation.)
Thanks Again,
John |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Mon Aug 29, 2005 10:17 pm |
|
|
The keypad pullups are required for the lines that are inputs - doesn't matter if they're arranged to be on the columns or rows, as the end result is the same.
Have a look at a schematic of a typical keypad. The one I like to reference is MELabs' Lab-X1. Preferably print it so that you can have a paper copy to mess up.
Lines B4-B7 are set to inputs, with the internal port b pullups enabled. Therefore they idle high. The other lines, B0-B3, are set to outputs, and are set to normally output a low, 0.
Now imagine one of the buttons being pressed. That "shorts" a low (from B0-B3, depending on the button) to one of the inputs (B4-B7, again depending on the button.) What was high (B4-B7) now becomes low, triggering the port b interrupt on change. There, you've detected a button press. Now the hard(er) part: which one?
With the 4x4 button layout of the lab-x1 board, any one of 4 buttons could have caused one interrupt. The way to check for which button is to raise each of the low (0) outputs (B0-B3) to a high (1), in turn, and check to see if the input line (B4-B7) is still low. If it is, then that button wasn't pressed. If it is no longer low, then that button is the one that was pressed.
You don't have to rearrange things for your 15 button layout. What I'm getting at is that you don't have to change the code to go with 5 input lines and 3 output, or 5 out and 3 in. You can still use the 4x4 matrix as laid out in the code, only you'll only be implementing 15 buttons, not 16.
And you don't have to worry about the ICSP connections to B6 & B7. Just as long as no other logic is connected to them, they can also be connected to a keypad with no issues. Just don't press any keypad buttons while you're programming it. |
|
|
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Mon Aug 29, 2005 11:17 pm |
|
|
Fantastic!
That really helped. I will spend some time with your post and the code so that I will understand whats happening.
I had looked at the MeLabs schematics (other posts had led me there.)
The 4x4 implementation hit me as I was reading your explanation. Duh, most efficient use is 4x4 with one unused key, who cares how they're arranged physically.
Also, the ICSP issues (or lack thereof) were immediately clear when I printed the MeLabs Schematic. Duh x2.
Only one small question. The Melabs Schematic depicts a lonely 100K resistor RB3 connection.....Por Que?
I sincerely appreciate your effort and time to explain these concepts.
John |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Mon Aug 29, 2005 11:47 pm |
|
|
I know the resistor you're talking about. It's stuck on B3 because that's the low voltage programming (LVP) pin. I can't remember off the top of my head if that 100k resistor ties that line high or low.
It's in there just for safety - so the pic doesn't accidentally enter LVP mode, or if it's in that mode, that no inadvertent programming happens. At least I think that's what its in there for. I think that the default state for the LVP fuse is to be on, so I guess it's possible for the chip to accidentally get into that mode between the time it's soldered down and when you program it.
To be honest, I never include that resistor in my designs, and it's never been an issue.
If I'm wrong, someone please correct me. |
|
|
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Fri Sep 16, 2005 10:56 pm |
|
|
OK.
Boards arrive Monday and I'm deciphering code for my first project using a keypad.
Newguy was a great help but now that I've reviewed his code I've got a couple questions.
1. Why use both:
Code: | output_b(0xF0);
set_tris_b(0xF0); |
Don't they do the same thing?
2. Newguy relies on an int16 to store keypresses and uses a lot of bit operations to track the keypresses. I assume that is so that multiple keypresses can be tracked simultaneously? Or are bit operations more efficient (faster) than just logging the key press in some variable?
Thnaks to all,
John |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Fri Sep 16, 2005 11:38 pm |
|
|
jecottrell wrote: | OK.
Boards arrive Monday and I'm deciphering code for my first project using a keypad.
Newguy was a great help but now that I've reviewed his code I've got a couple questions.
1. Why use both:
Code: | output_b(0xF0);
set_tris_b(0xF0); |
Don't they do the same thing?
2. Newguy relies on an int16 to store keypresses and uses a lot of bit operations to track the keypresses. I assume that is so that multiple keypresses can be tracked simultaneously? Or are bit operations more efficient (faster) than just logging the key press in some variable?
Thnaks to all,
John |
output_b() does just that - outputs some bit pattern to port b. set_tris_b() sets the direction register for port b. Since I set #use fast_io(b) earlier in the code, the compiler won't automatically set the direction register for you if you change from reading port b to setting it and vice-versa. That's why you need to independently set the direction and values for port b.
You're right - the only reason I use an int16 is to keep track of 16 separate buttons simultaneously. It seemed like the only logical way to do so, unless someone can show me a better way. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|