Follow+Star the public account, don’t miss exciting content
Author | Tanmoy Sen
WeChat Official Account | strongerHuang
In today’s world of advanced networking, more and more devices have the need to connect to the internet, and the ways to connect are increasing.
At the Smart Production Solutions (SPS) exhibition held in Nuremberg in November 2022, a working group composed of eight partners including Analog Devices, Arm, Amazon Web Services (AWS), B&R Industrial Automation, Lattice Semiconductor, Schneider Electric, Texas Instruments, and NXP announced that they would create an open-source time-sensitive networking (TSN) based Open Platform Communications Unified Architecture (OPC UA) using FreeRTOS.
To ensure that OPC UA is widely used in the field, just like existing industrial protocols, the price of devices supporting OPC-UA/TSN must be on par with existing solutions. This requires devices based on low-cost MCUs and low-power FPGA SoCs that support OPC-UA/TSN.
FreeRTOS-plus-TCP Software Architecture
Source code address:
https://github.com/FreeRTOS/FreeRTOS-Plus-TCPIn the current design of the FreeRTOS+TCP stack, the IP task is designed as an event-driven task. It blocks (suspends) on a FreeRTOS queue with a timeout, and the application and network interface post events to this queue. When an event (an event posted to the queue) is received, the IP task unblocks and processes these events. These events include:
-
Sending/receiving events from the socket API, as well as sending/receiving events to the socket API
-
IP stack timer events
-
Other network events (such as network uplink/downlink events)
All events received in the queue are currently processed with the same priority (since there is only one SW queue), regardless of traffic type, socket configuration, protocol, etc.
-
There is no option in the existing stack to handle multi-priority traffic data. -
Three context switches (from application task to IP task and from IP task to network driver task) may make the sending and receiving delays of TSN uncertain. -
The current priority of the FreeRTOS-plus-TCP idle task PrvIPTask is higher than that of application tasks. This will cause problems because higher throughput for TSN may require the application task’s priority to be higher than that of the idle task. -
Using the same Ethernet driver task for sending and receiving will pose challenges to the high throughput of TSN.
-
General API for best-effort and TSN traffic. -
To support TSN traffic types, a new “xDomain” named “FREERTOS_AF_TSN” will be introduced in the “FreeRTOS_socket” API.
-
A decoding layer after the socket layer can distinguish best-effort TCP traffic from TSN traffic. -
This layer can also distinguish various priority TSN traffic.
-
Support for multiple priorities to achieve deterministic traffic at layer 2. -
Support for traffic handling based on priority.
-
Only best-effort traffic: in this case, the stack will operate as a single queue system. -
Best-effort traffic and TSN traffic: activate the required number of queues based on the number of queues supported by the underlying hardware.
-
FreeRTOS-plus-TCP will use a simple polling mechanism to refresh the queues to the hardware. -
The hardware will determine the send and receive rates, and the FreeRTOS-plus-TCP stack will maintain the hardware rate.
Send + Receive Block Diagram
———— END ————
● Column “Embedded Tools”
● Column “Embedded Development”
● Column “Keil Tutorials”
● Selected Tutorials from Embedded Column
Follow the public account reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.
Click “Read the Original” to see more shares.