Tips for Choosing the Best Wi-Fi® MCU

While it might not get lots of media attention, the Wi-Fi^® microcontroller (MCU) plays a big role in moving the Internet of Things (IoT) forward by combining a processor, Wi-Fi transceiver, I/O, and other functions in a single system on chip (SoC). And even though they may appear to be comparatively simple devices, there is a lot going on under the hood, as they perform not just Wi-Fi connectivity but surprising levels of MCU performance, extensive security measures, and considerable amounts of IO. So, you need to consider them all to minimize risk. If you don’t, changing the device later requires redesigning all the software and the configuration of the accompanying circuit. 

As a core of the system, the MCU is the most critical portion of the Wi-Fi MCU, and these processors range from 8 to 32 bits. Choosing between them should be based on what the sensor itself is required to do. For example, if the sensor needs to infrequently transmit a minimal amount of data, an 8-bit device is fine, but if it will be running sophisticated algorithms for machine learning, a 32-bit MCU is a better choice. Its greater processing capacity will perform functions faster so it can return to sleep mode more often to minimize power consumption. In addition, its larger flash and RAM let you implement the entire networking stack and application code on the Wi-Fi MCU, eliminating the need for an external processor.

As more and more IoT networks are being deployed throughout the world, security is quickly rising to the top of challenges for IoT system designers. According to one report, it takes only about five minutes for an IoT device to be attacked once it’s connected to the Internet, and the number and types of threats are increasing yearly. While there are many ways hackers can enter these networks, edge devices (i.e., sensors) are prime targets because there are so many of them in Industrial Internet of Things (IIoT) networks, for example.

Hackers can find a way to obtain confidential data throughout the entire IoT network, and that can threaten an entire facility and potentially, an entire company. Therefore IOT engineers have to encrypt the data transmitted in the network with keys  and they only allow trusted devices with valid certification to join the network. For example, much of the data produced by sensors will ultimately end in a cloud data center, and each cloud service provider has its own certification and keys. Provisioning a trust device is a complex task that requires a lot of knowledge about cryptography. Fortunately, manufacturers such as Microchip make the process simple, eliminating this requirement and ensuring that all security and provisioning requirements are met with a proven and verifiable approach.

Although many MCUs store credentials in flash memory, the only truly safe way to store them is in a hard-coded security element that isolated from every other part of the device, and beyond. In contrast, when stored in flash memory the data is accessible and vulnerable to software and physical attack.

Microchip’s Wi-Fi MCUs, such as the WFI32, stored credentials using the company’s Trust&GO platform for securely provisioning its MCUs for AWS IoT, Google Cloud, Microsoft Azure, and third-party TLS networks. The credentials are generated inside the MCU’s Hardware Secure Modules (HSMs) when it is manufactured. The Trust&Go platform requires only an inexpensive Microchip development kit along with an accompanying design suite.

It’s also important to remember that a Wi-Fi MCU must be able to communicate with the widest array of Wi-Fi access points on the market. The manufacturer should state that, at the very least, its device has passed interoperability testing with them. This information is generally available from the manufacturer’s website, such as this one from Microchip. The inability to support all popular access points could damage your company’s reputation.

If you’re like many designers, you might be willing to overlook the importance of supporting a wide variety of interface standards, settling instead for a Wi-Fi MCU that supports just a few, assuming they’ll be more than adequate. This can often prove shortsighted because if you decide to use this Wi-Fi MCU in additional designs or if you’re modifying an existing IoT system in the future there’s a good chance you’ll encounter interfaces you didn’t expect, such as support for touch sensing. To be safe, make sure the Wi-Fi MCU you choose supports Ethernet MAC, USB, CAN, CAN-FD, SPI, I2C, SQI, UART, and JTAG (and ideally, touch sensing) that will ensure you can accommodate virtually any scenario you’re likely to encounter in the future.

Finally, you’re going to need a comprehensive Integrated Development Environment (IDE) platform, without which you’ll be left to cobble together resources from the Web that may or may not be helpful, simple, or reliable. The Wi-Fi MCU manufacturer your considering should provide more than simply details about the product and instructions that stop at the prototyping stage. The IDE should include every analog and digital function performed by the Wi-Fi MCU and all the external components required for implementation in specific applications. It should also offer a way to visualize how changes to the design are reflected in overall performance and the ability to evaluate the design’s RF performance as well as regulatory compliance. Some of the basic tools are free while others are available at a modest cost, including evaluation boards designed to serve the manufacturer’s Wi-Fi MCU family.

There are other factors to consider as well, such as the importance of the analog-to-digital converter, the details of which are a bit too long to discuss in this blog. However, I discuss them in detail in an article you can find here.

Check WFI32E01PC for more information.