I am using vscode with the Particle Workbench to create my code for a Baron.
i tried to use customer keypad without I2C on baron but looks like keypad.h as arduino library from VScode is not compatible with particles device, and i tried to rum my code on https://build.particle.io/build it’s verified perfectly but on Vscode as local compile it not passing compile.
Having used Arduino a lot, I have got used to downloading manually keypad.h Library from gitHub, i tried too and install manually on vsCode but nothing changed still have error. .
Is there a way to use keypay matrix4*4 on Particle boron…
Cheers
code am using
SYSTEM_MODE(SEMI_AUTOMATIC);
#include "Keypad.h"
const byte Rows= 4; //number of rows on the keypad i.e. 4
const byte Cols= 4; //number of columns on the keypad i,e, 3
//we will definne the key map as on the key pad:
char keymap[Rows][Cols]={
{'1','2','3','A'},
{'4','5','6','B'},
{'7','8','9','C'},
{'*','0','#','D'}
};
// a char array is defined as it can be seen on the above
//keypad connections to the arduino terminals is given as:
byte rPins[Rows]= {A0, A1, A2, A3}; //Rows 0 to 3
byte cPins[Cols]= {A4, A5, A7, 6}; //Columns 0 to 2
// command for library forkeypad
//initializes an instance of the Keypad class
Keypad kpd= Keypad(makeKeymap(keymap), rPins, cPins, Rows, Cols);
void setup()
{
Serial.begin(9600); // initializing serail monitor
}
//If key is pressed, this key is stored in 'keypressed' variable
//If key is not equal to 'NO_KEY', then this key is printed out
void loop()
{
char keypressed = kpd.getKey();
if (keypressed != NO_KEY)
{
Serial.println(keypressed);
}
}
@ScruffR thank for your help but do mind to let me know why My serial monitor not responding when I press any key on Keypad (nothing comes on serial monitor when i press the key)
while:
there is not syntax error in the code
code well uploaded to baron V0.9.0 through USB from VScode workbench
RGB LED is cyan after uploading to the device
and the same code are running perfectly in Arduino IDE
Probably because if (key) never becomes true but other reasons my be at play.
To exclude these you should add an else case where you - from time to time - print another message.
e.g. like this
void loop()
{
static uinte32_t ms = 0;
char key = keypad.getKey();
if (key)
Serial.println(key);
else if (millis() - ms > 1000) { // every second of not getting anything print a dot
Serial.print('.');
ms = millis();
}
}
When you get the dots printed it’s not the serial monitor but actually key never being true, which would suggest some issue with the wiring and/or the library.
To know which of that you may want to investigate how the library detects a button press, mimik that even with jumper wires and see what’s going on.
I have no such keypad to directly test, but debugging is a skill that requires some flexibility of mind to imagine what could go wrong, develop a test case, check the result, interpret, repeat, till you find the cause and the cure.
@ScruffR Dots are printed but key are still not working and for checking jumper wires I connected the same jumpers to Arduino UNO and it works even pressed key.
for now am 100% with you that serial monitor is Ok, and jumpers are fine maybe the problem is inside of library.
But even with your pin mappings I get the expected results.
So it’s not the library.
One possibiliy would be that some pins on your Boron got fried if you ever had the wiring wrong.
To test that connect a jumper wire from one of the rPins to D7 (testing each one of them).
The D7 LED should come on with medium brightness.
When all of these are fine, do the same with the cPins.
The D7 LED should come on slightly dimmer.
the problem was to use board pin name instead using baron datasheet Pin name,
because before i have been using: byte rowPins[ROWS] = {A0, A1, A2, A3}; byte colPins[COLS] = {A4, A5, D5, D6};
but now am using byte rowPins[ROWS] = {D18, D17, D16, D15}; byte colPins[COLS] = {D14, D13, D12, D11};
which looks different at same point but are the same the only difference is how their named, much better to use this refence Baron pin naming
If that didn't work but the other way does (without rewiring) I'm properly confused as exactly these pin assignments did work for me.
There must be some other explanation - especially since the pin names are nothing else than #define macros that evaluate to exactly the same number as their alternative macros for the same pin.
But what I see there is a misalignment between originally A0..A4 and now working D18..D15
Similarly D12 & D11 are not the same pins as D5 & D6 but rather MOSI & MISO.
So you must also have rewired the setup.
