In the course of the evolution of industrial IoT, we’re seeing greater preference for a single SoC that performs more functions, rather than using multiple discrete devices. This is because a single SoC offers multiple benefits including a smaller bill of materials, less design risk, a smaller footprint. Let’s take the example of a Wi-Fi MCU. It supports a diverse array of applications by integrating Wi-Fi connectivity with a processor and the GPIO. There are several factors to consider before specifying a particular Wi-Fi MCU. Before making a choice, it’s important to understand the different options.
While there are low-cost Wi-Fi connectivity options available in the market, they often compromise on the number of peripherals that they offer. This makes the choice difficult since robust Wi-Fi connectivity and high-performance MCU functionalities are both essential parameters and influence project design speed as well as effectiveness.
Given that the MCU lies at the core of the Wi-Fi MCU, it is important to zero down on the right choice start of the project to avoid unnecessary rework with regards to software redesign and changing the configuration midway.
The Role of Analog-to-Digital Conversion (ADC)
Despite it being the first processing component in the signal chain after the analog input, most people tend to overlook the importance of Analog-to-digital conversion when specifying a Wi-Fi MCU. Since its performance influences the functioning of the entire system, understanding key metrics of the ADC is key.
While designers often focus on the ADC’s number of bits, the effective number of bits (ENOB) available to perform the conversion is a more important metric. This is because, in practice, the actual number of bits is lower than the datasheet specification, sometimes substantially. The closer the match between the ENOB and datasheet specifications, the better. A lower number of bits available to perform the conversion, translates into lesser precision in how the SoC represents the input signal. Also, like all electronic devices, ADCs can contribute errors arising from quantization and timing, as well as variations in offset, gain, and linearity. ADCs are also notoriously sensitive temperature swings, which are commonplace in industrial IoT operating environments (See Figure 1). Gathering details around the ENOB, performance over temperature, linearity, and accuracy from Wi-Fi MCU manufacturers, if possible, is an important step.
Support for Peripherals
Often, the number of interface standards that a Wi-Fi MCU supports can prove to be inadequate, especially when engineers try to use one Wi-Fi MCU different designs.
This issue is more pronounced in the case of IoT systems since they involve a wide range of machines and controllers built at different times by a variety of manufacturers. This issue can get worse as the system grow and more interfaces are added.
In case the SoC has GPIO to spare, there is the option of adding more relays, switches, and other components that can be controlled with little or no pin sharing. To ensure that virtually every scenario can be accommodated now and in the foreseeable future, it is recommended that the device must be equipped to supported interfaces such as Ethernet MAC, USB, CAN, CAN-FD, SPI, I2C, SQI, UART, and JTAG (and potentially touch sending and display support).
Security Begins Inside
While security is essential for every IoT application, it is doubly critical in industrial scenarios. This is because any threat that makes its way into an industrial IoT network can potentially travel through an entire facility and even an entire company. Therefore, ensuring that first level of required security is within the MCU’s integrated crypto engine is absolutely crucial. Here, encryption and authentication can be performed either sequentially or in parallel. AES encrypt in ciphers can have key sizes up to 256 bits, DES and TDES. The authentication should include SHA-1 and SHA-256, and MD-5.
One of the most challenging tasks for designers is to provision their product for a cloud service. This is because each cloud service provider has its own certification and keys. Provisioning for them requires considerable knowledge about crypto. Fortunately, manufacturers such as Microchip Technology can help simplify this process, enabling enormous savings in time and money. This allows security and provisioning requirements are met with a proven and verifiable approach and with minimal confusion, while shaving off weeks or more from the design process. Most Wi-Fi MCUs store credentials in flash memory where the data is accessible and vulnerable to software and physical attack. Storing this information in a hard-coded security element ensures highest security because the data inside it cannot be read from any external software. A great example is Microchip’s WFI32 Wi-Fi MCU (Figure 2), which employs this approach in the company’s Trust&GO platform. It allows forsecure provisioning of its MCUs to connect to AWS IoT, Google Cloud, Microsoft Azure, and third-party TLS networks.
In pre-provisioned, preconfigured, or custom secure elements, credentials are generated inside the device’s Hardware Secure Modules (HSMs) during manufacture, thus isolating them from exposure during and after production. The Trust&Go platform can be used with an inexpensive Microchip development kit that provides designers with a design suite with tutorials and code examples to create the required manifest file. The design can be sent to production once the working of the C code for the secure element in the application is confirmed.
The latest Wi-Fi security certified by the Wi-Fi Alliance is another security consideration. In latest version, WPA3 that builds on its predecessor WPA2, there are added features that simplify Wi-Fi security, enable more robust authentication, deliver increased cryptographic strength, and maintain network resiliency. All new devices are required to be WPA3-certified in order to use the Wi-Fi Alliance logo. Therefore, every Wi-Fi chip and Wi-Fi MCU needs to be certified for utmost security. So, ensuring that your candidate Wi-Fi MCU is WPA3 certified is an important step.
Ensuring Interoperability
Factors such as a mismatch of RF or software can hinder a Wi-Fi MCU’s ability to communicate with some access points in the market. Failure to connect to popular access points could damage a company’s reputation. While ensuring interoperability of a Wi-Fi MCU with every access point (AP) on the planet is practically impossible, interoperability testing with the most popular AP’s on the market is important. Getting information either from the manufacturers’ Web sites or by explicitly asking for it is an important part of the decision-making process.
You’ll Need Help
Design support in the form of a comprehensive integrated development environment (IDE) platform is the last piece of the puzzle. Ideally, manufacturers should provide a comprehensive IDE Figure 3 that lists every analog and digital function performed by the Wi-Fi MCU as well as the role of external components in implementations for specific applications. In addition, it should include ways to visualize the impact of design changes on overall performance and the ability to evaluate the design’s RF performance as well as regulatory compliance
Without this, designers are left to improvise with sub-optimal resources based on online research. For example, some Wi-Fi MCU manufacturers stop at providing basic details about the product and instructions for prototyping rather than supporting with information required to move it from this stage to production. While some basic tools are free, others such as evaluation boards designed to serve the manufacturer’s Wi-Fi MCU family, are available at a modest cost.
Summary
As the proliferation of IoT devices moves more processing power to the edge rather being restricted to cloud-based data centers, the ability to integrate a greater number functions in the least amount of space and components, become important. The Wi-Fi MCU plays an important role in enabling this because it integrates multiple functions in a single device eliminating the need for function-specific discrete components. Integrating these devices into an embedded IoT subsystem can be fairly simple; although subject to the availability of adequate resources such as a high level of security. In addition, a straightforward means of provisioning based on the specifications of cloud service providers as well as comprehensive IDE that leads the designer from the prototype to production are important.
