1.23.0-preview: machine.Pin has undocumented subclasses

[Josverl]

I find a few new/undocumented properties in the machine.Pin class

• cpu : <class 'cpu'>
• board : <class 'board'>

Any suggestion what these may be ?
(Also deeper inspection of these classes resets the MCU , I think that may be a bug, but first let me understand what the meanting is )

import machine
print( dir(machine.Pin))
for a in dir(machine.Pin):
    if a[0] == "_" : continue
    print(a)
    print(getattr(machine.Pin,a))

['__class__', '__name__', 'value', 'DRIVE_0', 'DRIVE_1', 'DRIVE_2', 'DRIVE_3', 'IN', 'IRQ_FALLING', 'IRQ_RISING', 'OPEN_DRAIN', 'OUT', 'PULL_DOWN', 'PULL_UP', 'WAKE_HIGH', 'WAKE_LOW', '__bases__', '__dict__', 'board', 'init', 'irq', 'off', 'on']
value
<function>
DRIVE_0
0
DRIVE_1
1
DRIVE_2
2
DRIVE_3
3
IN
1
IRQ_FALLING
2
IRQ_RISING
1
OPEN_DRAIN
7
OUT
3
PULL_DOWN
1
PULL_UP
2
WAKE_HIGH
5
WAKE_LOW
4
board
<class 'board'>
init
<function>
irq
<function>
off
<function>
on
<function>

Portinfo

{'port': 'esp32',
 'build': '',
 'arch': 'xtensawin',
 'family': 'micropython',
 'board': 'Generic ESP32 module with ESP32',
 'cpu': 'ESP32',
 'version': '1.23.0-preview',
 'mpy': 'v6.2',
 'ver': 'v1.23.0-preview',
 'serial_port': 'auto'}

[robert-hh]

They are new for ESP32, but exist in other ports since a while. The list Pin objects, either in the naming scheme of the CPU, or of the board with the names that are printed on the silkscreen. The ESP32 just has an empty Pin.board class and should not have a Pin.cpu class. For a Metro M7 board (CPU i.mx rt 1010) you get the following lists:

>>> from machine import Pin
>>> dir(Pin.cpu)
['__class__', '__name__', 'GPIO_00', 'GPIO_01', 'GPIO_02', 'GPIO_03', 'GPIO_04', 'GPIO_05', 'GPIO_06', 'GPIO_07', 'GPIO_08', 'GPIO_09', 'GPIO_10', 'GPIO_11', 'GPIO_12', 'GPIO_13', 'GPIO_AD_00', 'GPIO_AD_01', 'GPIO_AD_02', 'GPIO_AD_03', 'GPIO_AD_04', 'GPIO_AD_05', 'GPIO_AD_06', 'GPIO_AD_07', 'GPIO_AD_08', 'GPIO_AD_09', 'GPIO_AD_10', 'GPIO_AD_11', 'GPIO_AD_12', 'GPIO_AD_13', 'GPIO_AD_14', 'GPIO_SD_00', 'GPIO_SD_01', 'GPIO_SD_02', 'GPIO_SD_03', 'GPIO_SD_04', 'GPIO_SD_05', 'GPIO_SD_06', 'GPIO_SD_07', 'GPIO_SD_08', 'GPIO_SD_09', 'GPIO_SD_10', 'GPIO_SD_11', 'GPIO_SD_12', 'GPIO_SD_13', 'PMIC_ON_REQ', '__bases__', '__dict__']
>>> type(Pin.cpu.GPIO_00)
<class 'Pin'>
>>> dir(Pin.board)
['__class__', '__name__', 'A0', 'A1', 'A2', 'A3', 'A4', 'A5', 'D0', 'D1', 'D10', 'D11', 'D12', 'D13', 'D14', 'D15', 'D2', 'D3', 'D4', 'D5', 'D6', 'D7', 'D8', 'D9', 'ESP_BUSY', 'ESP_CS', 'ESP_GPIO0', 'ESP_RESET', 'LED', 'MISO', 'MOSI', 'NEOPIXEL', 'SCK', '__bases__', '__dict__']
>>> type(Pin.board.A0)
<class 'Pin'>

With these, you can either use the pin objects as they are: Pin.board.A0, or as Pin("A0"). Similar for the Pin.cpu class, which may contain Pins not broken out at the board.

[Josverl]

Thanks Robert.
I could not find docs, but I did not look specifically for the ESP32.

Do you have a sample how they are supposed to be used.?

I find that when my stubber tries to map/introspect the classes that the board crashes/resets. I assume that isn't the intended behavior. I'll test which of the classes is the culprit

[Josverl]

update - the reboot issue disappears on closer inspection - while earlier it was repeatable like clockwork - bitter-sweet

[robert-hh]

e.g. Pin.board.A0 and Pin("A0") are both Pin objects for the same pin. So instead of calling the Pin("A0") method to get the pin object, it is already available in Pin.board.A0.

[Josverl]

Thanks, a quick search shows there that there little documentation, its used in a few examples, and a mention in the release notes.
Its not even documented for pyb.Pin

• Ill see in I can reverse engineer some docs from the implementation, but will need someone to review that.

[robert-hh]

I can do that.