Portenta H7: Pin Table - How complete should it be? Compatible with MBED version?

[KurtE]

@pillo79 @facchinm @mjs513 and all:

We are starting to play with the Portenta H7. I have one of the H7 and one of the H7 lite processors and a breakout board and a Hat Carrier.
Starting to go through some of the basic testing. Earlier when I played with it using MBED, I added pages to my GIGA pin out excel document:
https://github.com/KurtE/Arduino_GIGA-stuff/blob/main/Documents/Arduino_GIGA_R1_pins.xlsx
Which still needs to be cleaned up.

It looks like the current state of the pin table in the overlay is pretty limited:

		digital-pin-gpios = <&gpioh 15 GPIO_ACTIVE_LOW>,
				    <&gpiok 1 GPIO_ACTIVE_LOW>,
				    <&gpioj 11 GPIO_ACTIVE_LOW>,
				    <&gpiog 7 GPIO_ACTIVE_LOW>,
				    <&gpioc 7 GPIO_ACTIVE_LOW>,
				    <&gpioc 6 GPIO_ACTIVE_LOW>,
				    <&gpioa 8 GPIO_ACTIVE_LOW>,
				    <&gpioi 0 GPIO_ACTIVE_LOW>,
				    <&gpioc 3 GPIO_ACTIVE_LOW>,
				    <&gpioi 1 GPIO_ACTIVE_LOW>,
				    <&gpioc 2 GPIO_ACTIVE_LOW>,
				    <&gpioh 8 GPIO_ACTIVE_LOW>,
				    <&gpioh 7 GPIO_ACTIVE_LOW>,
				    <&gpioa 10 GPIO_ACTIVE_LOW>,
				    <&gpioa 9 GPIO_ACTIVE_LOW>,
					<&gpiok 5 GPIO_ACTIVE_LOW>;	// LEDR

Which does align with the MBED version for D0-D14, however LEDR on MBED is something like pin 23 and here currently pin 15.
On MBED the table looks like:

PinDescription g_APinDescription[] = {
  // D0 - D7
  { PH_15,        NULL, NULL, NULL },    // D0
  { PK_1,         NULL, NULL, NULL },    // D1
  { PJ_11,        NULL, NULL, NULL },    // D2
  { PG_7,         NULL, NULL, NULL },    // D3
  { PC_7,         NULL, NULL, NULL },    // D4
  { PC_6,         NULL, NULL, NULL },    // D5
  { PA_8,         NULL, NULL, NULL },    // D6
  { PI_0,         NULL, NULL, NULL },    // D7

  // D8 - D14
  { PC_3,         NULL, NULL, NULL },    // D8
  { PI_1,         NULL, NULL, NULL },    // D9
  { PC_2,         NULL, NULL, NULL },    // D10
  { PH_8,         NULL, NULL, NULL },    // D11
  { PH_7,         NULL, NULL, NULL },    // D12
  { PA_10,        NULL, NULL, NULL },    // D13
  { PA_9,         NULL, NULL, NULL },    // D14

  // A0 - A6
  { PA_0C,        NULL, NULL, NULL },    // A0    ADC2_INP0
  { PA_1C,        NULL, NULL, NULL },    // A1    ADC2_INP1
  { PC_2C,        NULL, NULL, NULL },    // A2    ADC3_INP0
  { PC_3C,        NULL, NULL, NULL },    // A3    ADC3_INP1
  { PC_2_ALT0,    NULL, NULL, NULL },    // A4    ADC1_INP12
  { PC_3_ALT0,    NULL, NULL, NULL },    // A5    ADC1_INP13
  { PA_4,         NULL, NULL, NULL },    // A6    ADC1_INP18
  { PA_6,         NULL, NULL, NULL },    // A7    ADC1_INP7

  // LEDS
  { PK_5,         NULL, NULL, NULL },    // LEDR
  { PK_6,         NULL, NULL, NULL },    // LEDG
  { PK_7,         NULL, NULL, NULL },    // LEDB

  { PA_0,         NULL, NULL, NULL },
  { PA_1,         NULL, NULL, NULL },
  { PA_2,         NULL, NULL, NULL },
  { PA_3,         NULL, NULL, NULL },
  { PA_4,         NULL, NULL, NULL },
  { PA_5,         NULL, NULL, NULL },
  { PA_6,         NULL, NULL, NULL },
  { PA_7,         NULL, NULL, NULL },
  { PA_8,         NULL, NULL, NULL },
  { PA_9,         NULL, NULL, NULL },
  { PA_10,        NULL, NULL, NULL },
  { PA_11,        NULL, NULL, NULL },
  { PA_12,        NULL, NULL, NULL },
  { PA_13,        NULL, NULL, NULL },
  { PA_14,        NULL, NULL, NULL },
  { PA_15,        NULL, NULL, NULL },
  { PB_0,         NULL, NULL, NULL },
...
  { PK_5,         NULL, NULL, NULL },
  { PK_6,         NULL, NULL, NULL },
  { PK_7,         NULL, NULL, NULL },
};

Where you have pins PA_0-15, PB_0-15... PJ_0-15, PK_0-7

Which obviously some of these pins point to other pins with the same underlying hardware pin...
Some probably do not connect up to anything.  
If I print out number of digital pins and count of pins I see:

NUM_DIGITAL_PINS: 22
PINS_COUNT: 194

So main questions include:
a) Should the pin out match the MBED version?
b) My assumption is that all of the pins that could be used for digital stuff that are exported through the connectors should have a pin number assigned to them. For example you have several of the UARTS defined which is great, but I would also expect that for those uarts that a sketch does not utilize, I could use the RX and TX and on some of them RTS and CTS pins, as normal IO pins.

Thoughts?

[mjs513]

@KurtE
As a FYI received my H7 Lite and the carrier should be here on Monday.

[KurtE]

I just pushed up again an updated copy of the GIGA/Portenta XLS document. Added a new page where I tried to see just how many pins of athe PA0-PK7 are used. Answer almost all of them.

I did it by trying to extract all of the pin numbers from the main connectors J1, J2, plus pins on the board.
Then went through the schematic and see where the pins that were not on those connectors were used.

Places like SDRAM, Ethernet, ... Also then added on to each row the AF functions for each pin... starts off like:

[KurtE]

Quick update:
I thought I would try out my GIGA Zephyr ILI9341 library on the Portenta H7. Still getting used to the Portenta Breakout board.
I need to setup a cheat sheet of what each of the pins on it, hook up to which pins on the H8 boards and probably later on C33.

First issue, I ran into was, spi was not setup in the overaly. So I added it (spi2). And started testing it... Found that the exported SPI from the H8 connects up to the SPI1 pins on the breakout board.

When defining the SPI object, I believe that it uses pins 8-10 which I was using in the sketch for RESET, DC, CS.
So change to using 4-6. First guess was maybe they would map to GPIO0-5 section on the breakout... Nope:
4-6 maps to the PWM section 2-0

So hooked up to those pins, and then ran the Graphic test program and nothing showed up on the screen, but I was seeing
stuff on the Logic analyzer. But but then ran into the next issue:
Looked like all of the GPIO pins were inverted in output. To confirm this did a quick and dirty sketch:

int pin = 4;  //
void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 5000) {}
  pinMode(pin, OUTPUT);
}

void loop() {
  digitalWrite(pin, HIGH);
  delay(250);
  digitalWrite(pin, LOW);
  if (Serial.available()) {
    pin = Serial.parseInt();
    while (Serial.read() != -1) {};
    pinMode(pin, OUTPUT);
    digitalWrite(pin, LOW);
  } else delay(100);
}

Expected HIigh signal to be 250ms and Low 100ms, but:

It was inverted

I looked at the overlay file and found that all of the GPIO pins were marked, like: <&gpiok 6 GPIO_ACTIVE_LOW>,
Whereas if you look at the GIGA table only the LED pins were marked that way, the others were like: <&gpiok 1 0>,

So I updated the table to be like the GIGA and rebuilt the kernel... And now:

Will probably generate a PR for this initial stuff. Will then depending on things, may try to add all of the other
pins like MBED version.

[KurtE]

Update:

I updated the pins list, to be compatible with the MBED version. Except there are some issues with the Analog pins.

In particular: MBED version.

  // D8 - D14
  { PC_3,         NULL, NULL, NULL },    // D8
  { PI_1,         NULL, NULL, NULL },    // D9
  { PC_2,         NULL, NULL, NULL },    // D10
  { PH_8,         NULL, NULL, NULL },    // D11
  { PH_7,         NULL, NULL, NULL },    // D12
  { PA_10,        NULL, NULL, NULL },    // D13
  { PA_9,         NULL, NULL, NULL },    // D14

  // A0 - A6
  { PA_0C,        NULL, NULL, NULL },    // A0    ADC2_INP0
  { PA_1C,        NULL, NULL, NULL },    // A1    ADC2_INP1
  { PC_2C,        NULL, NULL, NULL },    // A2    ADC3_INP0
  { PC_3C,        NULL, NULL, NULL },    // A3    ADC3_INP1
  { PC_2_ALT0,    NULL, NULL, NULL },    // A4    ADC1_INP12
  { PC_3_ALT0,    NULL, NULL, NULL },    // A5    ADC1_INP13
  { PA_4,         NULL, NULL, NULL },    // A6    ADC1_INP18
  { PA_6,         NULL, NULL, NULL },    // A7    ADC1_INP7

For the _C type pins, I set them up the same was as was done for the GIGA.
Note: I have not yet fully setup analog yet.

But, I don't know what is suggested for the ALT0 pins, like A4 and A5.

I also don't know the full relationship between the pin and the complementary pin. That is
Can I use D8 (PC_3) in my sketch when I am using A3(PC_3C) for analog?
My assumption is A5(PC_3_ALT0), is that if I use it, I can not use D8? but can I use A3 and A5?

May have to experiment to find out!
Current version of tha A0-A6:

  					<&gpioz 0 0>,  		/* A0    ADC2_INP0 */
  					<&gpioz 1 0>,  		/* A1    ADC2_INP1 */
  					<&gpioz 2 0>,  		/* A2    ADC3_INP0 */
  					<&gpioz 3 0>,  		/* A3    ADC3_INP1 */
  					<&gpioc 2 0>,  		/* A4 _ALT0?   ADC1_INP12 */
  					<&gpioc 3 0>,    	/* A5 _ALT0?   ADC1_INP13 */
  					<&gpioa 4 0>,       /* A6    ADC1_INP18 */
  					<&gpioa 6 0>,       /* A7    ADC1_INP7 */

Again not sure how to encode ALT0 yet. Maybe another hack on the gpioz and deadbeef?

EDIT: Forgot to mention: I updated the sketch I used to check the pin numbers which also shows the Port/pin number
for the pins, and went through and verified the pins on both the Portenta HAT and the breakout boards.
Excel document updated to show the port/pins for these two shields

[mjs513]

@KurtE - synched up with your config and overlay files. And running now - only tested i2c so far

[KurtE]

@facchinm @pillo79,

@mjs513 and myself, have been trying out different things on Zephyr and currently the Portenta H7 and H7 Lite.

As mentioned earlier in this issue, we have setup a version that matches the MBED Portenta H7 pin numbering.

I originally purchased the H7 (and Hat carrier), it was simply to see how it compared with the GIGA. It was unclear to me at the time,
if there was any prescribed way that when developing a sketch for it, How one should deduce what the pin number was to use different functions on the HAT, so I rang them out. And setup a page of an excel document with the pin numbering:

Not sure if this is what other users do or don't do?
So we currently have the table:

	zephyr,user {
		digital-pin-gpios = <&arduino_header 6 0>,
						<&arduino_header 7 0>,
						<&arduino_header 8 0>,
						<&arduino_header 9 0>,

Matching the MBED version.

However one side effect is the: simple example sketch Examples->basic->blink will now Faults.
Why?
The code in Arduino.h computes the LED_BUILTIN, by looking through the device tree.
It finds the LEDR in the LED table, it then walks the GPIOS table trying to find that pin:
Problem is, that pin (PK_5) exists twice in the GPIO list:
First in the low part of the pin table 23 and later in the PORT/Pin section that start
with PA_0-15, PB0-15...,PK0-7 as 191.

And the lookup code in Arduino.h sums them:

/* Only matched pin returns non-zero value, so the sum is matched pin's index */
#define DIGITAL_PIN_GPIOS_FIND_PIN(dev, pin)                                                     \
	DT_FOREACH_PROP_ELEM_SEP_VARGS(DT_PATH(zephyr_user), digital_pin_gpios,                    \
				       LED_BUILTIN_INDEX_BY_REG_AND_PINNUM, (+), dev, pin)

So it says: LED_BUILTIN is 214, which is beyond the end of the table. And the code does not check... and later faults.

Easy fix in this case, is to simply define it in variant.h
Question? assuming we wish to have compatibility with MBED version should we also define most/all of the names
in the MBED enum PinName PinNames.h file?

Secondary notes: Looks like the Portenta C33 order of pins in MBED is completely different. More organized by major functionality groups. Not sure if any of the 122 pins in that table map down to same pin or not.
I have a C33 arriving today, so will be able to do some playing with it on MBED. Looks like you are making progress on
the zephyr version.

Now back to playing

[facchinm]

Sorry for arriving so late Mike, I'm absolutely in favour of dropping the mbed compatibility after pin 13 (MKR header), so we can adopt a saner table and strategy and eventually there's no need for the extra patch. This applies to #71

[KurtE]

@facchinm - Not sure how this would work?
That is currently H7 has:

	zephyr,user {
		digital-pin-gpios = <&gpioh 15 GPIO_ACTIVE_LOW>,
				    <&gpiok 1 GPIO_ACTIVE_LOW>,
				    <&gpioj 11 GPIO_ACTIVE_LOW>,
				    <&gpiog 7 GPIO_ACTIVE_LOW>,
				    <&gpioc 7 GPIO_ACTIVE_LOW>,
				    <&gpioc 6 GPIO_ACTIVE_LOW>,
				    <&gpioa 8 GPIO_ACTIVE_LOW>,
				    <&gpioi 0 GPIO_ACTIVE_LOW>,
				    <&gpioc 3 GPIO_ACTIVE_LOW>,
				    <&gpioi 1 GPIO_ACTIVE_LOW>,
				    <&gpioc 2 GPIO_ACTIVE_LOW>,
				    <&gpioh 8 GPIO_ACTIVE_LOW>,
				    <&gpioh 7 GPIO_ACTIVE_LOW>,
				    <&gpioa 10 GPIO_ACTIVE_LOW>,
				    <&gpioa 9 GPIO_ACTIVE_LOW>,
					<&gpiok 5 GPIO_ACTIVE_LOW>;	// LEDR

So assuming I have my Portenta plugged into another board, currently I have: Mid carrier, Hat Carrier and breakout board.

How would one plug in a device and use any of the other pins that are exposed? I can imagine exposing most all of the pins that are exposed directly by the pins on the Portenta, plus LEDS and most if not all of them on the High density connectors, except for those which are used for very specific things like SDRAM, or USB or ...

I am still wondering about creating an PinName enum (maybe copy from MBED) and have the pinName duplicate functions, much in the way you have pure_analog pins. It should also include a function to map from name to number...
The port/pin can be encoded the same way 4 bits each. Only question I had was how to map from lets say PortA to the device tree PortA object. Such that we could then call like: return gpio_pin_set(spec->port, spec->pin, value);

Why I think we probably need something is without it, converting and or testing between the MBED version and the Zephyr version will be a PIA. That is suppose I wish to use the pin labeled: GPIO4 on the Mid Carrier, What do I pass to the APIs?
I can for example maybe know which pin it actually is:
From the MID Carrier file:
https://docs.arduino.cc/static/8ef771ee25fbb0fd245598df70429cbf/ASX00055-software-pinout-mapping.pdf?_gl=1*163ype5*_up*MQ..*_ga*MTMyODkxMzYxNi4xNzQxMTk0Mjgx*_ga_NEXN8H46L5*MTc0MTE5NDI3OC4xLjEuMTc0MTE5NDI4Mi4wLjAuODAxMzQ3OTAy

I see it is PE_3, now how do map this to digital Pin?
With MBED I cheated and could compute: 26+ 4*16 + 3 = 93 ...
But now with Zephyr what would I do? I would probably run sketch for all possible pins and ring it out, but that is not perfect.

Suggestions?

[facchinm]

My gut feeling here is that we should provide a "Portenta pinout" with the abstract names as macros/enums in either the core or zephyr, so the final user with any carrier will be able to call
pinMode(GPIO4, INPUT) or even pinMode(I2S_CK, OUTPUT) without knowing which pin number is associated with that pin

I searched the public web a bit for usages of the exact pin number and I couldn't find any example except "catchall" sketches, so I'm quite confident it wouldn't break anything

[KurtE]

Thanks @facchinm,

I agree with you, that there is some need something like this. And it is not new for zephyr, similar issues on MBED version. For example this thread that was opened in the last day:
https://forum.arduino.cc/t/access-portenta-mid-carrier-gpio-pins-in-arduino-ide-code/1360740/1

Currently on MBED, you have the Alternate functions that use enum PinNames in the header file PinNames.h

typedef enum {
    PA_0       = 0x00,
    PA_0C      = PA_0  | DUAL_PAD, // dual pad
    PA_0C_ALT0 = PA_0C | ALT0, // same pin used for alternate HW
    PA_0C_ALT1 = PA_0C | ALT1, // same pin used for alternate HW
    PA_0C_ALT2 = PA_0C | ALT2, // same pin used for alternate HW
    PA_1       = 0x01,
    PA_1C      = PA_1  | DUAL_PAD, // dual pad
    PA_1C_ALT0 = PA_1C | ALT0, // same pin used for alternate HW
    PA_1_ALT0  = PA_1  | ALT0, // same pin used for alternate HW
    PA_2       = 0x02,
...
    PK_0       = 0xA0,
    PK_0_ALT0  = PK_0  | ALT0, // same pin used for alternate HW
    PK_1       = 0xA1,
    PK_1_ALT0  = PK_1  | ALT0, // same pin used for alternate HW
    PK_2       = 0xA2,
    PK_3       = 0xA3,
    PK_4       = 0xA4,
    PK_5       = 0xA5,
    PK_6       = 0xA6,
    PK_7       = 0xA7,
...
    //Led mappings
    LED_RED = PK_5,  //Red
    LED_GREEN = PK_6,  //Green
    LED_BLUE = PK_7,  //Blue
...

Which has all of the mappings for the PA_0-PK_7 mappings. It also has some of the generic mappings like LED_RED.
The file pns_arduino.h in the variants has some of the others like:
#define SERIAL2_TX PA_15

My gut says you will need something that you may need multiple ways to map:
As you mentioned, maybe: pinMode(GPIO4, INPUT)
likewise: pinMode(PE_3, INPUT)
And probably some number(0-255) as I may want to use it as the Chip select pin I pass to some library, like
one of my own libraries or one from Adafruit...

Another main reason one needs to understand which pin is which, is many of them are used for multiple things, both on the
Portenta itself but also on the different boards: Like on the board PC_2 and PC_3 are used 3 different ways. Althought probably
the _C versions do not conflict with the others.

I really wish some of the documentation on the carrier boards was easier to find some additional information:
For example the Mid Carier documentation has the Software Mapping file, I mentioned in the previous post:
Which shows you the pinouts for the two main pinout connectors, but it does not show you the pin outs for some of the
other connectors like the Camera one or the display shield. As for example the two pins I mentioned GPIO3 and GPIO4
Are also used for the Camera:

As the Enable and Power Down pins.

On the Breakout board, you end up using the first couple pages of the schematic to figure out which pin is which:
Like for the camera stuff:

Does not have the same breakout as Mid as does not have Arducam pinout... Wish it also had document like the
Mid Carrier. (Also wish for consistent naming: PA1 versus PA_1

Hat Carrier: The first one I purchased when I bought the H7, is more of a challenge. I ended up mapping the pins, by:
Looking at the pin out document: and look at: pin 3 of 40 pin connector is on J2-45 and went to the advanced pin out
table and found:

to find out that is PH12...

So I did my own Excel document with all of the mappings.

I do appreciate that one can find most of this information with the documentation you have generated, and I did not
necessarily need to resort to using the Reference Manual and Product page, although I did to generate some pages in
my excel document: Which the mux page starts off like:

<style> </style>

Pin #	Column1	Pin Name	Usage	Port	AF0	AF1	AF2	AF3	AF4	AF5	AF6	AF7	AF8	AF9	AF10	AF11	AF12	AF13	AF14	AF15
0		PH_15		PH15	-	-	-	TIM8_CH3N	-	-	-	-	-	FDCAN1_ TXFD_ MODE	-	-	FMC_D23	DCMI_D11	LCD_G4	EVENT OUT
1		PK_1		PK1	-	TIM1_CH1	-	TIM8_CH3N	-	SPI5_NSS	-	-	-	-	-	-	-	-	LCD_G6	EVENT OUT
2		PJ_11		PJ11	-	TIM1_CH2	-	TIM8_CH2N	-	SPI5_MISO	-	-	-	-	-	-	-	-	LCD_G4	EVENT OUT
3		PG_7		PG7	-		HRTIM_CH E2				SAI1_MCLK _A	USART6_ CK	-	-	-	-	FMC_INT	DCMI_D13	LCD_CLK	EVENT OUT
4		PC_07		PC7	TRGIO	HRTIM_CH A2	TIM3_CH2	TIM8_CH2	DFSDM1_ DATIN3	-	I2S3_MCK	USART6_ RX	SDMMC1_ D123DIR	FMC_NE1	SDMMC2_ D7	SWPMI_TX	SDMMC1_ D7	DCMI_D1	LCD_G6	EVENT OUT
5		PC_06		PC6	-	HRTIM_CH A1	TIM3_CH1	TIM8_CH1	DFSDM1_ CKIN3	I2S2_MCK	-	USART6_ TX	SDMMC1_ D0DIR	FMC_ NWAIT	SDMMC2_ D6	-	SDMMC1_ D6	DCMI_D0	LCD_ HSYNC	EVENT OUT
6		PA_8		PA8	MCO1	TIM1_CH1	HRTIM_ CHB2	TIM8_BKIN2	I2C3_SCL	-	-	USART1_ CK	-	-	OTG_FS_ SOF	UART7_RX	TIM8_BKIN 2_COMP12	LCD_B3	LCD_R6	EVENT OUT
7		PI_0		PI0	-	-	TIM5_CH4	-	-	SPI2_NSS/ I2S2_WS	-	-	-	FDCAN1_ RXFD_ MODE	-	-	FMC_D24	DCMI_D13	LCD_G5	EVENT OUT
8		PC_3		PC3	C1 SLEEP	-	-	DFSDM1_ DATIN1	-	SPI2_MOSI /I2S2_SDO	-	-	-	-	OTG_HS_U LPI_NXT	ETH_MII_ TX_CLK	FMC_SDCK E0	-	-	EVENT OUT
9		PI_1		PI1	-	-	-	TIM8_BKIN2	-	SPI2_SCK/ I2S2_CK	-	-	-	-	-	TIM8_BKIN 2_COMP12	FMC_D25	DCMI_D8	LCD_G6	EVENT OUT
10		PC_2		PC2	C1 DSLEEP	-	-	DFSDM1_ CKIN1	-	SPI2_MISO /I2S2_SDI	DFSDM1_ CKOUT	-	-	-	OTG_HS_ ULPI_DIR	ETH_MII_ TXD2	FMC_SDNE 0	-	-	EVENT OUT
11		PH_8		PH8	-	-	TIM5_ETR	-	I2C3_SDA	-	-	-	-	-	-	-	FMC_D16	DCMI_ HSYNC	LCD_R2	EVENT OUT
12		PH_7		PH7	-	-	-	-	I2C3_SCL	SPI5_MISO	-	-	-	-	-	ETH_MII_R XD3	FMC_SDCK E1	DCMI_D9	-	EVENT OUT
13		PA_10		PA10	-	TIM1_CH3	HRTIM_ CHC2	LPUART1_ RX	-	-	-	USART1_ RX	-	FDCAN1_ TXFD_ MODE	OTG_FS_ ID	MDIOS_ MDIO	LCD_B4	DCMI_D1	LCD_B1	EVENT OUT
14		PA_9		PA9	-	TIM1_CH2	HRTIM_ CHC1	LPUART1_ TX	I2C3_SMBA	SPI2_SCK/ I2S2_CK	-	USART1_ TX	-	FDCAN1_ RXFD_ MODE	-	ETH_TX_ ER	-	DCMI_D0	LCD_R5	EVENT OUT

Question is what to do in the short term?
We do have that open PR which did/or does match the MBED mappings. We did trim off the last pins of PJ_n to not
duplicate the LEDS. I left in the duplicates for PWM pins, by using some different mapping code, that
converted the PWM table to pins differently.

Thanks

 

 

[KurtE]

@facchinm @pillo79 @mjs513 and all:

Sorry for yesterday's book. Hope some of it makes sense. 😆

I am wondering about doing sort of a mixed solution for the pins. That is I believe the pin table that I have in the current PR, could be slimmed down, to maybe only have on it the pins that can be used. Like the main pins that are on the Portenta H7s, Plus probably a lot of the ones on the different carriers, like the GPIOs and the PWMS, ADCs, ... more or less all of the pins that one
would likely would pass off to a library by number...

Then Port over the Portenta's MBED PinName as overloads. I have a sketch that reasonably works where I:

#include "PinNames.h"
void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 5000) {}
  if (Serial) {
    Serial.print("Red Pin: "); Serial.println(PinNameToIndex(LED_RED));
    Serial.print("Green Pin: "); Serial.println(PinNameToIndex(LED_GREEN));
    Serial.print("Blue Pin: "); Serial.println(PinNameToIndex(LED_BLUE));
  }
  pinMode(LED_RED, OUTPUT);
  pinMode(LED_BLUE, OUTPUT);
  pinMode(LED_GREEN, OUTPUT);

}

uint8_t loop_count = 0;
void loop() {
  loop_count = (loop_count + 1) & 0x7;
  digitalWrite(LED_RED, (loop_count & 1)? HIGH : LOW );
  digitalWrite(LED_BLUE, (loop_count & 2)? HIGH : LOW );
  digitalWrite(LED_GREEN, (loop_count & 4)? HIGH : LOW );
  delay(250);
  
}

The whole sketch including a header file with the slightly stripped down version of the PinNames.h (removed all of the ones that had things like | ALT0

zephyr_pin_names_test-250307a.zip

And I have a .cpp file that processes them as a quick and dirty.

I am not an expert in the Device Tree APIS and the like, so there is probably a cleaner way for one to get the
address of the gpio objects gpioa, gpiob...

Current way is I hacked up the overlay and added:

		port-pin-gpios =	<&gpioa 0 0>,
					<&gpiob 0 0>,
					<&gpioc 0 0>,
					<&gpiod 0 0>,
					<&gpioe 0 0>,
					<&gpiof 0 0>,
					<&gpiog 0 0>,
					<&gpioh 0 0>,
					<&gpioi 0 0>,
					<&gpioj 0 0>,
					<&gpiok 0 0>;

And then build a table in the same way as GPIO does...
And then I have a couple of functions like:

// duplicate of one in zephyr common
static const struct gpio_dt_spec arduino_pins[] = {DT_FOREACH_PROP_ELEM_SEP(
	DT_PATH(zephyr_user), digital_pin_gpios, GPIO_DT_SPEC_GET_BY_IDX, (, ))};

static const struct gpio_dt_spec arduino_ports[] = {DT_FOREACH_PROP_ELEM_SEP(
  DT_PATH(zephyr_user), port_pin_gpios, GPIO_DT_SPEC_GET_BY_IDX, (, ))};


void digitalWrite(PinName pinNumber, PinStatus status) {
	  gpio_pin_set(arduino_ports[pinNumber >> 4].port, pinNumber & 0xf, status);
}

int PinNameToIndex(PinName P) {
  for(size_t i=0; i<ARRAY_SIZE(arduino_pins); i++) {
    if ((arduino_ports[P >> 4].port == arduino_pins[i].port) && ((P & 0xf) == arduino_pins[i].pin)) {
      return i;
    }
  }
  return -1;
}

pinMode is similar, If I go farther with this, I would probably have it first call: PinNameToIndex and if index is found, call
the normal pinMode function, that way it should pickup any DT defined attributes for the pin.

Thoughts?