An IoT router is needed to collect and transmit data to the clouds from various wired local buses (CAN, RS485, USB …) and wireless local networks (Bluetooth, LoRa …).
Using Azure RTOS to make your own router is quite simple. You just need to choose the right couple of ingredients: a Wi-Fi module and a versatile, fast, secure, cost-effective microcontroller with an open architecture.
Universal – because there is a desire to cover as many interfaces as possible.
Fast – because many interfaces require more performance at the same time
Protected – because communication channels must be encrypted on the go, the firmware must be protected from reading, files must also be encrypted and signed. Otherwise, you can not access the open Internet.
Economical – because sometimes you need to run on battery power.
Open – because otherwise I wouldn’t be able to write articles about it.
And I chose the platform Renesas Synergy™and in it the family S7G2, and specifically the R7FS7G27G2A01CBD chip. The platform is interesting because it has the most developed support package. Azure RTOS. Everything is there – BSP with API for any peripherals available on the chip, RTOS drivers for USB, SDIO, Ethernet, RTC, SDRAM, NAND, Crypto, etc. The ecosystem is so distinctive and unique that it is not part of the demo projects in the Azure RTOS repository. Those who are interested should look for all source codes and documentation on the Renesas website.
The R7FS7G27G2A01CBD microcontroller itself contains an ARM Cortex-M4 core with a frequency of up to 240 MHz. Package 224-LFBGA. There are enough pins to connect 16-bit SDRAM, and bring out a dozen more interfaces, including two SDIO for an SD card and for a Wi-Fi module. It was decided to connect the Wi-Fi module via the SDIO interface as the fastest. We leave the USB HS interface for connecting external devices, including a USB-Ethernet adapter.
I will not retell the specification for the microcontroller here, I will only note interesting points in the context of the router project, which experts can evaluate.
The main thing is that the documentation is almost completely open except for one peripheral module. it Secure Cryptographic Engine (SCE7). But it comes with a library with a good description of the API. The library is fast and reliable, tested in practice.
Availability on board the module Interrupt Controller Unit (ICU). Its unusual feature is that it multiplexes all DMA and interrupt signals onto a single event bus. And then these events are sent both to the NVIC of the core and to the DMA modules. This is very different from the architecture of most other microcontrollers, where the DMA and interrupt signals are strictly separated and one cannot be used instead of the other.
The next resulting feature is that the interrupt vectors do not have hard-coded interrupt lines from the periphery. Any event can be sent to any vector (and there are 96 of them in the chip), whether it is an interrupt (external or internal) or a DMA request.
Another interesting module Data Transfer Controller (DTC). By the principle of operation, it is almost similar to DMA, but it starts working on interrupt requests, and not on DMA requests. Those. peripherals working with DTC do not need to have a separate DMA call signal, interrupt signals are sufficient. The DTC module has access to the entire address space of the chip. However, the DTC module processes requests sequentially and inextricably, and not concurrently and in parallel, like DMA channels. As a result, DTC does not have a limit on the number of requests it can serve, but service speed drops due to waiting in the queue and depending on other requests. DTC is especially useful for servicing UART, I2C, SPI, SSI and other slow interfaces. This saves DMA channels for fast interfaces.
There is a protection of the firmware against reading with a mode when the microcontroller cannot be reset to the default state at all with erasing the entire Flash. There is also a module for cryptographic key wrapping, i.e. keys are not stored in pure form anywhere in memory.
I must say that Renesas appeared as a result of the merger of well-known companies Hitachi and Mitsubishi. They used to make very interesting microcontrollers. And Mitsubishi microcontrollers were the basis for running in the iconic RTOS uCOS-II.
Selecting a Wi-Fi module
Our router connects to the internet via Wi-Fi. Since field buses can have speeds up to tens of Mbps, the module must transmit at least the same speed over Wi-Fi. You can find drivers for the following Wi-Fi modules in the Azure RTOS and Renesas repositories:
SX-ULPGN based on Qualcomm QCA4010 chipset, 1×1 802.11 b/g/n. There is detailed manual how to run everything with Azure RTOS. The chip itself is fast, but the communication in the driver works via UART. It spoils everything. It is impossible to transfer data through the UART at the speed required by the router.
EMW3080, 1×1 802.11b/g/n. Communication is also via UART. Those. too slow.
GT-202 based on Qualcomm QCA4002 chipset, 1×1 802.11 b/g/n . Communication with the host is done via 10 MHz SPI. But this is still not enough.
As you can see, everything is not very suitable here. There are also third-party solutions potentially suitable for porting:
Modules on a chip ESP32-C5, 1×1 802.11 a/b/g/n up to 40 MHz band. There is a 5 GHz band, but with a band of only 20 MHz. There is also a standard way to exchange via UART, but there is also SDIO. Not bad overall, but ESP usually doesn’t have stack options for the host controller, ie. the need to program the modules themselves is added and this complicates development. The chip has only recently been announced, and may be difficult to acquire.
CC3135MOD on chip CC3135, 1×1 802.11a/b/g/n. Communication via SPI 20 MHz. Peak speed over TCP 13 Mbps. There is a 5 GHz band. But the speed of the interface with the host is still low. Great effort will be required to adapt the drivers simple link on Azure RTOS
ATWILC3000-MR110xA 1×1 IEEE 802.11 b/g/n. Exchange with the host skull SDIO. This is what you need. Peak speed over TCP 28 Mbps. There is a driver for FreeRTOS under the stack lwIP. In previous articles, I described how easy it is to port the lwIP API to Azure RTOS. This module could be accepted as a router candidate if there were no other options.
Decided to choose a Wi-Fi module from the ecosystem WICED. Everything is changing fast and now the ecosystem is called AIROC™. This ecosystem is now owned by Infineon, previously owned by Cypress Semiconductor, and even earlier, the chips in this ecosystem were developed by Broadcom Inc. Therefore, the same chips of this category can be found under different names and with a long history.
I stayed on the WICED platform, or rather I made my own branch, because I didn’t want to get vendor lock-in. It was also interesting that WICED was based on ThreadX RTOS, and this is the core of Azure RTOS. Infineon, after the acquisition of Cypress, switched to support Amazon FreeRTOS. This, of course, is not a strong obstacle to integration into Azure, since Azure fully emulates FreeRTOS services, but once again proves how dangerous it is to trust vendors.
From the whole variety of Wi-Fi modules based on Infineon chips, not all of them can be chosen for our router. Not everyone has open source drivers for RTOS. The most interesting chip seemed CYW43340. And a suitable module based on it was found from a little-known company Inventek Systems. This is a module ISM43340-L77.
WiFi module ISM43340-L77
The module communicates with the host using the SDIO interface, frequency 25 MHz. Those. in the limit, the transfer rate can reach 100 Mbps. The module Operates in two bands: 2.4 GHz and 5 GHz. Support for two antennas, with a choice of the best one. The bandwidth in both bands can reach 40 MHz.
This promises an over-the-air transmission speed of 150 Mbps. The module also contains Bluetooth v4.0 operating through a separate UART interface at speeds up to 4 Mbps. Some versions of the module also support the NFC interface. But in our case it is not used. When enabled, the module requires firmware to be loaded. This is done through the same SDIO interface and lasts less than 0.5 sec. The firmware is stored in the Flash memory of the microcontroller and takes about 370 KB. The API provided by WICED for these modules is quite extensive. You can organize both an access point and a client station, and both options at the same time. There is a wide choice of types of communication channel protection: WEP, WPA, WPA2, WMM, TKIP, CKIP. MESH Networking and P2P connection are available. You can change the MAC address, scan the air, filter packets, measure and control channel power, select channels, and much more.
Wi-Fi module connection
Not all module pins require connection, many can be left unused. For example, the pins of the NFC interface and the I2S digital audio interface are left free. Outside, only an antenna switch was needed on the SKY13351-378LF chip. And some elements of antenna path matching. Antennas are provided remote.
The module is also interesting in that it has power off pins. And separately for Wi-Fi and separately for Bluetooth. The residual consumption will be 220 µA.
The diagram also shows the connection lines of the JTAG module. The CYW43340 chip contains an ARM Cortex-M4 core inside, i.e. the same as the main microcontroller, which means they can be debugged in the same environment in which the main program is being developed.
It is better to make the router modular. The processor board is 6-layer with thinner copper and the power and driver board is 4-layer and thicker copper.
The RS-485 and CAN interfaces are galvanically isolated from the system and from each other.
Looking ahead, I will say that on the module ISM43340-L77 in station mode, the speed of transferring files to a remote FTP server was 45 Mbps on the 5 GHz band. And when using TLS with AES-256 encryption, the speed was 27 Mbps.
That’s all for now.