Handling Arduino pin references

[Bodmer]

In the Arduino environement it is expected that pin manipulation functions such as digitalWrite() accept the Arduino pin reference which is abstracted from the real GPIO number. This library instead uses GPIO number directly, this leads to compatibility problems. For example on an RP2040 Nano Connect digitalWrite(13, HIGH) changes GPIO 6 due to the mapping:

I can see that the conversion from the Arduino pin number to the GPIO number in this package is currently handled by a #define Dxx pin references. So in the above case digitalWrite(D13, HIGH) would work fine and drive GPIO 6.

I understand why this package has evolved in this way and a change now may be too much to ask...

[earlephilhower]

Actually, the core uses Arduino naming just fine. When you use the Arduino pin names (D0...D30, A0...A7) those names refer to static const ints with the proper GPIO pin. We have a unique mapping file for each board variant, in fact.

So, the proper call for your example would be digitalWrite(D13, HIGH) which would set pin GP13 on the original RPi Pico board, or GP6 on the Arduino Nano Connect.

[Bodmer]

Yes, I understand. However the Arduino API for digitalWrite expects an Arduino pin reference to be passed to it, then conversion to a physical GPIO is done within that function. Thus the API is not compatible with sketches that use raw numbers for the Arduino pin references. I can understand the reluctance to change the API.

[Bodmer]

The problem is compounded becuase the Arduino Mbed support package also does not currently provide visibility to Dxx pin references. To use GPIO numbers with the Mbed package it is however possible to use digitalWrite(p6, HIGH) to control GPIO6 which in this case is Arduino pin 13.

[earlephilhower]

Don't know what to tell you, unfortunately. I'm just implementing it the way I've seen many other boards do it. I can't believe they're telling people to use raw numbers...the pinout diagram you posted, for example, even labels the pins as D0...Dn! If you only ever have a single board variant per core, which I guess is true for Arduino.cc proper, I guess it's fine. But it makes things 100% unportable to other boards of the same core but different PCBs...

If you'd like to try and work out a way of inverting things (D0=0 always, for example,...but what number would A0 be???) I'm open to looking at a PR.

[Bodmer]

The API reference here uses raw "Arduino" pin numbers which are mapped to physical pins within the function. Unfortunately I see no simple solution to the API implementation differences.

I can see why the Arduino team did this, for example all "Nano" boards have a D13 (Arduino pin 13) irrespective of the processor and GPIO mapping on the board.

I am not asking for any changes to be made to this package. I just have to make allowance for the API differences in my libraries.

[earlephilhower]

Wow, so they do. Nobody's ever accused Arduino of being a master-planned API, of course. Not a dig on them! Arduino's something that's grown over many, many years and has brought tons of people into embedded systems. But sometimes choices made back in 1999 for an 8-bit, 4MHz AVR processor come back to bite you when you have 100s of variants running 5 orders of magnitude faster.

Maybe the sanest thing would be to get the Dx macros in the MBED version? Unless they are deprecating the pin names everywhere, it might just be something they haven't considered...