espflash: Add binary packages with NINA and esp_hosted firmware.

[robert-hh]

• NINA_FW_v1.5.0_W102.bin for the u.blox W102 module or any other generic ESP32 device.
• NINA_FW_v1.5.0_Airlift.bin for Adafruit Airlift modules.

The two binaries only differ in which pin is used for the MOSI signals. The u.blox module uses Pin 12, the Adafruit modules use Pin 14. A generic ESP32 can be used with either firmware, given that MOSI is connected accordingly.

[andrewleech]

I haven't quite kept up with Nina support in micropython; I presume this allows use of an esp32 as an external radio to provide network access on an otherwise non-connected micropython part?
Is Bluetooth supported as well (yet)?

[robert-hh]

I presume this allows use of an esp32 as an external radio to provide network access on an otherwise non-connected micropython part?

Yes & yes. That is the intention. You can use generic ESP32WROOM based hardware or modules like u.blox W102 and Adafruit Airlift. But the MicroPython build must have the drivers included, which by default is not the case. The basic WLAN driver is 14 for the code and 6k for frozen utility scripts. Bluetooth including nimBLE is ~80k, mbedts is ~100k.
In the next few moments I'll send a PR for the SAMD port, tested with a few SAMD boards. Boards with a SAMD51x19 MCU hav just basic WiFI, the SAMD51x20 MCUs have SSL as well. That can be changed if the PR for external Flash support is merged.

I tested that approach already with two MIMXRT boards (1010 and 1015) which otherwise have not network support. But other port can be extended as well.
Bluetooth is on the road map as well. It builds and can be started. Only I have to do more testing.

[dpgeorge]

Is it possible to remove the v1.5.0 firmware now that the v2 exists?

Also, is it worth adding (brief) instructions on how to build these binaries, so that someone else can update them in the future if needed?

[robert-hh]

Sure. V1.5 can be removed, and I can write instructions. I can add a README into this espflash directory.

[robert-hh]

The build instructions are added. I had a little problem compiling and building the nina-fw with my current set-up for esp-idf. Maybe there are too many versions in that copy. So I made a fresh set-up of the esp-idf following the README.md file in the nina-fw repository. That one worked.

[robert-hh]

I just noticed that esp_hosted has changed a lot since this PR was made. Thus the build instructions do not match any more. I have to re-check the instructions and eventually build & test the esp_hosted firmware.

[robert-hh]

@dpgeorge The instructions are updated. I verified, that the firmware can be built and that they work. The preference is still to use the supplied binary blobs.

[iabdalkader]

I'm curious, does this new firmware NINA_FW_V2.0.0_W102.bin actually work on Nano RP2040 or should work? If it hasn't been tested, maybe keep 1.5?

Anyway, if you're still going to remove the 1.5.0 binary, then please update the path and checksum in the example here:

micropython-lib/micropython/espflash/example.py

Line 10 in 7473d1d

md5sum = b"9a6cf1257769c9f1af08452558e4d60e"

[robert-hh]

The V2.0.0 firmware worked on the boards where I tested it. I did not test it with the RP2040 Nano connect. I forgot that I have one. But I do not object to keeping v1.5.0.

[robert-hh]

I'm curious, does this new firmware NINA_FW_V2.0.0_W102.bin actually work on Nano RP2040

I tested it with a Nano RP2040 and it works. iperf3 TCP is actually almost twice as fast than with v1.5.0 - but still slow at a rate of about 1MBit/s.

The esp-hosted firmware does not seem to work. The NINA.-W102 module has 2MB flash, and the configuration is for a 4MB flash, including a second firmware partition for OTA. That would not fit into 2MB.