Our familiar electronic devices are increasingly connecting to the internet. While the RX family is best known for its adoption in factory automation, it is also employed in areas such as HVAC systems, elevator controls, and lighting infrastructure in building automation applications, leveraging its networking capabilities.
Since joining Renesas in 2003, I've been consistently involved in the development of the TCP/IP protocol stack tailored for Renesas microcontrollers.
TCP/IP protocol stack [M3S-T4-Tiny] for RX Family
Drawing from my experience, I believe one of the main challenges in the IoT transformation revolves around the question: "How should TCP/IP be implemented?"
To illustrate further, consider this: around the release of Windows 95 in 1995, CPUs operating Windows functioned at a frequency of 100MHz ~ 200MHz. Fast forward to 2023, and the prominent RX65N of the RX family operates at a max frequency of 120MHz, mirroring the CPU speeds from the Windows 95 era. Even back then, computers running Windows 95 were capable of encrypted communications like SSL when connecting to the internet (although widespread adoption of SSL, now known as TLS, became more common in the 2000s). This suggests that MCUs like the RX65N should feasibly connect to the internet.
Yet, it seems that only a subset of innovative users is actively pursuing IoT integration for their products. There must be an inherent barrier, and I think that the challenge lies in the implementation of TCP/IP. In addressing this challenge, I believe that the widespread adoption of an operating system equipped with internet functionalities, like Windows 95, might be the solution.
As frequently referenced in this blog series, Renesas has partnered with giants like AWS and Microsoft to collaboratively develop real-time operating systems tailored for our microcontrollers, namely "FreeRTOS" and "Azure RTOS".
This time, we'll focus on the technical aspects of "How should TCP/IP be implemented?". One fundamental concept to understand TCP/IP is the "OSI reference model." For those familiar with computer networking, this might be a well-known idea. The OSI model starts with the physical layer, which represents the actual computer and its internal electrical signals, as its first layer. From the second to the seventh layer, it's organized hierarchically based on the roles of software in data processing. I've also compiled a table below briefing the main protocols used in IoT devices and their functions.
For electronic devices equipped with general-purpose operating systems (OS) like PCs and smartphones, functions from the second to the sixth layer are incorporated within the OS, and the seventh layer (application layer) is provided to developers as an OS feature. Similarly, in MCU embedded systems equipped with the RX family, functions from the second to the sixth layer are encompassed within real-time operating systems like FreeRTOS or Azure RTOS, and the seventh layer (application layer) is offered to developers as an OS function. Traditionally, since the real-time OS and functions from the second to the sixth layer were provided separately by various software vendors, users faced the challenge of having to work on constructing the foundational layers (2nd to 6th) before proceeding with the development of applications in the seventh layer.
For current wireless modules like Wi-Fi or cellular, layers one to four are handled by the wireless module side, while layers five to seven are managed by the MCU side. This structure requires a rather complex implementation, bridging the OSI reference model itself between different computers. Furthermore, both on the MCU side and the wireless module side, a CPU is needed to process data for protocols like TLS or TCP/IP, which results in power inefficiencies across the entire system. If implementations like MQTT or TLS are done on the MCU side, the related MQTT or TLS on the wireless module side becomes redundant, wasting memory allocated for storing the associated programs.
For Ethernet, the first layer is already integrated into the MCU, with only the signal conversion part handled by an external chip, commonly referred to as the PHY chip. Additionally, layers two through four are software-managed on the MCU side. This cost-efficient configuration has become prevalent in the market over the past decade. Therefore, it is believed that similar changes will take place in wireless modules in the future.
Constructing a network system, as fascinating as it is complex, evolves with time and technological advancements. Particularly when employing wireless modules in MCU-based IoT systems, it's crucial to employ an OSI reference model-centered design strategy.
At Renesas, our commitment is clear: continuous engagement with our clients to provide solutions that are both timely and optimal. We remain dedicated to furthering the development of real-time OSes like "FreeRTOS" and "Azure RTOS" to empower our customers to focus on application development.