Pin specification by integer\r disappeared

[robhamerling]

I didn't touch my Teensy40 for a while, but after I loaded it today with 1.22.preview.147 programs specifying a Pin by number - like Pin(10) - fail with message "Pin doesn't exists".
It seems required to specify Pin('D10') or a 'board' or 'cpu' name.
Is this change (omitting the possibility of integer specifications) on purpose or is it a bug/glitch?

[robert-hh]

Is this change (omitting the possibility of integer specifications) on purpose or is it a bug/glitch?

Hard to say. It is a side effect of PR12211, which unified across ports how pins data structures of a port are derived from pins.csv. Re-establishing the integer option is either difficult or ugly code, so I decided instead to change the documentation. See the discussion here: #12877
So given that there was no plan to remove the integer variant it's a bug. As part of a planned harmonization it's kind of intended. Still there are ports which allow to use an integer, like nrf, ESP32 or SAMD. But these have a clear mapping between the integer and the GPIO, which did not exist for the MIMXRT devices. At these, the integer was the index into the pins.csv file, which is somewhat unstable.

[robhamerling]

Thanks for this background info!
Harmonization looks like a good idea (although it may be the cause of unpleasant surprises).

[jimmo]

Yep exactly what @robert-hh said. This wasn't a deliberate change (as opposed to some of the other changes in that PR that were deliberate decisions to increase compatibility). I had noticed at the time this was different and then forgot to come back and re-think the next steps.

Using the index in the pins.csv file was a bit fragile, but the issue here is that it's different behavior to e.g. esp32 and rp2 where the numeric index is a cpu pin, but here it was a board pin.

But it's not uncommon for boards based on cpus to still put numeric "names" on their silkscreen. It's a bit confusing now that on, for example, the Teensy 4.0 that the silkscreen says "3" but you need to now use "D3".

We can certainly look at re-introducing pin numbering as a more deliberate feature across all ports (perhaps we should allow numeric entries in the board map?).

[robhamerling]

For my Teensy I had to update only a couple of scripts, not a big deal. But if the possibility of using pin numbers would disappear for ESP32, RP2 and maybe others families it will have a big impact with existing scripts.

[GitHubsSilverBullet]

Am I the only one who thinks that it's a pretty bad idea to replace Pin numbers with some descriptive strings? If a CPU has GPIO pins 0…29, I'd like to be able to use'em as pins 0…29 and not some fancy named strings.

Furthermore, while (to a certain degree) I do understand the wish make all boards and µC look the same, this Arduinofication goes a bit to far. Microcontrollers are usually different enough in pin-layout and functionality that it's not possible to just swap the source code and use a different platform anyways.

Sorry if this comes over a bit harsh, but I feel to speak up clearly would be the best path.

[robert-hh]

We are talking here about the MIMXRT port. And the i.MX RT MCU's have a quite irregular naming scheme for the GPIO pins. Unlike the ESP32, rp2, which uses numbers or other MCUs, which have GPIO names like PAxx, PBxx, .., which easily maps to a number. For the MIMXRT port, the number that could be used had no clear correspondence with GPIO pins. At the Teensy 4 for instance, Pin(1) mapped to GPIO_AD_B0_02, Pin(2) to GPIO_EMC_04, ... See the boards pins.csv.
The descriptive strings as you call them is the text printed on the silk screen of the board and at the schematics. Nothing stops you to use GPIO names instead.

[robert-hh]

@robhamerling The PR #12211 did not remove the option to use an integer to refer to a GPIO pin for MCUs like ESP32 and RP2. Even the NRF and SAMD port kept that option, even is at these boards using an integer is not obvious.

[GitHubsSilverBullet]

Understood. Good to hear that the others are left untouched.
I was actually just reacting to what @robhamerling wrote and just wanted to make sure…
No offense… ;-)