zephyrCommon: Changing pin numbering rules

[soburi]

Zephyr's ba48d83b
changes make it easy to configure pin numbering at compile,
so we'll change the pin numbers to be based on the GPIO pin numbers.

This is same as the traditional Arduino, using the GPIO numbers as
pin numbers. Pin names written on the board, such as D1 and D2,
are aliases for these pin numbers.

When using multiple GPIO ports, pin numbers are numbered consecutively
from the beginning. For example, if you have two 16-port GPIOs,
16 refers to the first pin (idx=0) of the second port.

[pillo79]

Just chiming in for the Arduino side to say, please don't drop custom pin numbering.

The technical implementation is great 👍 and it removes the need for bulky pin lists 💛, but AFAICS also makes it "impossible" to assign specific numbers to pins, and this is something that is really important for backwards compatibility with traditional Arduino sketches.

[ OTOH, I do hate having to write those lists; tried several alternative DTS mappings myself but haven't yet found one that is flexible enough and/or enough of an improvement... 🙁 ]

[soburi]

Just chiming in for the Arduino side to say, please don't drop custom pin numbering.

The technical implementation is great 👍 and it removes the need for bulky pin lists 💛, but AFAICS also makes it "impossible" to assign specific numbers to pins, and this is something that is really important for backwards compatibility with traditional Arduino sketches.

[ OTOH, I do hate having to write those lists; tried several alternative DTS mappings myself but haven't yet found one that is flexible enough and/or enough of an improvement... 🙁 ]

The main purpose of this change is to make pins that are not exposed on the connector usable.
The pin change itself is necessary to deal with edge cases, so it needs to remain.
My current idea is to use the zephyrproject-rtos/zephyr#87595 change to extract pin information from the gpio-nexus node that is labeled as arduino_header.
With this method, as long as the connector is defined on the devicetree, I think it will be possible to make it behave like an "Arduino" without writing any additional config. For edge cases that still cannot be solved, I think we'll have to deal with them with the current settings, but some consideration may be needed to find the best way to handle them.

---

By the way, zephyrproject-rtos/zephyr#87595 is stalled because only a few people reviewed it.
If you can review this part, please help with this PR review.

[soburi]

@pillo79

The technical implementation is great 👍 and it removes the need for bulky pin lists 💛, but AFAICS also makes it "impossible" to assign specific numbers to pins, and this is something that is really important for backwards compatibility with traditional Arduino sketches.

Does this mean you want to freely map the direct values ​​passed to digitalOut?

I understand that traditionally, Arduino's D1-based values ​​were logical pin numbers,
while values ​​like digitalOut argument were physical pin numbers (i.e., implementation-dependent).

Until now, the gsoc-2022-arduino-core implementation has assumed logical = physical due to various constraints. (i.e., D0 = 0, D1 = 1)

In this implementation, only mapped pins are usable, so the intention of this PR is to introduce physical pin numbers to handle all pins on the board.

If the answer to the initial question is yes, I think this can be addressed by adding one more LUT.

[DhruvaG2000]

I have seen the PR, and have some catching up to do on the new zephyr commit that has been mentioned. I will need some more time to actually go through since this seems to have a large impact overall. Please excuse the delay!

[DhruvaG2000]

Is it me or is the alignment really messed up on this one?

[DhruvaG2000]

@Ayush1325 if possible can you test for any regressions on the Beagleconnect freedom?
I am ok with the general idea here, and it does seem like an improvement for handling gpio ports.
Just need to be careful about the code though, and hence giving some comments from maintenance and debugging perspective.

[DhruvaG2000]

I'll merge this as soon as I am done fixing the CI failures. Please excuse the delay