I want to be able to produce a product that provides as nice an end user experience as possible. That means, want to be able to deliver a device to someone who isn't technically expert and have them be able to get the thing up and running. Additionally, I want a hardware product that produces a reliable, quality result. Sometimes a hardware vendor suggests support for a feature when the reality is a bit different, and this can result in undesirable or unreliable behavior, and we'll examine whether there are situations where that happens.

This primarily means getting the thing onto a wireless network and providing any settings required for the device to operate. While there are numerous ways to do this, I think the nicest uses what's called a "captive portal". An unconfigured device (or one where the configuration is no longer able to connect to its specified network) creates a wireless network that a user can connect to with a mobile phone or laptop, after which a configuration portal automatically appears. The user can then specify WiFi settings or other parameters. Additionally, if the WiFi information changes, or if the user holds the reset button down, the device reverts to factory defaults and enters configuration mode again. A popular library, WiFiManager, and its variants is the mechanism I've chosen to use for this purpose.

Additionally, I think it's important to explore the nature and quality of the peripherals provided by the MCU. 

Finally, I'll consider the quality and reliability of the overall software ecosystem. This includes not just the "core" software shipped, but also the health of the third party software community.

Here are some of the aspects of the project that I tested on each platform:

• WiFi configuration portal
• I2C, GPIO and high frequency (25kHz) PWM
• NTP client support
• UDP Broadcast

ESP8266

This group of products (usually in the form of a module present on a larger board) along with it's newer, bigger brothers in the ESP32 family is ubiquitous. Most of my experience involves various members of the NodeMCU family, though I have generally not used the NodeMCU Lua based firmware. There's a vibrant community supporting a wide variety of firmware platforms, and these chips appear in a lot of Chinese WiFi enabled devices like smart bulbs (see Tasmota), so they're kind of a hacker's paradise. If you stay aware of what they're capable of (or not) and keep your requirements on the lower end of the performance spectrum, they're a great option. I keep a half dozen of these guys in the supply box.

Pros:

• Price: Very, very low. Often cheaper than the cost of components alone
• Many vendors make standard (or interesting) variants; high quality boards available from AdaFruit, Sparkfun and others
• Third party software ecosystem is vibrant, though many authors have moved on to ESP32, leaving maintenance support wanting
• WiFiManager (in a ESP8266 supported version) provides a professional configuration experience and relatively clean code. [1]

Neutral:

• No onboard EEPROM but a library for Arduino can use a portion of flash as EEPROM, and this works quite nicely.
• Module available in multiple variants with different amounts of flash, so check to make sure the size is what you expect or need.
• Single core CPU handles WiFi and user firmware, so there are gotchas with respect to interrupts. Generally faster than AVR but less than more expensive options.
• Modules have relatively few GPIO lines, so not ideal for more involved projects.

Cons:

• Quality of cheapest boards suspect
• Peripherals are poor or left to software emulation (I2C, PWM, etc) despite indications otherwise. PWM at higher frequencies is CPU bound and subject to glitches and jitter. I2C is said to be available on any pins via software bit-bang, but in practice some pins aren't usable.
• Dependent on closed ESP SDK, and there are bugs to be aware of.
• Power utilization/management is not great, and options for waking from sleep are limited (ie, WDT). So, perhaps not the best option for battery based projects.
• Espressif is not what I'd consider top tier in terms of quality and support, so expect bugs and poorly documented behavior (or behavior described by third party observation rather than specification) at times.
• The development of tzapu/WiFiManager support for 826x modules has been somewhat unreliable lately, requiring the use of an older version. 

Interesting item to note: You can load what's called an "coprocessor firmware" [2,3] on these modules, and that can be used to interact with the radio via a "Hayes style" AT command set or via SPI. This allows you to use the module as a network co-processor to add WiFi capability to other microcontrollers. 

[1] https://hg.sr.ht/~hww3/esp8266_basic/browse

[2] https://github.com/JiriBilek/WiFiSpiESP

[3] https://learn.adafruit.com/adafruit-io-basics-airlift

ESP32

This family of products is similarly extensive, with a range of radio and CPU options existing under the ESP32 family name. There's a vibrant community supporting a wide variety of firmware platforms, and like the ESP8266, these chips appear in a lot of Chinese WiFi enabled devices like smart bulbs (see Tasmota). I keep a few of these on hand in various variants (including some that sport wired ethernet interfaces) for projects that require keeping cost reasonable but also need improved CPU or peripheral performance.

Pros:

• Many vendors make standard (or interesting) variants; high quality boards available from AdaFruit, Sparkfun, Olimex and others
• Third party software ecosystem is vibrant
• WiFiManager (in a ESP8266 supported version) provides a professional configuration experience
• WiFi + Bluetooth, some variants include 5Ghz radios.
• Better selection of peripherals compared to ESP8266.

Neutral:

• No onboard EEPROM but a library for Arduino can use a portion of flash as EEPROM, and this works quite nicely.
• Module available in multiple variants with different amounts of flash, so check to make sure the size is what you expect or need.
• Different variants have different CPU cores (Tensilica vs RISCV), so be aware of what that might mean for your project.
• Modules have relatively few GPIO lines, so not ideal for more involved projects.

Cons:

• Quality of cheapest boards suspect
• Not expensive, but compared to the "throw away" cheapness of the no-name 8266, you do have to think a bit more about cost.
• Dependent on closed ESP SDK, and there are bugs to be aware of.
• Espressif is not what I'd consider top tier in terms of quality and support, so expect bugs and poorly documented behavior (or behavior described by third party observation rather than specification) at times. Somewhat better than the ESP8266 line in this regard.

SAMD21 + various WiFi Modules

The Atmel/Microchip SAMD21/51 family of MCU are used by a wide variety of development platforms, notably the Arduino Zero and MKR series boards, as well as a number of similar ecosystems from other vendors like Seeed and Adafruit.  The Atmel hardware includes some nice peripherals and Atmel (now Microchip) is a top tier vendor in terms of quality of documentation and support. The boards from the name brands are usually well made and have a variety of useful features (like lipo battery support).

The SAMD chips don't have communications radios, and thus use radio modules to provide WiFi support. I'll discuss the various options separately.

If you don't need WiFi and can work around the EEPROM situation if it's relevant, I really like this platform for lightweight needs.  Additionally, if you find an option with a good WiFi coprocessor, that could also work as a "house" hardware selection

Pros:

• Nice selection of peripherals in a small package
• Vibrant, well supported ecosystem
• Wide array of boards form a number of well respected vendors (Sparkfun, Adafruit, Seeed, etc)

Neutral:

• With such a wide variety of options, understanding which contains the features needed is key.
• More modest levels of performance (CPU + RAM) than some other options

Cons:

• No EEPROM, though Flash can be used using emulation. Major shortcoming is that the Arduino bootloader doesn't accommodate this usage, so firmware flashes overwrite stored settings and there seems little interest in addressing this. You could flash a different bootloader or use ISCP to program, but it seems like this should have easily been avoided before product launch.
• Because WiFi is implemented as an additional module, there are a wide range of options of varying cost, level of software integration and quality. If you like a "plug it in and go" type setup, the amount of responsibility this places on you may be offputting.

SAMD21 + W600 (Seeed)

(Appears to be deprecated as of summer 2022)

The W600 module comes from a Beijing based "Winner technologies", and on paper looks to be a good low cost alternative to the ESP8266 module. A particular firmware is loaded onto the module and a client communicates over UART with the main processor. The price was reasonable, at under $10 at the time of writing.

The board itself is nicely designed with a lipo charging circuit and a compact design. The real problem is that the client (and possibly the module firmware) appear to have been left in a state of half completion. No "self provisioning" software is available which is compatible with this module, and I'm not sure that enough lower level support is available to bridge that gap.

Certainly it would be theoretically possible to build the missing infrastructure, but if a vendor doesn’t seem to be interested in their own product, it is hard to want to throw in with them. As interested as I am in having multiple options for solving a problem, I think this particular option is best avoided.

SAMD21 + WINC1500 (Arduino MKR 1000)

(Appears to be deprecated as of summer 2022)

The ATWINC1500 family of WiFi modules comes to us from Atmel/Microchip. The whole of the firmware used on these modules appears to be closed. The last update for the WINC1500 was released in 2019.

As an official Arduino, the hardware seems nicely put together and packaged. It also has a lipo charging circuit and a number of nice features. The WiFi software interface is similar, yet different from other products in this vein, so code can't be simply reused without modifications. 

I was able to put together a project that included most of the self provisioning feature, though the part of the setup where the configuration interface appears automatically upon connection (the "captive" part of the captive portal) doesn't seem to exist. That said, if you punch in the address in your browser, it all works as expected from there.

The bigger problem, and one that makes this hard to recommend is that the DHCP support built into the module seems to not work correctly with dnsmasq, a dhcp server that's frequently built into home-grade wireless routers. The device would get a lease but would then lose it within a minute resulting in a loss of connectivity. Some investigation leads me to belive that dnsmasq is working as expected, but that there's some firmware bug in the ATWINC module preventing the lease from being accepted. I suppose if you only needed static addressing, this shortcoming could be avoided, but without any way to fix the problem, it's hard to recommend this solution.

Microchip appears to have newer members of the ATWINC family, but it's unclear whether they're worth looking into based on the firmware issues experienced in the 1500.

SAMD21 + Nina module (Arduino MKR 1010)

The ublox Nina module is used in a number of development boards, including the Arduino MKR 1010. This module is actually an ESP32 in a module designed by ublox, and Adafruit, in particular uses a variant of the Nina firmware in their "Airlift" modules. Ublox is a vendor with a pretty good reputation, and they make a variety of modules for GPS, WiFi and various radio communication methods.

This is a popular combination, and the hardware is well supported and with the exception of the binary blobs from Espressif, the firmware source is available. This module, however, is rather pricey and as of writing, hard to find. The MKR 1010 retails for between $30 and 40, making it a more expensive option. 

Raspberry Pi Pico W

A variety of boards are available with the RP2040[4] microcontroller. Several of these include one of the various other WiFi modules discussed above. The RP2040 is an interesting entry into the market place and has a number of compelling features that make it worth a look.

Pros:

• Very good value for the price: $6 with WiFi (BT may be coming later)
• Cypress, now Infineon module with WiFi and BT from a major vendor
• Growing third party ecosystem with current or pending support for a number of platforms
• Good peripheral support, including the unique PIO engines, which can be used to implement wire level protocol support without tying up the CPU

Neutral:

• Wireless support, in particular, is less mature, though we are only 2-3 months from the initial release of the product.
• Good datasheet and documentation, though Raspberry Pi foundation is relying on third parties to provide support beyond some basic SDKs.
• The WiFiManager_RP2040 library works but doesn't support the "captive" part of the configuration portal. Perhaps this could be fixed?
• The RP2040 processor is used in a number of products and flash is external by default, so make sure you are getting a board with the features you need.

Cons:

• No reset button. Seems like a cost cutting measure, but annoying nonetheless.
• Bluetooth functionality is not enabled (presumably due to certification issues specific to BT)
• The on-circuit WiFi antenna may be sub-par compared to the others I've tested. May need additional research.
• Early days as far as "plug and play" software support goes. The arduino-pico framework is making good progress, though, and platform.io support appears to be a short way off.
• A minor software problem is that by default, the lwIP stack is built with support for a very small number (4) of sockets, especially UDP. This means that by default, only 2 sockets are available, and if you use OTA, that uses them, leaving no sockets for use in user code. Figuring out the difficulty was an exercise in frustration. Building a core with increased capacity isn't difficult, but is extra work, and didn't work for me on MacOS. This could  probably be avoided by a change in the configuration used by arduino-pico.

[4] https://www.raspberrypi.com/documentation/microcontrollers/rp2040.html

Some final notes

Obviously these findings represent fact with a heavy dose of opinion, based on my personal experience. The values I've applied to various aspects might be completely different for you: my pros and cons are probably not the same as yours. Also, any hardware development project is going to run into lots of situations that will cause head scratching, so having good documentation as well as a supportive vendor and user community is important.

I find the use of network co-processors interesting, as it allows a lot of flexibility when designing a system, at the expense of slight complexity and additional cost. However, depending on the particular needs of a project, gains in peripheral support and potential energy savings could be decisive. Additionally, new designs coming from established names like Nordic Semiconductor could potentially break the headlock Espressif modules currently have for all but the lowest cost devices.