I want to use a keypad for a security lock.
When I put in the right code (p.e. 1234), the locker is open, or a green led flashes or something.
I used the code from the keypad library with some changes in the loop. Such as:
#include <Keypad.h>
const byte ROWS = 4; //four rows
const byte COLS = 3; //three columns
char keys[ROWS][COLS] = {
{'1','2','3'},
{'4','5','6'},
{'7','8','9'},
{'#','0','*'}
};
byte rowPins[ROWS] = {5, 4, 3, 2}; //connect to the row pinouts of the keypad
byte colPins[COLS] = {8, 7, 6}; //connect to the column pinouts of the keypad
Keypad keypad = Keypad( makeKeymap(keys), rowPins, colPins, ROWS, COLS );
void setup(){
Serial.begin(9600);
}
void loop(){
int code;
int secureCode = 1234;
char key = keypad.getKey();
if (key != NO_KEY){
code = code * 10 + key - '0';
Serial.println(code);
}
}
...and other code to check the secureCode...
The problem is that everytime when I put a new number, this number comes on a new line.
So the int code won't be filled with 1234, but first 1, then 2. A new input replaces the old value.
How can i solve this?
I was thinking of an array, to put in the codes. When array is complete, check his content en give action or not. But experts from the dutch forum not recommended this.
The variable code is defined in your loop, it needs to be defined globally if you want it to keep its value between calls of loop().
Using the method of having an array may be a better solution, the way you are doing it at the moment will fail if you start the code with a 0, there is no way of differentiating between 0123 and 123 without counting the number of characters etc.
With these comments I can get to work! Thanks all for thinging with me.
@billroy
It didn't.
code must be filled with the entered code from the keypad.
And at last all four digits must be in 'code'. So code == 1234.
Therefor code was first 1, after next input 2, then 3, then 4. But not the whole securecode.
If you are just printing code, make code 5 chars long instead of 4, the reason for this is that the way print works is it steps through your array one character at a time until it reaches a 0 ('\0' not '0'), which denotes the end of a string. While the compiler knows the length of code, when it runs the processor does not know its length, so an extra 0 is needed on the end to tell it that this is the end of the string.
Should you not break out of this when you find the first incorrect match, otherwise you are only comparing the last characters and ignoring the results of the first 3 tests.
UKHeliBob:
Should you not break out of this when you find the first incorrect match, otherwise you are only comparing the last characters and ignoring the results of the first 3 tests.
(code
==secureCode[c]) will return either a 1 or 0, for true or false, correct is initialised to 1, and then ANDed with the result (note the &=) this means once it gets a 0 it will stay at 0, regardless of whether the next result is a 1 or a 0.
You could break out of the loop, that just requires more code and personally I like this way. I'm not sure which would be faster? breaking out will save you looking at the other characters, but each character will require some extra processing, I suppose the most optimum way would be:
[code]
for(c=0; c<4 && correct; c++)
{
correct=(code[c]==secureCode[c]);
}
[/code]
But for 4 characters, it's not going to make an ounce of difference, as long as it works
Thanks Toby. Frankly I didn't even spot the &
Now I know why I always put spaces in my code where it is appropriate ratherthanjammingitalltogether so it becomes a blur.
I think that I prefer the 'test a character and if it doesn't match flag a mis-match and break' approach as it is much more obvious what is going on but, of course, it is not as clever.
UKHeliBob:
Thanks Toby. Frankly I didn't even spot the &
Now I know why I always put spaces in my code where it is appropriate ratherthanjammingitalltogether so it becomes a blur.
I think that I prefer the 'test a character and if it doesn't match flag a mis-match and break' approach as it is much more obvious what is going on but, of course, it is not as clever.
Yeah, I'm definitely guilty of overcomplicating code, just to cut out a couple of lines