The quest continues.
The target is to find a way to use PortB-change interrupts to react to a 4x3 keypad hit.
Consider this schematic:
Row A to D are connected to RB4 -7
Culomn 1 to 3 are connected to RB1 -3
(This leaves RB0 free for other use)
Here is an elementary test in Flowcode:
Simulating the program in Flowcode gives no reaction on the interrupt at all.
When I run the code in Proteus and in hardware, keys 3,6,9 and # are reacting and return the correct keynumber, the other keys don't react.
After a hardware reset, no key is reacting anymore.
After a switch off/on, keys 3,6,9 and # are reacting again.
One of the problems can be that PortB-Change interrupt will react on a change condition of RB4 - 7.
Like the hardware is setup now, without pull-up or pull-down resistors, a change condition cannot be detected.
I experimented with pull-downs on RB4 - 7, but without result.
Did anybody tried this before and found a working solution?
Best regards,
Eric
PortB-Change interrupt (part 3) and keypad
Moderator: Benj
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: PortB-Change interrupt (part 3) and keypad
Hello Eric
To read a multiplexed keypad you must run a routine that toggles the outputs connected to the rows while sampling the columns for a pressed switch. Or you can do this visa versa with the columns being output and the rows sampled. Either way this is not going to work with a port change interrupt. The easiest way to do this would be to use a timer interrupt to poll the keypad at regular intervals. You can even use this method to build up a keypress buffer for use later in your main program.
To read a multiplexed keypad you must run a routine that toggles the outputs connected to the rows while sampling the columns for a pressed switch. Or you can do this visa versa with the columns being output and the rows sampled. Either way this is not going to work with a port change interrupt. The easiest way to do this would be to use a timer interrupt to poll the keypad at regular intervals. You can even use this method to build up a keypress buffer for use later in your main program.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
-
medelec35
- Matrix Staff
- Posts: 9521
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
Re: PortB-Change interrupt (part 3) and keypad
I may be totally wrong, so If I am - sorry in advance.
What if you had RB4 - Rb7 with weak pull ups and set for interrupt on change. Have RB1 - RB3 as outputs = 0V
Then If you press a key, one of RB4 - RB7 lines will change to low so that will be 1st thing stored i.e get value invert by xor and masking lower bits. Then you could have a routine which changes RB4- RB7 as outputs, then RB1-RB3 to i/p's with weak pull-ups. Then read RB-1 RB3 which the button pressed with be the one which is low. Again value invert by xor and masking upper bits this time. add both results together then/2 to give lower number, then use a look up table to get required ASCII.
e.g If 6 is pressed then change will be detected since RB6 is pulled low. Then if pins are swapped as above then only RB3 of new i/p's will be low.
Don't know how easy this would be to implement using flowcode , but worth a try?
What if you had RB4 - Rb7 with weak pull ups and set for interrupt on change. Have RB1 - RB3 as outputs = 0V
Then If you press a key, one of RB4 - RB7 lines will change to low so that will be 1st thing stored i.e get value invert by xor and masking lower bits. Then you could have a routine which changes RB4- RB7 as outputs, then RB1-RB3 to i/p's with weak pull-ups. Then read RB-1 RB3 which the button pressed with be the one which is low. Again value invert by xor and masking upper bits this time. add both results together then/2 to give lower number, then use a look up table to get required ASCII.
e.g If 6 is pressed then change will be detected since RB6 is pulled low. Then if pins are swapped as above then only RB3 of new i/p's will be low.
Don't know how easy this would be to implement using flowcode , but worth a try?
Martin
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: PortB-Change interrupt (part 3) and keypad
Hello Medelec
Thinking more about it I think you are right, you could try and detect a drop in voltage from a key press and then perform the scan to see which key was actually pressed. I think I got caught up in the key scan rather then the triggering of the key scan.
Thinking more about it I think you are right, you could try and detect a drop in voltage from a key press and then perform the scan to see which key was actually pressed. I think I got caught up in the key scan rather then the triggering of the key scan.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
-
medelec35
- Matrix Staff
- Posts: 9521
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
Re: PortB-Change interrupt (part 3) and keypad
This is my 1st attempt of creating routine for key detection method. I have probably been a bit more complex than it needs to be. I have created a routing so the key detected is low all the rest are high. So routing inverts and masks and adds up so value derived is as though only key pressed is high in value. Then result is divided in two, so look up table can be halved. Finally a ASCII is found from the look-up table.
There is some problem between code produced by Flowcode and whether it will work on Proteus when interrupts are involved. I’m not sure which one is at fault could be either.
Only way to find out how near or far this is to a solution is to run on real hardware. Perhaps in ICD mode.
Or some one like Ben or Steve to spot and correct all my mistakes.
When I get a bit more time I will annotate Flowcode flowchart more to make it easier to follow.
There is some problem between code produced by Flowcode and whether it will work on Proteus when interrupts are involved. I’m not sure which one is at fault could be either.
Only way to find out how near or far this is to a solution is to run on real hardware. Perhaps in ICD mode.
Or some one like Ben or Steve to spot and correct all my mistakes.
When I get a bit more time I will annotate Flowcode flowchart more to make it easier to follow.
- Attachments
-
- Keypad1_p_int.fcf
- (16.5 KiB) Downloaded 309 times
Martin