As industrial IoT (IIoT) evolves, the trend is toward performing more functions in a single system-on-chip (SoC) rather than in multiple discrete devices because the result is a smaller bill of materials, less design risk, and a smaller footprint, among other benefits. An excellent example is the Wi-Fi microcontroller (MCU) that integrates Wi-Fi connectivity with a processor and the GPIO required to accommodate the needs of a diverse array of applications. There are multiple factors to consider when specifying a Wi-Fi MCU and to make a prudent choice it’s important to understand them.
Low-cost Wi-Fi connectivity options exist in the market today, but often they make sacrifices with regard to their number of peripherals and overall performance. This means that choosing the best Wi-Fi MCU is challenging and risky because a Wi-Fi-enabled MCU not only must have robust Wi-Fi connectivity but also high-performance MCU functionalities. Missing either or both will result in a delay or even failure of the design project.
As a core of the system, the MCU is the most critical portion of the Wi-Fi-enabled device, so it is necessary to examine its performance at the start of the project. Changing the device later generally requires redesigning all the software and the configuration of the accompanying circuit.
Don’t forget the ADC
Analog-to-digital conversion is one of the most overlooked functions when specifying a Wi-Fi MCU, even though it is the first processing component in the signal chain after the analog input. This means that its performance impacts the entire system, so it is important to understand the key metrics of the analog-to-digital converter (ADC) and how the Wi-Fi MCU manufacturer should address them.
One of the first specifications that designers focus on is the ADC’s number of bits. This can be confusing because in practice the actual number of bits will be lower than the datasheet specification, sometimes substantially. What’s more important is the effective number of bits (ENOB) the ADC has available to perform the conversion. This will invariably be lower than the datasheet specification but the closer the ENOB and datasheet specifications match is very important because this varies considerably among ADCs. The fewer the bits available to perform the conversion, the less precisely the SoC will represent the input signal.
In addition, like all electronic devices, ADCs “contribute” something to the signal that negatively affects their capabilities, including errors such as from quantization and timing, as well as variations in offset, gain, and linearity. ADCs are also notorious for their sensitivity to wide temperature swings that are common in many IIoT operating environments (See Fig. 1a & 1b). The Wi-Fi MCU manufacturer can mitigate this, so it is important to contact the manufacturers to determine the device’s ENOB, performance over temperature, linearity, and accuracy. If this information cannot be provided, move on the next candidate for the project.
Fig. 1a & 1b: Low-grade ADCs have poor accuracy and linearity and are sensitive to environment and temperature. (Image: Microchip Technology)
Peripheral support
All Wi-Fi MCUs have support for at least a few interface standards, so it’s easy to assume they’ll be enough. Engineers often come to regret this assumption when they attempt to use the same Wi-Fi MCU in another design. This is increasingly common when building or modifying IIoT systems because most production facilities have a wide range of machines and controllers built at different times by a variety of manufacturers.
And as the system grows, it will likely add even more interfaces, and there may come a time when support for features such as touch sensing and LCD support will be required. If the SoC has GPIO to spare, more relays, switches, and other components can be controlled with little or no pin sharing. For this reason, the device’s supported interfaces should include Ethernet MAC, USB, CAN, CAN-FD, SPI, I2C, SQI, UART, and JTAG (and potentially touch sending and display support) to ensure virtually every scenario can be accommodated now and in the foreseeable future.
Security begins inside
Security is essential for every IoT application, but industrial scenarios are mission-critical. Once a threat makes its way into an IIoT network it can then move through an entire facility and possibly an entire company. The first level of required security is within the MCU’s integrated crypto engine, where encryption and authentication are performed either sequentially or in parallel. Ciphers should include AES encryption with key sizes up to 256 bits, DES and Triple DES, and authentication should include SHA-1, SHA-256, and MD-5.
One of the most challenging tasks for designers is provisioning their products for a cloud service. Each cloud service provider has its own certification and keys, so provisioning the device becomes complex, requiring considerable knowledge about crypto.
Fortunately, some manufacturers including Microchip Technology make this process simple, saving enormous amounts of time and money. It is important to note that most Wi-Fi MCUs store credentials in flash memory where the data is accessible and vulnerable to software and physical attack. The highest security is attained by storing this information in a hard-coded security element because the data inside cannot be read from any external software. For example, Microchip’s Wi-Fi MCUs such as the WFI32 (See Fig. 2) employ this approach in the company’s Trust&GO platform for securely provisioning its MCUs for connection to AWS IoT, Google Cloud, Microsoft Azure, and third-party TLS networks.
The reduction in time and confusion resulting from the approach cannot be overstated. Weeks or more can be shaved from the design process while ensuring that all security and provisioning requirements are met with a proven and verifiable approach.
Fig. 2: The WFI32 Wi-Fi module isolates credentials by storing them in hardware, making them virtually invulnerable to hacking. (Image: Microchip Technology)
Pre-provisioned, preconfigured, or custom secure elements store credentials generated inside the device’s Hardware Secure Modules (HSMs) when it is manufactured, isolating them from exposure during and after production. The Trust&Go platform requires only an inexpensive Microchip development kit in which the designer works within the included design suite using tutorials and code examples to create the required manifest file. Once the C code for the secure element is working in the application, the design can be sent to production.
The other form of required security is the latest Wi-Fi security certified by the Wi-Fi Alliance. The latest version is WPA3 that builds on its predecessor WPA2, but adds features to simplify Wi-Fi security. It also enables more robust authentication, delivers increased cryptographic strength, and maintains network resiliency.
All new devices must be WPA3-certified in order to use the Wi-Fi Alliance logo, so every Wi-Fi chip and Wi-Fi MCU should be certified for the utmost security. Nevertheless, check to be sure the Wi-Fi MCU is WPA3 certified.
Ensuring interoperability
It is always possible that a Wi-Fi MCU will not be able to communicate with some access points in the market because of a mismatch of RF, software, and other factors. Failing to connect to popular access points could damage a company’s reputation. While it is impossible to guarantee that a Wi-Fi MCU will work with every access point (AP) on the planet, the problem can be minimized by ensuring that the Wi-Fi MCU has passed interoperability testing with the most popular APs on the market. This information can be found on manufacturers’ websites. If it is not readily available, call the manufacturer and ask for it, and if that fails choose another vendor.
You’ll need help
Last but surely not least is the need for design support. Without a comprehensive integrated development environment (IDE) platform, the designer is left to cobble together resources from the web that may or may not be useful, simple, or reliable. For example, a few Wi-Fi MCU manufacturers provide basic details about the product and instructions for prototyping but stop there rather than including the information required to move the design into production.
The manufacturer should provide a comprehensive IDE (See Fig. 3) that includes every analog and digital function performed by the Wi-Fi MCU and all the external components required for implementation in specific applications. The IDE platform also needs to provide a means for visualizing 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.
Fig. 3: An integrated development reduces risk by providing the designer with debugging and other tools from the prototype stage through the finished product. (Image: Microchip Technology)
Summary
The trend in IoT is toward moving more processing power to the edge of the network rather than solely in cloud-based data centers. To achieve this, it is necessary to integrate as many functions as possible in the least amount of space and components. The Wi-Fi MCU is one of many SoCs that go a long way to accomplishing this by integrating multiple functions in a single device rather than in function-specific discrete components.
Integrating these devices into an embedded IoT subsystem can be relatively simple, assuming adequate resources are available from the Wi-Fi MCU manufacturer. This includes a high level of security, a straightforward means of provisioning it to accommodate the needs of cloud service providers, and a comprehensive IDE that leads the designer from the prototype stage to production.
About the author
Alex Li is product line manager at Microchip Technology, responsible for technical marketing and global growth in Wi-Fi products. During his career in the semiconductor industry, Mr. Li has held technical engineering and marketing roles in the U.S. and Singapore. Prior to Microchip, he worked in Semtech Corporation’s Product Line Marketing group, Consumer and Sensing division. Earlier, Mr. Li was senior application engineer at Arrow Electronics, serving a customer base in the Asia Pacific region. Prior to Arrow, he was a senior lead product application engineer at NXP Semiconductors based in Singapore and a member of the global sales and marketing team that provided business development strategies for NXP’s Asia Pacific region. Mr. Li holds a Bachelor of Science degree in electronics and computing engineering from the National University of Singapore. He holds a Master of Business Administration (MBA) from the Washington University Olin Business School in St. Louis, Missouri.
Advertisement
Learn more about Microchip Technology
