I think you may have some really outdated changes, I didn't look at the whole PR but note that mimxrt already has working WiFi and BLE support using nimble and cyw43, I added it myself some time ago, so some of your changes duplicate things (for example see mp_bluetooth_deinit() in main.c, and port files in Makefile etc..), also nimble.mk includes the paths you added. Like I said it's already working, you just need to add support for new NICs/drivers (Nina/esp_hosted).

Thanks for the hint and maybe it's the case. The history of this PR starts earlier than the inclusion of the cyw43 support. Since you looked at it already, can you be specific about the places were things are duplicated?

Edit: I see the duplicate of deinit. And I used already earlier the mpbthciport.c file introduced with the cyw43 support.
Edit2: I know the there is support for cyw43. Only the existing boards cannot use it. The added support for NINA or esp_hosted based devices allow users to add WiFi/BLE to other boards as well.

Since you looked at it already, can you be specific about the places were things are duplicated?

I left a quick review, anything removed I think is duplicated.

Edit2: I know the there is support for cyw43. Only the existing boards cannot use it. The added support for NINA or esp_hosted based devices allow users to add WiFi/BLE to other boards as well.

I understand, but what I meant is: there's already working support for nimble and LWIP, in that port, which means you only need to add support for Nina/Esp hosted.

Thanks for the review. I was a little bit overwhelmed by the fact that git managed to merge 3 branches with almost no conflict. But I did not check for duplicated. Still CI reports a build error: [proto_c cannot be found](make: protoc-c: Command not found). Sometimes it works.

Thanks for the review. I was a little bit overwhelmed by the fact that git managed to merge 3 branches

Yes it looked like a bad git merge. Anyway, I can take another look tomorrow.

Still CI reports a build error: [proto_c cannot be found](make: protoc-c: Command not found). Sometimes it works.

You must make submodules with the BOARD set, see ci_renesas_ra_board_build in tools/ci.sh

About Proto-c: It works locally. And when I do the make BOARD=xxx submodules and try to push it, there is no change to push.
Edit: I think I got it. Have to change ci.sh.

Code size report:

Reference:  lib/micropython-lib: Update submodule to latest. [2bd337e]
Comparison: mimxrt/wlan_pinout and mimxrt/Makefile: Implement review comments. [merge of 7d4177f]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt: +366112 +97.135% TEENSY40[incl +344(data) +44088(bss)]
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

function ci_mimxrt_build {
    make ${MAKEOPTS} -C mpy-cross
    make ${MAKEOPTS} -C ports/mimxrt BOARD=MIMXRT1020_EVK submodules
    make ${MAKEOPTS} -C ports/mimxrt BOARD=MIMXRT1020_EVK
    make ${MAKEOPTS} -C ports/mimxrt BOARD=TEENSY40 submodules
    make ${MAKEOPTS} -C ports/mimxrt BOARD=TEENSY40
}

I'm not sure why boards are built twice, but I think you need to add submodules to every build.

Oh okay first line checks out the submodules, in that case I'm not sure why it's failing.

Proto-c was not installed. See a few lines up. The error about proto-c is now gone, only I have to clean up the manifest.py files. But maybe not today anymore.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (2bd337e) to head (7d4177f).
⚠️ Report is 6 commits behind head on master.

@@           Coverage Diff           @@
##           master   #12937   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         171      171           
  Lines       22300    22300           
=======================================
  Hits        21939    21939           
  Misses        361      361           

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

Micropython esp-hosted works with the v1.0.0.0.0 driver. The module used for esphosted has to provide at least 4MB flash. Therefore it does not work with the uBlox NINA-W102 modules with 2MB flash per se. The esp-hosted configuration is for a 4MB flash, including a second firmware partition for OTA. That would not fit into 2MB.
I made a version with a single partition and for 2MB flash, which starts up and connects to the AP. Tested on a SAMD51. The connection is NOT stable, but that may be due to other problems. esp_hosted seems to consume a lot of execution time, so REPL is somewhat stuttering.

Micropython esp-hosted works with the v1.0.0.0.0 driver

Good to know! Thanks @robert-hh

@iabdalkader There is a startup problem with esp_hosted V1.0.0.0: After calling wlan.connect(), sometimes wlan.isconnected() never returns True. But the interface is working. I can "Ping" the board and can run iperf3 with both TCP and UDP connections. I do not see this behavior with V0.0.5. This is related to the esp_hosted firmware and happens with different ports.

Edit: The same happens if a static IP is set before calling wlan.conenct() with every port, even for esp_hosted v0.0.5. wlan.isconnected() never returns True, but the device IS connected.

@iabdalkader @dpgeorge After testing with esp_hosted v1.0.0.0 for a few days, I consider it as not ready for use, at least in the configuration I have determined. Besides the start-up problem noted above, it works reliably only with fast MCU's like Teensy 4.x, with slower ones and smaller RAM it locks up quite often, almost all the time when trying TCP transfer. UDP works mostly. So there is a problem in the interaction between esp module and MCU.
V0.0.5 works reliably on the tested ports, namely RP2, MIMXRT and SAMD. For the latter I have a branch, but will due to it's code size most likely not raise a PR for it.

Not 100% sure, but it might have something to do with the changes ESP made to the ABI/protocol after v0.0.5. We could probably support both firmwares via a config option. I'll see if we can allocate some time for this.

@iabdalkader Thanks. Attached are the sdkconfig files which I used for V1.x. The SPI Pin config is for Airlift boards. But that is easy changeable.
sdkconfig_V1_000.zip

@dpgeorge I'm closing this PR. After a bit of consideration, it looks more like a source of continuous irritation than a benefit. There is no board or an add-on, where it would work off-the-shelf. In any case, the WiFi module has to be updated first, which is not a very simple step. And for both the NINA and the esp_hosted firmware the firmware versions are old. Newer firmware versions are either not available or do not work properly. So we have two components - Micropython and the Wifi module firmware - which must be kept in sync, and that will probably fail sooner that later.

@iabdalkader It may still be interesting to tell, why the v1.0.0.0 version of esp_hosted behaves strange. There are a few boards which use esp_hosted of-the-shelf, and for these it may be interesting to have an upgrade path.

@robert-hh thanks for your persistence with this and your executive decision to stop working on it.

I agree that it's pretty hard to maintain drivers (both the host and controller drivers) for a WiFi coprocessor. The required bandwidth and low latency of WiFi, along with the complexity of the protocol, makes it pretty tricky to line up all the pieces. If it were a major feature for a commercial board (eg pyboard) then we could spend time on it. But having it as an optional bonus feature for mimxrt, no one has the time for that right now.

Eventually things might improve. Eg the ESP32-P4 needs the esp_hosted firmware, and a way to upgrade it, so we might have to revisit the upgrade process at the very least.

[Side note: this is why I like the cyw43xx, because its patch firmware is relatively small and stable, is included on the host side and downloaded each time it's powered on. That makes it much easier to use and more reliable.]

The esp_hosted firmware is currently used by two MP boards, the ESP32_P4 and the Arduino Nano 33 BLE. For that reason I left PR micropython/micropython-lib#642 open. There is OTA support for updating the esp_hosted firmware, but I did not try that.

B.t.w.: My P4 board complains that the esp_hosted firmware needs an upgrade, but works otherwise.

@iabdalkader It may still be interesting to tell, why the v1.0.0.0 version of esp_hosted behaves strange. There are a few boards which use esp_hosted of-the-shelf, and for these it may be interesting to have an upgrade path.

I will get around to working on this, maybe a few days next week. It's a work thing so will be on work hours.

I just found a different way to get a start point, which may be more recent and seems more straightforward.

1. set up esp-idf v5.5.1 and run export.sh
2. go to a directory of you choice and run:

idf.py create-project-from-example "espressif/esp_hosted^2.7.0:slave"
cd slave
idf.py set-target esp32  # or any other ESP32 device of your choice
idf.py menuconfig  # configure the interface, which is all now in example-configuration
idf.py build

I did not check yet whether it is all one needs, but it looks more consistent.
Edit: Already building using that path seems to be a rough ride.