Matrix keypad library (Keypad.h) not compiling for Artemis ATP

Hello all,

I just started to explore the Artemis ATP board, and got stuck in a problem. I tried to dig the forum for a solution without success.

When I try to compile the “HelloKeypad” example from the arduino Keypad library (Alexander Brevig, version 3.1.1, https://playground.arduino.cc/Code/Keypad/) I got the following error:

In file included from /tmp/arduino_modified_sketch_605904/HelloKeypad.ino:10:

/home/ernesto/Arduino/libraries/Keypad/src/Keypad.h: In member function ‘virtual void Keypad::pin_mode(byte, byte)’:

/home/ernesto/Arduino/libraries/Keypad/src/Keypad.h:80:70: error: no matching function for call to ‘pinMode(byte&, byte&)’

virtual void pin_mode(byte pinNum, byte mode) { pinMode(pinNum, mode); }

^

In file included from /home/ernesto/.arduino15/packages/SparkFun/hardware/apollo3/1.0.17/cores/arduino/ard_sup/Arduino.h:77,

from /tmp/arduino_build_310926/sketch/HelloKeypad.ino.cpp:1:

/home/ernesto/.arduino15/packages/SparkFun/hardware/apollo3/1.0.17/cores/arduino/ard_sup/ap3_gpio.h:62:6: note: candidate: ‘void pinMode(uint8_t, am_hal_gpio_pincfg_t)’

void pinMode(uint8_t pin, am_hal_gpio_pincfg_t mode);

^~~~~~~

/home/ernesto/.arduino15/packages/SparkFun/hardware/apollo3/1.0.17/cores/arduino/ard_sup/ap3_gpio.h:62:6: note: no known conversion for argument 2 from ‘byte’ {aka ‘unsigned char’} to ‘am_hal_gpio_pincfg_t’

/home/ernesto/.arduino15/packages/SparkFun/hardware/apollo3/1.0.17/cores/arduino/ard_sup/ap3_gpio.h:63:6: note: candidate: ‘void pinMode(uint8_t, am_hal_gpio_pincfg_t, ap3_err_t*)’

void pinMode(uint8_t pin, am_hal_gpio_pincfg_t mode, ap3_err_t *retval);

exit status 1

Error compiling for board SparkFun RedBoard Artemis ATP.

The code compiles without problems in an Arduino Mega board. I tried assign different pins in the code without success. If I try to scan the keypad without using the arduino library (example: http://anilarduino.blogspot.com/2015/05 … duino.html) it works without problems. I suppose the way that the library assign the pin modes is not translating correctly from arduino to artemis, but looking at the library code I could not figure out why.

System details:

OS: ArchLinux

IDE: Arduino v. 1.8.10

Board Module: SparkfunApollo3 v 1.0.17

Appreciate any suggestions.

Ernesto

Hi Ernesto.

Unfortunately SparkFun didn’t write the Matrix Keypad Library and we’re not able to assist. You might see if the author can help make the changes needed for the library to work with the Artemis.

I have not debugged the issue myself yet but I have seen this same kind of error message with Artemis ATP when using a sparkfun library.

Thought this might help validate that it could be a valid issue worth looking at, looks likely to be that same or related issue at first glance. When I get time to look at this I’ll try and solve myself but in the mean time thought it might help.

When using the SX1509 library and trying the “SparkFun SX1509 I/O Expander Example: keypad matrix” example I get:

Arduino: 1.8.5 (Linux), Board: “SparkFun RedBoard Artemis ATP, 115200, SparkFun Variable Loader (Recommended)”

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp: In member function ‘void SX1509::reset(bool)’:

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:95:27: error: no matching function for call to ‘SX1509::pinMode(byte&, const am_hal_gpio_pincfg_t&)’

pinMode(pinReset, OUTPUT); // set reset pin as output

^

In file included from /home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:27:

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.h:120:7: note: candidate: ‘void SX1509::pinMode(byte, byte)’

void pinMode(byte pin, byte inOut);

^~~~~~~

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.h:120:7: note: no known conversion for argument 2 from ‘const am_hal_gpio_pincfg_t’ to ‘byte’ {aka ‘unsigned char’}

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp: In member function ‘void SX1509::pinDir(byte, byte)’:

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:114:13: error: no match for ‘operator==’ (operand types are ‘byte’ {aka ‘unsigned char’} and ‘const am_hal_gpio_pincfg_t’)

if ((inOut == OUTPUT) || (inOut == ANALOG_OUTPUT))

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:128:12: error: no match for ‘operator==’ (operand types are ‘byte’ {aka ‘unsigned char’} and ‘const am_hal_gpio_pincfg_t’)

if (inOut == INPUT_PULLUP)

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp: In member function ‘void SX1509::sync()’:

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:461:26: error: no matching function for call to ‘SX1509::pinMode(byte&, const am_hal_gpio_pincfg_t&)’

pinMode(pinReset, OUTPUT); // set reset pin as output

^

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:137:6: note: candidate: ‘void SX1509::pinMode(byte, byte)’

void SX1509::pinMode(byte pin, byte inOut)

^~~~~~

/home/user/Arduino/libraries/SparkFun_SX1509_Arduino_Library-master/src/SparkFunSX1509.cpp:137:6: note: no known conversion for argument 2 from ‘const am_hal_gpio_pincfg_t’ to ‘byte’ {aka ‘unsigned char’}

exit status 1

Error compiling for board SparkFun RedBoard Artemis ATP.

This report would have more information with

“Show verbose output during compilation”

option enabled in File → Preferences.

I took a closer look today and I think they are slightly different issues but a similar root cause.

Disclaimer: This is the first time I am using arduino so I am not familiar with its specifics or potential conventions for how you override the core.

  1. The root cause of both sets of issues appears to be the sparkfun apollo3 core for arduino overrides common constants used by arduino to specify pin modes (such as INPUT, INPUT_PULLUP, and OUTPUT). Instead of being just values they are now structures. As stated above I am not experience with arduino enough to know what is accepted practice but it seems like there are going to be many libraries out there potentially broken by this change since I see folks assuming those constants are simple values in several libraries (including sparkfun ones). At first glance it seems like it would be better to add a level abstraction in the apollo core so that you maintain simple values for these constants. I assume there was a trade off made at some point to reduce complexity elsewhere. That said I doubt your going to find many library maintainers that are going to make a one off change for the apollo library’s change of common constant values (but I don’t know enough about arduino to know if folks are not supposed to assume things about those constants so I could be wrong).

  2. ernestocurty, I think the issue your running into is that the keypad library wrapped the pinMode function in another function pin_mode (keypad.h, line 87 in the version I am looking at, 3.1). Since the wrapper assumes that those standard constants are normal values it breaks things. If you wanted to try and fix yourself without modifying the apollo3 core you could try just adding a second instance of the pin_mode function that has the signature:

virtual void pin_mode(byte pinNum, am_hal_gpio_pincfg_t mode) { pinMode(pinNum, mode); }

I have not looked elsewhere in that library to see what else may be broken but at first glance that may be enough to work around your particular issue.

  1. In case anyone else is trying to use the sparkfun SX1509 library there are two types of issues that I can see. The first is what I described in #1, if that was changed it would fix this too, there are comparison operations being done that would have to be refactored in the library if not fixed in the apollo3 core. The second is that there are calls to pinmode in reset and sync functions that are getting confused with the class member functions. In fact if I understand things properly these may never have worked properly. The intent appears to call the arduino pinmode function to set parameters of the physical pin. However its actually calling the pinmode member function of the class which uses the same name but has a different purpose. It appears that prepending :: to indicate the global namespace would be enough to fix this. You only see the problem now because of the issues with the constants, and maybe when the issues were not there its smart enough to pick up the correct function (have not tested that).

I would be interested to be better educated by others or sparkfun folks on what is accepted practice of these constants in question and/or why they were overridden versus a level of abstraction.

Thanks,

Hi frinkahedron! Thank you for your comprehensive response. I manage to understand that the origin of the problem was the use of the virtual function, but I was stuck there due to my shallow knowledge of C++. Your response made me understand why the virtual function caused the problem (and pointed out the solution). I’ll certainly test your suggestions when I got some time.

Also, in the meantime I tested other library options, and found 2 that work with the Artemis/Apollo3 core. I’ll post the links here just in case someone else runs into the same problem.

ZulNs’ MultiTapKeypad (https://github.com/ZulNs/MultitapKeypad)

very complete library, allows you to input numbers or text (multi tap) as an old cellphone, define modifier keys, recognize key hold etc. The ‘con’ is that the library basically is the loop, and call the rest of user code as an ‘attached function’. I found difficult to integrate it with a hierarchical menu system and some real time updates of variables on LCD screen. Again, this can be only a reflection of my coding skills limitation.

Nickgammon’s Keypad_Matrix (https://github.com/nickgammon/Keypad_Matrix). Monito rkey down/key up and n-key rollover. Non blocking and easy to use. Also has a great tutorial explaining how it works. Not as feature-rich as the previous one, but very easy to use and if you only need to control menus and input numbers works perfectly. Is the library I choose for my project using now.

Again, thank you for sharing your knowledge.

Best,

Ernesto.