Sanity check: A few strange things in the SAMD51 v1.20.0 firmware

[Josverl]

I notice that the umachine.Pin has a two class literals that Python would not allow

        5V_ENABLE : Any ## <class 'Pin'> = Pin("5V_ENABLE", mode=IN, pull=PULL_OFF, GPIO=PC14)
        3V3_ENABLE : Any ## <class 'Pin'> = Pin("3V3_ENABLE", mode=IN, pull=PULL_OFF, GPIO=PC15)

I'm not sure if this is new to the 1.20.0 build, or existed earlier
also not quite sure what PEP this violates , but names cannot start with a Digit , so perhaps change to ENABLE_5V instead ?

Also I notice that the umachine.uname() does not exist.
Is there any specific reason for that , or should it be enabled with #define MICROPY_PY_UOS_UNAME (1) ?
( the machine.name() issue is not new to 1.20.0)

>>>
MicroPython v1.20.0 on 2023-04-26; Wio Terminal D51R with SAMD51P19A
Type "help()" for more information.
>>> import machine 
>>> machine.uname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: no such attribute
>>>

[robert-hh]

There was no change in the Pin class between the last nightly build of v1.19.1 and v1.20. But there is a big difference between v1.19.1 "official" and v1.20. 5V_ENABLE and 3V3_ENABLE are just pin names, but go of course go into the pin.board class. They can be changed.

machine.uname() was in one PR, but not merged, because it's planned to drop it. So it's left off intentionally.

[Josverl]

Thanks Robert,

On the Pin names, for now I've added a check to avoid any names starting with a digit, as these can't be used anyway.

On the uname()

because it's planned to drop it.

Is there any discussion or plan around that?

I have a few scripts that currently rely on uname, that I'll need to find a different info source for.

[robert-hh]

On the Pin names, for now

I added a commit to change these to the actual service type PR, which collects small changes & fixes.

Is there any discussion or plan around that?

I do not know more that Damien's comment on my attempt to include machine.uname(). As a breaking change I expect that not to happen before version 2.0. As alternative sys.implementation may match.