Broken Arduino libraries due to implementaion of commonly used GPIO constants

[frinkahedron]

Subject of the issue

I have noticed that some arduino libraries (including those created by sparkfun) fail when using the apollo3 core. In short, the apollo3 core defines common constants used by arduino to specify pin modes (such as INPUT, INPUT_PULLUP, and OUTPUT) as structures instead of a simple data type. The libraries in question make assumptions that these constants will be simple data types and that causes the failures. See https://forum.sparkfun.com/viewtopic.php?f=169&t=51356 for an example.

This is my first real look at Arduino so I don't know if the assumptions being made by those libraries are counter to accepted practices but based on what I have seen so far I would expect there would be more libraries that will run into problems because of this.

In the interest of better compatibility with libraries I am wondering if it makes sense to adjust this in the core. I don't expect library maintainers will redefine thier use of constants to every way a core might define constants differently so it seems to make more sense to change the core (if this argument is valid).

Again I normally work with more low level code so Arduino is new to me so I may not be factoring in some key considerations so please educate me if my conclusions seem flawed.

Proposed Changes

If the suggestions are deemed valid I could post a pull request with more details, I have made changes similar to those described below on my own local copy of the core to work around the issue for myself.

1. Take existing defines for GPIO constants in question (INPUT, OUTPUT, etc) and rename them with a prefix such as "AP3_PINCFG_" and make those updates throughout the code.
2. Add back in defines for GPIO constants in question (INPUT, OUTPUT, etc) but with simple integer values.
3. Create a new version of pinMode that uses the translates the integer based GPIO constants to use the pinMode calls that use the structures.

Last I checked it would affect about 3 files.
It does add a slight level of abstraction that may need to be considered for impact and if it conflicts with your design approach.

Your workbench

Using Linux (Qubes with Fedora 30 Qube instance running Arduino 1.8.5)
Using Artemis boards from sparkfun (Nano, ATP, etc)

Steps to reproduce

Example: Try and use the sparkfun SX1509 ardiuno library (https://github.com/sparkfun/SparkFun_SX1509_Arduino_Library) and run an example such as basic keypad example.

Expected behaviour

Code compiles and uploads to the target board

Actual behaviour

Compile fails with errors such as:
/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

See https://forum.sparkfun.com/viewtopic.php?f=169&t=51356 for an example.

[oclyke]

@frinkahedron Excellent point. The current implementation is/was admittedly experimental - we wanted to stick as close to the underlying SDK as possible.

Thanks to this report I can tell that was obviously ill-advised and we would welcome a PR if you are willing. Otherwise this would be a pretty high priority issue for us to solve here.

Thanks!

Interesting to think about how we missed this error...

• Most likely because the GPIO functions, when used directly, are fine. However when expected to pass pin level into another library it gets "pinched" by the type assumptions of that library. Ahh, if only Arduino had standardized a "pin level type" that could be redefined.

[frinkahedron]

I'll clean up my local changes and submit a PR today for comment