It seems updating the submodule itself is causing problems on mimxrt ports. I guess either we need to fix the port using new SDK or find another way of adding the new drivers.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:  -120 -0.033% TEENSY40
        rp2:    +0 +0.000% RPI_PICO
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

There is an open PR #11516 to add the mcux library as submodule instead of the library of Hatach. I tried this PR and the mimxrt port builds well with it. Only that the mcux lib is huge, and it may have been updated since then.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.39%. Comparing base (77f08b7) to head (3171c92).

@@           Coverage Diff           @@
##           master   #13429   +/-   ##
=======================================
  Coverage   98.39%   98.39%           
=======================================
  Files         161      161           
  Lines       21156    21156           
=======================================
  Hits        20816    20816           
  Misses        340      340           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

When I include your submodule I get the error message at the build as well. So there is a missing conditional compile in machine_rtc.c, which is required with the new lib. That came with lib v2.11, but MicroPython uses 2.10 atm.

Thanks @nxp-yilin for the contribution!

For my own education, is there any possibility that this could be combined with the mimxrt port? (Given that both ports use the nxp_driver submodule).

Taking on a new port is a big undertaking for the MicroPython project. The PR specifically mentions the MCXN947, but will this port work (without too much additional effort) on other chips in the MCX series (e.g. N94x, N54x)? What's the availability of these chips, are there dev boards and other products available? (We will need to obtain some for testing)

That said, this does look like a very well done port, thank you for making it so consistent with the other ports.

is there any possibility that this could be combined with the mimxrt port

At first glance the answer is no. The source structure is completely different. For instance it adds a drv_xxx.c layer between the machine_xxx.c files and the mcux library. Some modules like PWM, I2S, networking are still t.b.d.

Besides that, adding that as a separate port will require updating lib/nxp-driver to v2.11 at least. I prepared it, but it not done yet since no one missed it. And there is PR #11516 to used the official NXP library instead of the clone hosted by Hatach in the tinyusb environment.

is there any possibility that this could be combined with the mimxrt port

At first glance the answer is no. The source structure is completely different. For instance it adds a drv_xxx.c layer between the machine_xxx.c files and the mcux library. Some modules like PWM, I2S, networking are still t.b.d.

The MCX series uses LPC-style pin naming as well as different PORT/Pin structures than i.MXRT's IOMUXC, this requires different make-pins scripts and object structs, so the thought was ditched some while ago.
Some peripherals are not fully compatible between these series, such as CTimer and ADC etc., and there would be too much macros controlling which peripherals are get used. That drv_ layer was initially added to move these HW related part out of machine class code, however since there is only one MCX part for now so these files are mostly wrappers for MCXN94x/N54x. The missing drivers could be added once the port layout and submodule selection are confirmed.

Besides that, adding that as a separate port will require updating lib/nxp-driver to v2.11 at least. I prepared it, but it not done yet since no one missed it. And there is PR #11516 to used the official NXP library instead of the clone hosted by Hatach in the tinyusb environment.

That repository contains way more parts than MicroPython project currently supports, however it seems there's approach of selectively initializing certain submodules being used by adding a submodule target, e.g. picosdk only for rp2 port. If this approach is preferred then we can switch to it, and the current mimxrt port can also following the latest mcux-sdk by taking the changes from #11516 or continuing using the current nxp_driver as transitional stage.

Thanks @jimmo , here's some answers regarding the previous questions:

For my own education, is there any possibility that this could be combined with the mimxrt port? (Given that both ports use the nxp_driver submodule).

This is explained in this comment. It's possible but will add a lot of confusing macro to control which peripheral we are using.

Taking on a new port is a big undertaking for the MicroPython project. The PR specifically mentions the MCXN947, but will this port work (without too much additional effort) on other chips in the MCX series (e.g. N94x, N54x)? What's the availability of these chips, are there dev boards and other products available? (We will need to obtain some for testing)

Generally, this port is for the 'MCXNx4x' series with 4 sub variants:

• MCXN947
• MCXN946
• MCXN547
• MCXN546

However the MCXN947 will be the MCU for official boards (FRDM_MCXN947, MCXN947EVK), and there's currently no official boards for the N5 series. So technically this port also works for other variants mentioned above but for now only MCXN947 boards are available to use with this port.

As for other MCX series, such as A series, there's some basic support in this port for future device features, so they will also supported by this port.

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

Brief changelog since the last rebase:

• Updated STATIC macro to keyword static
• Another 2 drivers (PWM and SPI) are added.
• UART drivers (machine_uart) now use receiver interrupts and ringbuffer

There's a separate commit (3171c92) to address the build issues on mimxrt port due to the nxp_driver submodule update, please advise if it's more suitable in a separate PR.

As this PR has been hanging around for a some time, I'd like to know whether there's anything we can do to proceed with the next steps, or whether there's any concern which needs to be solved first.

For previous discussions on the SDK submodule dependency, we have the following options available:

• Continue using Hatach's cut-down version
• Bring the mcux-sdk submodule in for mcx port, while eventually migrate mimxrt port to this.

Please kindly advise the best approach so the code can be updated accordingly.

About the SDK: Relying on Hatach's version may not be the best option. There is a PR #11516 dangling since a while for switching to the MCUX library as submodule. I tested that with the mimxrt port and it looked doable. Only the size of the SDK is an obstacle. And naturally the MicroPython project would NOT follow each and every update of the SDK. That's too much ongoing test effort.

About the SDK: Relying on Hatach's version may not be the best option. There is a PR #11516 dangling since a while for switching to the MCUX library as submodule. I tested that with the mimxrt port and it looked doable. Only the size of the SDK is an obstacle. And naturally the MicroPython project would NOT follow each and every update of the SDK. That's too much ongoing test effort.

Thanks Robert, I personally also prefer using the mcux-sdk repo. I'll try bumping the version of that submodule to somewhere contains the latest MCX parts on that PR and see whether we can make this work.

I tested this and it seems to work fine, good job! However, I wasn't sure how to deploy the firmware, I eventually just used jlink, so you may want to add deploy instructions to boards/<board>/deploy.md (and possibly board.json files too).