Add MIMXRT1010_EVK & SEEED_ARCH_MIX (mimxrt) v1.26.1

[andrewleech]

Hello,
I've been starting to use mimxrt chips a bit more and was hoping to assist in creating stubs for them.

I generated these from the two boards I've got on hand after loading the official release builds and running stubber installed from directly from GitHub.

Is this an appropriate way to submit the generated files?

Is there a standard process for generating the generic package for a platform eg micropython-mimxrt-stubs as opposed to a board specific one? Is that something I can help with?

[Josverl]

🥇for the first comple boards submitted.

I'l review to verify if there are no merge surprises, but I don't expect any.

After that Ill publish them for others to consume.

Is there a board that you think is most complete or representative for the port?

For instance for the RP2 port I have thus far used the rpi-pico_W as a superset of the pico

[andrewleech]

Is there a board that you think is most complete or representative for the port?

The SEEED_ARCH_MIX is a bigger chip, bigger board. Has a fair few more features enabled (eg. networking, sdcard) so is broader in feature coverage for sure.

[andrewleech]

I discovered a small thing missing from my stubs :-D micropython/micropython#18464

[Josverl]

If the PR does not get merged, I can also add the stub to the reference stubs. That is my shortcut.
Once documentation is merged, that Docstring will take priority

Ref stubs can also add detailed type annotations and overloads if needed.

[Josverl]

Is there a standard process for generating the generic package for a platform eg micropython-mimxrt-stubs as opposed to a board specific one? Is that something I can help with?

The default board for a port is currently "hard-configured" in a dict in micropython-stubber

I'll add : "mimxrt": ["SEEED_ARCH_MIX", ""], to set the 'reference' board and rebuild

[Josverl]

When I rebuild the stubs locally from the 'firmware' stubs I notice a class network.LAN(): that is not actually available on the board if I read the specs correctly.

the "firmware-stubs" just show :

# MCU: {'variant': '', 'build': '', 'arch': 'armv7emsp', 'port': 'mimxrt', 'board': 'MIMXRT1010_EVK', 'board_id': 'MIMXRT1010_EVK', 'mpy': 'v6.3', 'ver': '1.26.1', 'family': 'micropython', 'cpu': 'MIMXRT1011DAE5A', 'version': '1.26.1'}
# ...
STA_IF: Final[int] = 0
AP_IF: Final[int] = 1

def hostname(*args, **kwargs) -> Incomplete: ...
def route(*args, **kwargs) -> Incomplete: ...
def country(*args, **kwargs) -> Incomplete: ...

so no actual network interfaces at all ( though it does include the network module - which makes no real-world sense to me , and could save some bytes - but that is a different verture.

In the merged-stubs for the board I find:

class LAN:
    @overload
    def active(self, /) -> bool:
        """
        With a parameter, it sets the interface active if *state* is true, otherwise it
        sets it inactive.
        Without a parameter, it returns the state.
        """

    @overload
    def active(self, is_active: bool | int, /) -> None:
        """
        With a parameter, it sets the interface active if *state* is true, otherwise it
        sets it inactive.
        Without a parameter, it returns the state.
        """

that is not present in the merged-stubs your PR
https://github.com/andrewleech/micropython-stubs/blob/defb1d96acd94e08381f7939cf0f41e77d113af7/stubs/micropython-v1_26_1-mimxrt-MIMXRT1010_EVK-merged/network.pyi#L97

Edit : The class it in the stubs you submitted - just located in a different part of the file. There is some inconsistency with regards to ordering of inserts across host platforms with libcst - i should report that upstream

I think is is caused by the use of @overload in the reference stubs that push these methods and their containing class into the stubs ( similar for some other classes/methods.

Sanity checks:

• is it correct that the MIMXRT1010_EVK does not have any network interfaces ?
• did you by chance clean up the network.LAN() class.

if so this is a missing feature in stubber, but the logic to handle a conditional merge based on the target port is rather tricky, and I need to finish migrating of some annotations I initially made using @overload to the new but not well documented @mp_available(port=['.....') notation that should allow to write once - use selectively

For now we can manually clean up the extraneous classes in the network module (each tie the subs are regenerated) , or just leave as is.

[Josverl]

Could run help("modules") on each of the two boards and share the output of these ?
or add a PR to the stubber repo to add these outputs as .txt files to : https://github.com/Josverl/micropython-stubber/tree/main/data

stubber make-variants uses that output to build a list of all possible modules it tries to stub.

( current process is not self-serve friendly I realize now)

[Josverl]

Thanks Andrew,

I have published the current version to PyPI based on this branch.

                                                                Publish Results
┏━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ result            ┃ name                                    ┃ version      ┃ error ┃ path                                                    ┃
┡━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ Published to PyPi │ micropython-mimxrt-stubs                │ 1.26.1.post1 │ None  │ publish/micropython-v1_26_1-mimxrt-stubs                │
│ Published to PyPi │ micropython-mimxrt-mimxrt1010_evk-stubs │ 1.26.1.post1 │ None  │ publish/micropython-v1_26_1-mimxrt-mimxrt1010_evk-stubs │
│ Published to PyPi │ micropython-mimxrt-seeed_arch_mix-stubs │ 1.26.1.post1 │ None  │ publish/micropython-v1_26_1-mimxrt-seeed_arch_mix-stubs │
└───────────────────┴─────────────────────────────────────────┴──────────────┴───────┴─────────────────────────────────────────────────────────┘

there are a few things that I noticed while reviewing that require additional thinking and some changed to stubber.
I plan to merge this with likely some additional small changes.

I'm quite open to need a few .post versions with a new port or module, and never had complaints :-)