Sorry I am late to the discussion been busy with some other things non computer related.

To be honest I would rather see the pin definitions in one place for a variety of reasons. Some of which are think you will be asking for trouble when trying to get all the libraries and documentation updated, not just the ones Arduino maintains. There are a myriad of third party libraries libraries that support the Arduino ecosystem. You want to keep it as easy and simple as can be.

If you remove the commented lines from@KurtE's pin in the previous post its not much longer:

            <&gpioa 0 GPIO_ACTIVE_LOW>,   <&gpioa 11 GPIO_ACTIVE_LOW>,  <&gpioa 12 GPIO_ACTIVE_LOW>,  <&gpioa 13 GPIO_ACTIVE_LOW>,  <&gpioa 14 GPIO_ACTIVE_LOW>,  <&gpiob 2 GPIO_ACTIVE_LOW>,  <&gpiob 3 GPIO_ACTIVE_LOW>,  <&gpiob 4 GPIO_ACTIVE_LOW>,  <&gpiob 6 GPIO_ACTIVE_LOW>,  <&gpiob 7 GPIO_ACTIVE_LOW>,  <&gpiob 8 GPIO_ACTIVE_LOW>,  <&gpiob 9 GPIO_ACTIVE_LOW>,  <&gpiob 14 GPIO_ACTIVE_LOW>,  <&gpiob 15 GPIO_ACTIVE_LOW>,  <&gpioc 13 GPIO_ACTIVE_LOW>,  <&gpioc 15 GPIO_ACTIVE_LOW>,  <&gpiod 3 GPIO_ACTIVE_LOW>,  <&gpiod 4 GPIO_ACTIVE_LOW>,  <&gpiod 5 GPIO_ACTIVE_LOW>,  <&gpiod 6 GPIO_ACTIVE_LOW>,  <&gpiod 7 GPIO_ACTIVE_LOW>,  <&gpioe 2 GPIO_ACTIVE_LOW>,  <&gpioe 3 GPIO_ACTIVE_LOW>,   <&gpiog 3 GPIO_ACTIVE_LOW>,  <&gpiog 9 GPIO_ACTIVE_LOW>,  <&gpiog 10 GPIO_ACTIVE_LOW>,   <&gpiog 14 GPIO_ACTIVE_LOW>,  <&gpioh 6 GPIO_ACTIVE_LOW>,   <&gpioh 9 GPIO_ACTIVE_LOW>,  <&gpioh 10 GPIO_ACTIVE_LOW>,  <&gpioh 11 GPIO_ACTIVE_LOW>,  <&gpioh 12 GPIO_ACTIVE_LOW>,  <&gpioh 13 GPIO_ACTIVE_LOW>,  <&gpioh 14 GPIO_ACTIVE_LOW>,   <&gpioi 2 GPIO_ACTIVE_LOW>,  <&gpioi 3 GPIO_ACTIVE_LOW>,  <&gpioi 4 GPIO_ACTIVE_LOW>,  <&gpioi 5 GPIO_ACTIVE_LOW>,  <&gpioi 6 GPIO_ACTIVE_LOW>,  <&gpioi 7 GPIO_ACTIVE_LOW>,  <&gpioi 8 GPIO_ACTIVE_LOW>,  <&gpioi 9 GPIO_ACTIVE_LOW>,  <&gpioi 10 GPIO_ACTIVE_LOW>,  <&gpioi 13 GPIO_ACTIVE_LOW>,  <&gpioi 14 GPIO_ACTIVE_LOW>,  <&gpioi 15 GPIO_ACTIVE_LOW>,  <&gpioj 6 GPIO_ACTIVE_LOW>,  <&gpioj 7 GPIO_ACTIVE_LOW>,  <&gpioj 8 GPIO_ACTIVE_LOW>,  <&gpioj 9 GPIO_ACTIVE_LOW>,  <&gpioj 10 GPIO_ACTIVE_LOW>;

and if I remember right we commented out the led pins because where was a conflict so they would not work unless you fixed that.

@mjs513@pillo79@facchinm and all:

I have been playing around some with this over the weekend. I have create a new branch:
https://github.com/KurtE/ArduinoCore-zephyr/tree/portenta_pin_names
which is based off of the current Arduino branch.

This branch has three changed files:
variant.h which includes the PinNames.h
PinNames.h, which instead of creating its own type and then created overloaded functions for things like: pinMode,
it simply an enum with the names, which maps directly to the pin number.

And the overlay file changes, where the only changes to the device tree, were to add all of the additional pins, that I was able
to use digitalRead/digitalWrite to, on the different carrier boards.

Note: I also added in two bogus entries in place of the two currently commented out pins in the current pin table:
Updated Version:

zephyr,user {digital-pin-gpios = <&gpioh 15 GPIO_ACTIVE_LOW>,/* D0 */    <&gpiok 1 GPIO_ACTIVE_LOW>,/* D1 */    <&gpioj 11 GPIO_ACTIVE_LOW>,/* D2 */    <&gpiog 7 GPIO_ACTIVE_LOW>,/* D3 */    <&gpioc 7 GPIO_ACTIVE_LOW>,/* D4 */    <&gpioc 6 GPIO_ACTIVE_LOW>,/* D5 */    <&gpioa 8 GPIO_ACTIVE_LOW>,/* D6 */    <&gpioi 0 GPIO_ACTIVE_LOW>,/* D7 */    <&gpioc 3 GPIO_ACTIVE_LOW>,/* D8 */    <&gpioi 1 GPIO_ACTIVE_LOW>,/* D9 */    <&gpioc 2 GPIO_ACTIVE_LOW>,/* D10 */    <&gpioh 8 GPIO_ACTIVE_LOW>,/* D11 */    <&gpioh 7 GPIO_ACTIVE_LOW>,/* D12 */    <&gpioa 10 GPIO_ACTIVE_LOW>,/* D13 */    <&gpioa 9 GPIO_ACTIVE_LOW>,/* D14 */    <&gpioz 0 GPIO_ACTIVE_LOW>,/* A0 ADC2_INP0 */    <&gpioz 1 GPIO_ACTIVE_LOW>,/* A1 ADC2_INP1 */    <&gpioz 2 GPIO_ACTIVE_LOW>,/* A2 ADC3_INP0 */    <&gpioz 3 GPIO_ACTIVE_LOW>,/* A3 ADC3_INP1 */    <&gpioz 4 GPIO_ACTIVE_LOW>,/* A4 hack for duplicate PC_2 */    <&gpioz 5 GPIO_ACTIVE_LOW>,/* A5 hack for duplicate PC_3 */    <&gpioz 12 GPIO_ACTIVE_LOW>,/* PC2A4 _ALT0?   ADC1_INP12 */    <&gpioz 13 GPIO_ACTIVE_LOW>,/* PC3 A5 _ALT0?   ADC1_INP13 */    <&gpioa 4 GPIO_ACTIVE_LOW>,/* A6 ADC1_INP18 */    <&gpioa 6 GPIO_ACTIVE_LOW>,/* A7 ADC1_INP7 */<&gpiok 5 GPIO_ACTIVE_LOW>,// LEDR<&gpiok 6 GPIO_ACTIVE_LOW>,// LEDG<&gpiok 7 GPIO_ACTIVE_LOW>,// LEDB  <&gpioa 0 GPIO_ACTIVE_LOW>,  <&gpioa 11 GPIO_ACTIVE_LOW>,  <&gpioa 12 GPIO_ACTIVE_LOW>,  <&gpioa 13 GPIO_ACTIVE_LOW>,  <&gpioa 14 GPIO_ACTIVE_LOW>,  <&gpiob 2 GPIO_ACTIVE_LOW>,  <&gpiob 3 GPIO_ACTIVE_LOW>,  <&gpiob 4 GPIO_ACTIVE_LOW>,  <&gpiob 6 GPIO_ACTIVE_LOW>,  <&gpiob 7 GPIO_ACTIVE_LOW>,  <&gpiob 8 GPIO_ACTIVE_LOW>,  <&gpiob 9 GPIO_ACTIVE_LOW>,  <&gpiob 14 GPIO_ACTIVE_LOW>,  <&gpiob 15 GPIO_ACTIVE_LOW>,  <&gpioc 13 GPIO_ACTIVE_LOW>,  <&gpioc 15 GPIO_ACTIVE_LOW>,  <&gpiod 3 GPIO_ACTIVE_LOW>,  <&gpiod 4 GPIO_ACTIVE_LOW>,  <&gpiod 5 GPIO_ACTIVE_LOW>,  <&gpiod 6 GPIO_ACTIVE_LOW>,  <&gpiod 7 GPIO_ACTIVE_LOW>,  <&gpioe 2 GPIO_ACTIVE_LOW>,  <&gpioe 3 GPIO_ACTIVE_LOW>,  <&gpiog 3 GPIO_ACTIVE_LOW>,  <&gpiog 9 GPIO_ACTIVE_LOW>,  <&gpiog 10 GPIO_ACTIVE_LOW>,  <&gpiog 14 GPIO_ACTIVE_LOW>,  <&gpioh 6 GPIO_ACTIVE_LOW>,  <&gpioh 9 GPIO_ACTIVE_LOW>,  <&gpioh 10 GPIO_ACTIVE_LOW>,  <&gpioh 11 GPIO_ACTIVE_LOW>,  <&gpioh 12 GPIO_ACTIVE_LOW>,  <&gpioh 13 GPIO_ACTIVE_LOW>,  <&gpioh 14 GPIO_ACTIVE_LOW>,  <&gpioi 2 GPIO_ACTIVE_LOW>,  <&gpioi 3 GPIO_ACTIVE_LOW>,  <&gpioi 4 GPIO_ACTIVE_LOW>,  <&gpioi 5 GPIO_ACTIVE_LOW>,  <&gpioi 6 GPIO_ACTIVE_LOW>,  <&gpioi 7 GPIO_ACTIVE_LOW>,  <&gpioi 8 GPIO_ACTIVE_LOW>,  <&gpioi 9 GPIO_ACTIVE_LOW>,  <&gpioi 10 GPIO_ACTIVE_LOW>,  <&gpioi 13 GPIO_ACTIVE_LOW>,  <&gpioi 14 GPIO_ACTIVE_LOW>,  <&gpioi 15 GPIO_ACTIVE_LOW>,  <&gpioj 6 GPIO_ACTIVE_LOW>,  <&gpioj 7 GPIO_ACTIVE_LOW>,  <&gpioj 8 GPIO_ACTIVE_LOW>,  <&gpioj 9 GPIO_ACTIVE_LOW>,  <&gpioj 10 GPIO_ACTIVE_LOW>;

The reason for the two replacement hacked items:

    <&gpioz 12 GPIO_ACTIVE_LOW>,/* PC2A4 _ALT0?   ADC1_INP12 */    <&gpioz 13 GPIO_ACTIVE_LOW>,/* PC3 A5 _ALT0?   ADC1_INP13 */

Simply used your z hack... why:
If you look at the pin out for these pins:

These pins have duplicate in pins D8 and D10, and If you simply put C2/C3 in the GPIO pin table the enumeration code
that generates the Arduino Pin sums the index of all that match: so instead of D8 being 8, it becomes If I remember correctly
8+20 ...

Hello guys, and thanks for being so supportive! 🥇

On this topic the idea I had was to fully exploit the same ZephyrGPIO nexus nodes abstraction used in thearduino-r3-connector: I would basically define each board connector in the schematics with its GPIO pins, and then reference the same pins in thedigital-pin-gpios table via those connector names and numbers. Should be much more descriptive, single-source (you copy connector numbers, not GPIO info), and also flexible (you can directly reference a board connector pin, or in the future support multiple different standards like UNO, Mega etc).

IIRC the core is currently missing some macro magic to allow the number lookups to work properly but it should be definitely possible.

What do you think about this?

Hi@pillo79 -

Sorry I only know enough to be dangerous. 😆

but by GPIO nexus nodes - This is the arduino_header part used in the GIGA pin definitions?

zephyr,user {digital-pin-gpios = <&arduino_header 6 0>,<&arduino_header 7 0>,<&arduino_header 8 0>,<&arduino_header 9 0>,<&arduino_header 10 0>,<&arduino_header 11 0>,<&arduino_header 12 0>,<&arduino_header 13 0>,<&arduino_header 14 0>,<&arduino_header 15 0>,<&arduino_header 16 0>,<&arduino_header 17 0>,<&arduino_header 18 0>,<&arduino_header 19 0>,<&gpiog 14 0>,/* TX1 - 14 */<&gpioc 7 0>,...

Maybe it is helpful. Especially if you do a lot of similar boards. For me, at least at first it was confusing as
you had to know that pins 0-5 were the Analog 0-5 pins, so D0 is actually header pin 6...

It would probably help to see more examples. And how this translates back to the Arduino side.

For example if you could define, logical connectors that show all of the available pins for each of the different carrier boards,
like: on the hat carrier board, on the RPI connector pin 7 maps to the H7 pin PA_8
and the PH connector pin 9 goes to PJ_7
.
Or on the Mid Breakout - by names? like GPIO1 -> ...

For the Arduino/C++ world, I might suggest in one of the header files, one could do this, by
adding Name spaces with defines or named Enums where maybe one could do: PMIDC::GPIO1 as a pin number passed to pinMode(...
But I don't know how that translates back into the zephyr world.

Sorry hopefully others with more experience here with zephyr might give a more coherent response.

Sorry for being late to the party but am confused as how that would help if working with the breakout boards for the h7 as@KurtE mentioned. Does make sense when you work with a board like the GIGA or the uno or the due or the mega that has the pin numberin on the headers for the most post. In the case of the mid-carrier there are no pin-numberings only pin names.

So as@KurtE mentioned what is the reference equivalent - how would I know what the pin-number for GPIO-6 would be or for sda/scl etc. I would be guess or assuming. For these breakout boards I think you would need to enumerate them somehow as Kurt mentioned.

Now - I can see if you just want to use them for CPU board since the pins are numbered but not labeled.

Think if you try to use aliases it would make the overlays even more confusing.

@pillo79 and all,

Follow up on the idea:

On this topic the idea I had was to fully exploit the same ZephyrGPIO nexus nodes abstraction used in thearduino-r3-connector

Zephyr World
I am getting a better handle on some of this, through my exercise of trying to add some support for the Teensy Micromod. I had mostly treated it as a Teensy and the reviewers would like it to have more Micromod support. So for example added one of these nodes:

micromod_header: connector {compatible = "sparkfun,micromod-gpio";#gpio-cells = <2>;gpio-map-mask = <0xffffffff 0xffffffc0>;gpio-map-pass-thru = <0 0x3f>;gpio-map = <0 0 &gpio1 18 0>, /* A0         MMOD 34 */      <1 0 &gpio1 19 0>, /* A1         MMOD 38 */      <2 0 &gpio4 6 0>, /* D0         MMOD 10 */      <3 0 &gpio4 8 0>, /* D1/CAM_TRIG MMOD 18 */      <4 0 &gpio4 31 0>, /* I2C_INT#   MMOD 16 */      <5 0 &gpio2 4 0>, /* G0/BUS0    MMOD 40 */      <6 0 &gpio2 5 0>, /* G1/BUS1    MMOD 42 */      <7 0 &gpio2 6 0>, /* G2/BUS2    MMOD 44 */      <8 0 &gpio2 7 0>, /* G3/BUS3    MMOD 46 */      <9 0 &gpio2 8 0>, /* G4/BUS4    MMOD 48 */      <10 0 &gpio2 9 0>, /* G5/BUS5    MMOD 73 */      <11 0 &gpio2 10 0>, /* G6/BUS6    MMOD 71 */      <12 0 &gpio2 11 0>, /* G7/BUS7    MMOD 69 */      <13 0 &gpio1 30 0>, /* G8         MMOD 67 */      <14 0 &gpio2 12 0>, /* G9/ADC_D-/ MMOD 65 */      <15 0 &gpio4 7 0>, /* G10/ADC_D+ MMOD 63 */      <16 0 &gpio1 31 0>,  /* G11/SWO    MMOD  8 */      <17 0 &gpio2 0 0>; /* SPI_CS     MMOD 55 */};

as well as some mappings:

// Sparkfun Micromod compatible pinsmicromod_1_uart: &lpuart6 {};micromod_2_uart: &lpuart3 {};micromod_0_i2c: &lpi2c1 {};micromod_1_i2c: &lpi2c4 {};micromod_0_spi: &lpspi4 {};

As I understand it, these will then potentially allow one to use this in shields that are defined for it. Currently MMOD only has one (Asset Tracker overlay)... Don't have one of these, but... With this shield, then all pins used and things like SPI, I2C are used through these defines, like:

&micromod_0_i2c {max17048: max17048@36 {compatible = "maxim,max17048";reg = <0x36>;status = "okay";};};

So now what I believe you were maybe saying, that For the Portenta and maybe some more for the GIGA, you might define a
couple more connector objects: Like J1 and J2 (probably not the names you would use)

On the GIGA - maybe at least one new one that defines the connector used both on GIGA and the Mid Carrier board for Portenta.

And then potentially define shields for the different carrier boards (Hat, breakout, Mid, ..) that use these connector
definitions and defines?

I have not experimented in my own test program, on how to access one or more pins out of the connectors, but I assume
there might be ways in a similar way as for uart like:
const struct device *const usb_uart_dev = DEVICE_DT_GET_ONE(zephyr_cdc_acm_uart);
something like: <micromod_header 2>

Arduino World
One of the many things I am unclear on, is how this then translates into the Arduino world? Will there be multiple
variants for each type of board? Like Giga, and Giga with display shield. Portenta H7, Portenta H7 on breakout board, Portenta
on Mid Carrier, Hat, ... C32, C32 on ...

Resource naming and numbering. How compatible should it be with currently released (MBED, Renesas) Arduino boards/variants?
We have already answered somewhat that we don't need/want to have the full Portenta H7 MBED pin table, where after
all of the fixed pins (ones on outside of board, plus LEDS...) there was a complete list of all possible pins. But I personally
believe we should have access to all possible GPIO pins that one can connect up to today using the different boards, such
as the breakout carrier. Pin/Resource names?

Or are you thinking a complete new/updated Arduino model?

Sorry, just trying to get a better understanding, of what direction we are going.

Thanks

@facchinm -@pillo79 -@KurtE

Is there any update on how you want to handle the HD connector pins so the carrier boards can be used? Haven't seen anything further discussing this?

Thanks
Mike