6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:28 pm

All times are UTC




Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Keypad for use with VIA
PostPosted: Wed Aug 19, 2015 12:24 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Something that I've just knocked together to get some basic input going. I'm sure many people have done this here, but thought it might be of interest to those just starting out.

This was made around a keypad that I purchased on ebay. The keypad has the usual rows and columns matrix (4x4 keys consisting of 0-9 and A-F) and to which I've attached an Atmel ATMEGA 328P-PU microcontroller which does the scanning (thus taking the responsibility/work load from the 6502 / VIA).
The 328P pulses each row low and (for each row) then checks the columns to get the row and column combo of the key being pressed. If a key ahd been pressed then does a lookup to determine the equivalent ascii code which is then outputted to the VIA. The VIA IRQ pin is then pulsed low to tell the VIA that a key has been pressed and data is ready.

I've gotten the hardware assembled (looks a bit messy on the soldering as I had to rework some of it) and have mostly completed the 328P firmware (see attached), although I've got to make a few adjustments; namely I need to clear the code up a bit and add in some comments and also possibly add in R3 (a 10K pull up resistor for the IRQ line). R3 shouldn't really be needed as it's actively driven by the 328P so I might not put it in, but we'll see how things go in testing as it's lack might cause the VIA to generate spurious IRQs during the 328P's (admittedly brief) initialisation.

BTW I've included an SPI header so that the 328P can be programmed in-situ.

Here's a couple of pictures and a circuit diagram plus the firmware (I used Atmel Studio 6.2):

[edit] Updated the firmware AVR source code with bug fixes and comments


Attachments:
Keypad.zip [22.67 KiB]
Downloaded 87 times
keypad_underside.jpg
keypad_underside.jpg [ 200.13 KiB | Viewed 1811 times ]
keypad_top.jpg
keypad_top.jpg [ 144.27 KiB | Viewed 1811 times ]
VIA to keypad interface.png
VIA to keypad interface.png [ 91.5 KiB | Viewed 1811 times ]


Last edited by banedon on Wed Aug 19, 2015 8:15 pm, edited 1 time in total.
Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 19, 2015 2:30 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
(I like it... for a while it's bugged me that you can readily get 16-key keypads but a KIM-1 needs 7 more keys than that. And the answer came to me: octal! Eight keys for number entry and eight left over for functions!)


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 19, 2015 2:38 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
BigEd wrote:
(I like it... for a while it's bugged me that you can readily get 16-key keypads but a KIM-1 needs 7 more keys than that. And the answer came to me: octal! Eight keys for number entry and eight left over for functions!)

Then why not go binary and have 14 for other functions! Or have a smaller keypad!

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 19, 2015 5:47 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
I was kind of tickled to see how well these little NEC IR remotes work. Maybe use a simple plastic coated paper overlay for a new key legend.

Connect the IR Receiver IC output to a single pin on the VIA and let the 6502 decode the signals, or perhaps use an 8-pin PIC to decode the signals and send key press data to the 6502 VIA or ACIA.

Attachment:
NEC Remote.png
NEC Remote.png [ 531.85 KiB | Viewed 1790 times ]

Attachment:
NEC (small).png
NEC (small).png [ 143.85 KiB | Viewed 1790 times ]


Attachments:
NEC Term Screen.png
NEC Term Screen.png [ 45.63 KiB | Viewed 1790 times ]
NEC IR Viewer.jpg
NEC IR Viewer.jpg [ 154.07 KiB | Viewed 1790 times ]
NEC Remote.jpg
NEC Remote.jpg [ 58.24 KiB | Viewed 1790 times ]


Last edited by Michael on Thu Aug 20, 2015 6:34 am, edited 1 time in total.
Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 19, 2015 5:57 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
I have one of those remotes on order from China and was wondering what I'd do with it. Now and I know:)


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 19, 2015 8:19 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
I've updated the source code file as I had the rows and columsn mixed up. That's now been corrected. Also included comments.


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 20, 2015 6:55 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
banedon wrote:
I have one of those remotes on order from China and was wondering what I'd do with it. Now and I know:)

The price and the idea of using a single VIA pin for keypad input is appealing, isn't it? It would certainly make for a nice small front panel. Also, I wonder if you couldn't use an 8-pin PIC as a PS/2 Keyboard to IR transmitter? Might be a nice incremental upgrade for a "starter" system.

I've also thought about using something like a 4.3" resistive touch screen overlay for a keypad, but, personally, I prefer tactile feedback from buttons.


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 24, 2015 3:39 pm 
Offline

Joined: Mon Mar 25, 2013 9:26 pm
Posts: 183
Location: Germany
Two years ago I hooked up an C64 keyboard to an Arduino an wrote a little key-scanner to use the keyboard. Using an Arduino Leonardo would cause the whole thing act as an USB keyboard.
Using an 74HC138 I could reduce the number of "line driving pins" to 3. So one via should have enough pins to make a simple 8x8 keyboard work.

Mario.

_________________
How should I know what I think, until I hear what I've said.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 25, 2015 1:27 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Thanks to me being a bit blind and also to Atmel Studio 6.2 masking a source code error, I've spotted a few issues and corrected them.

Here's the new source code and circuit diagram.
Attachment:
kybd2.jpg
kybd2.jpg [ 124.03 KiB | Viewed 1643 times ]

Attachment:
GccApplication7.zip [23.31 KiB]
Downloaded 69 times


I've also run into an issue that Michael kindly pointed out to me, although I think it's a slightly different one than initally thought (correct me if I'm wrong, Michael).
When I press two keys on the same row as each other, I get a large pull on the power rail. If press three keys together, I get even more pull.

Here's what happens when keys are pressed and held down on the same row. Note that keys pressed at the same time on different rows do not cause issues:

Resting current use: alternates between 3 and 5mA
1 key pressed: 3mA (does not rise to 5mA)
2 keys pressed together: 37mA (+34mA)
3 keys pressed together: 55mA (+18mA)
4 keys pressed together: 72mA (+17mA)
The above does not differ if different key combinations are used.

The way my keypad circuit works is that it holds all rows HIGH by default
When a row is being scanned, it drops that row LOW.
The Column inputs are then checked to see if a LOW is detected on a column and if so, the row/column number combination is recorded, the ascii value looked up and outputted on the VIA interface pins (along with the VIA IRQ dropping LOW for 10ms).
The column lines are held high using a 10K bus resistor network connected to +5v rail.

I don't understand why there is this power draw? Can anyone see from my diagram if I've mucked something up? If it were completely shorting out then my benchtop PSU would go to the max allowed current and then start dropping the voltage. This doesn't happen.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 25, 2015 5:17 pm 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
it sounds like you should be tri stating the rows which are not scanned? Right now the row that isn't scanned is driving the row that is, via the key switch.

Alternatively to tri stating you can use diodes, eg. how the ULA and key matrix were arranged in the Spectrum. But since you are using a controller I would just tri state.

See: https://github.com/aslak3/keyboardcontr ... ter/main.c

This is the code for my C64 keyboard AVR-based controller. It shows the principle of rotating the DDR, leaving the "unscanned" row in input in tri state.

EDIT: added some details, since I wrote the first post using my phone.

_________________
8 bit fun and games: https://www.aslak.net/


Last edited by Aslak3 on Tue Aug 25, 2015 6:03 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 25, 2015 5:59 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Aslak3 wrote:
it sounds like you should be tri stating the rows which are not scanned? So the row that isn't scanned is driving the row that is, via the key switch.

Altenatively to tri stating you can use diodes, eg. how the ULA and key matrix were arranged in the Spectrum. But since you are using a controller just tri state.


Hi Aslak3

That's pretty much what was recommended by Michael (from this forum) as well. What I'm really after is understanding what is actually happening - are the columns drawing the current from the row pin, for instance? So we have roughly 18mA per column (i.e. per key). This might explain it, although I don't understand quite why this would cause such a large draw for each.. :? .


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 25, 2015 8:35 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
I'm sure you've figured this out by now, but I'll write anyway. This is mentioned in the keypads & keyboards section of the potpourri page of the 6502 primer at http://wilsonminesco.com/6502primer/potpourri.html#KBD . Basically you have contention, where two row outputs get shorted together and one is trying to pull the line up and the other one is trying to pull it down. If they're dedicated to the keypad and you're not using them for other things at the same time, the way to handle it that makes the hardware simplest when you're using a VIA is in software. You write 0's to all those bits in the output register and leave them, then only change the data-direction register to scan the rows. That way, you'll never have one pin trying to pull up a line that another pin is trying to pull down.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 26, 2015 7:59 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
GARTHWILSON wrote:
I'm sure you've figured this out by now, but I'll write anyway. This is mentioned in the keypads & keyboards section of the potpourri page of the 6502 primer at http://wilsonminesco.com/6502primer/potpourri.html#KBD . Basically you have contention, where two row outputs get shorted together and one is trying to pull the line up and the other one is trying to pull it down. If they're dedicated to the keypad and you're not using them for other things at the same time, the way to handle it that makes the hardware simplest when you're using a VIA is in software. You write 0's to all those bits in the output register and leave them, then only change the data-direction register to scan the rows. That way, you'll never have one pin trying to pull up a line that another pin is trying to pull down.

Yes indeed, although I'm not getting these on different rows being shorted together - just different columns for the same row. So if I press 0,1,2,3 (on the same row) then I get the issue. If I press 0,6,A,F (diagonally down and to the right) together then I don't. So I'm not sure that this is contention? Only because it seems to involve one output and mulitple input pins....

The following might make it clearer (forgive the crudity of my MS Paint skills). This show what is happening when keys 0,1,2,3 are all held down together and that row then being scanned:
Attachment:
keypd3.png
keypd3.png [ 173.84 KiB | Viewed 1583 times ]


The Rows are AVR outputs and the Col(umns) are AVR inputs. If I held down, say, buttons 0 and R and then got an issue, then I would also think contention, but I don't I only get an issue with a combination of buttons 0,1,2,3 - i.e. ones on the same row. Same row, same output pin.
(the red arrows should point the other way as the columns are srawn to 0V by the row, but you get what I mean)

[edit]

I've added in 1N4148 diodes into the rows, but although a good idea to prevent contention, doesn't make any difference to this issue. Here's an updated circuit diagram:
Attachment:
kybd_small.png
kybd_small.png [ 52.25 KiB | Viewed 1580 times ]


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 26, 2015 1:49 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
Hi Mike,

I mentioned in the PM that your description of rows and columns and how they're being used wasn't consistent in your schematic and code. The AVR code suggests your keypad matrix is wired like this;
Attachment:
Mike's Keypad.png
Mike's Keypad.png [ 18.22 KiB | Viewed 1572 times ]

The AVR code shows you're driving the column pins (RD0..RD3) as outputs with row pins (RD4..RD7) as inputs which is contrary to your schematic and your description of the scanKbd() function. This also suggests your pull-up resistors are connected to the column lines and you're relying on the AVR internal weak pull-ups for the RD4..RD7 row inputs.

To avoid short circuits from multiple concurrent key presses in the same row while scanning the keypad I suggested either adding four diodes to the circuit or modifying the key scan code to only set one column line at a time to an output (low) during each column scan while leaving the remaining port D pins as inputs with pull-ups. Here's a quick-n'-dirty (untested) example;

Code:
/********************************************
 *  Scan Keypad                             *
 ********************************************/

 char scan(void)                            // scan keypad matrix
 { char matrix = 0;                         //
   for(char col = 1; col < 16; col <<= 1)   // 00000001, 00000010, 00000100, or 00001000
   { DDRD = col;                            // set 'col' bit to output, all others inputs
     PORTD = ~col;                          // set 'col' pin low, pull-up all other pins
     for(char row = 16; row > 0; row <<= 1) // 00010000, 00100000, 01000000, or 10000000
     { if(PIND & row == 0)                  // if key press
         matrix = row + col;                //
     }                                      // next row
   }                                        // next col
   return(matrix);                          // return 0 or pressed key matrix value
 }                                          //


Your new code still has a DDRD assignment operand with only seven bits instead of eight. Bit 7 should be a '0' anyway but it seems sloppy.

Consider using a switch state memory or switch state latch to distinguish between "new press" and "still pressed" switch states each time through the main loop. Use switch state logic to qualify sending "new press" data and strobe to the VIA while ignoring "still pressed", "new release", and "still released" states.

Good luck on your project, Sir. It looks great...

Cheerful regards, Mike


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 26, 2015 4:30 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
I'm ashamed to say that you're right (we need a forum icon for face palm lol). I did originally have them a different way around, left the project for a couple of weeks and obviously completely forgot. Thank you for your persistence in letting me know where I'd gone wrong, Michael.

One thing: I can't seem to use the diodes. The rapid pulsing of the rows isn't translated throught the 1N4848 diodes - I get a very shallow square wave ripple on the other side. Anyone got any suggestions on a different type? If not, I'll try and slow down the scanning to see if that helps (and yes, I have the diodes the correct way round :p).


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: MSN [Bot] and 6 guests


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 post attachments in this forum

Search for:
Jump to: