Let you know what SAL socket abstraction layer is

IoT devices have to connect to a variety of networks and applications, which greatly increases the difficulty and complexity of software development. The development method will also be very different from previous embedded devices. What is the current mainstream software development model? Let's take the development of a typical IoT device with MCU+WiFi/NB-IoT SoC architecture as an example (Figure 1). Developers need to develop applications above the MCU TCP/IP protocol layer for specific wireless SoC/modules, including MQTT, HTTP, Web Socket, business applications, etc. Once the user replaces the wireless chip or module, due to the inconsistency of network protocols, programming interfaces, etc., the upper-layer applications need to be significantly modified or even started from scratch.

(Figure 1: Current software development model)

If the SAL abstraction layer of the RT-Thread operating system is used (Figure 2), developers do not need to consider which wireless method, wireless chip, or even module or interface the system uses. They only need to call the upper-level API interface to achieve one-time development and cross-platform use. In addition, various IoT software packages supported by RT-Thread can be easily "installed and used".

              (Figure 2: Software development model with SAL)

As can be seen from the above, the SAL released by RT-Thread this time is of great significance to the IoT industry. It truly realizes cross-platform software development and compatibility at the system (MCU+wireless chip/module) level, namely ACS (Application Cross System), and subsequent application expansion will become a piece of cake.

SAL Introduction

SAL, short for Socketabstraction layer, is the socket abstraction layer between the network hardware layer and the application layer. Its predecessor was the DFS_NET component of RT-Thread. Due to its dependence on lwIP and limitations, RT-Thread has almost completely rebuilt it. The emergence of SAL allows RT-Thread to seamlessly access a variety of network chips or modules (for example: Ethernet chips with built-in protocol stacks such as W5500/CH395, WiFi modules with AT commands, GPRS modules, NB-IoT modules, etc.), greatly improving RT-Thread's compatibility with different network hardware in the IoT field. Its main features are as follows (Figure 3):

• Abstract and unify various network protocol stack interfaces

• Provides standard BSDSocket API

• Unified fd (file descriptor) management method

(Figure 3: Network framework diagram)

The following will explain the functions and implementation of SAL from the perspective of modules associated with SAL:

• Application layer: When doing network development, the application layer can directly use the BSD Socket API interface provided by SAL. The unified abstraction of the interface layer allows our developers to quickly apply the many IoT software packages provided by RT-Thread that support the BSDSocket interface. This greatly improves the reusability of software for our users in network programming.

• SAL implementation layer: This layer is located at the bottom of SAL, and completes the docking implementation with the SAL framework for different modules, chips or protocol stacks. After the access is completed, the application layer hardly needs to care about the actual network access method, which reduces the coupling between the application layer and the bottom layer.

• DFS file system layer: SAL is closely integrated with DFS, and the socket descriptor and fd file descriptor can be completely matched, realizing the unified management of fd. This allows the application layer to operate the socket through the read/write and poll/select interfaces, making it more compatible with the POSIX standard.

Application scenarios:

Network module for connecting to AT commands

When using these AT modules for network development, it is inevitable to couple a lot of module-related AT communication codes in our application code. This will also result in the components previously developed using standard BSD Sockets being unable to be reused.

With SAL, we only need to implement the SAL docking interface according to the command mode of the AT module (RT-Thread has provided the implementation of common modules, such as Espressif's ESP8266 and Quectel's M26), and the upper-level application can happily perform Socket programming.

Just a quick note here, the AT component of RT-Thread already has the above functions and will be released soon, so stay tuned...

Connect to network chip with built-in protocol stack

With the increasing popularity of network chips like W5500/CH395, our MCU no longer needs to run the network protocol stack, which greatly reduces the resource usage of the MCU. However, there is the same problem as the AT module. How can we ensure that the application layer can still use the standard Socket for programming? This problem is left to SAL to solve. SAL has built wheels that adapt to these chips, which will be convenient for all of us developers who use RT-Thread + W5500/CH395.

Non-lwIP TCP/IP protocol stack

In some special fields, lwIP may not be able to meet the requirements of our users. Replacing the TCP/IP protocol stack is inevitable. Thanks to the SAL framework, the new protocol stack only needs to be connected to it, and the upper-layer application can be used with confidence, and the previous code can still be reused.

SocketCAN

Socket CAN is a way of CAN programming on Linux. It is easy to use and programming is smooth. Many users also want to implement Socket CAN programming on RT-Thread. At this time, SAL is needed. We only need to use RT-Thread CAN device at the bottom layer to implement the interface corresponding to the SAL framework.

DFS_NET to SAL Migration Guide

The original DFS_NET configuration is located in: RT-Thread Components → Device virtual file system

The existing SAL configuration is located in: RT-ThreadComponents → Network → Socketabstraction layer

The migration steps are as follows:

1. Determine whether the RT_USING_DFS_NET option is enabled in the previous project. If it is enabled, migration is required.

2. The RT_USING_DFS_NET option was deprecated after the SAL component was added and replaced by the SAL_USING_POSIX option. If migration is required, enable the above SAL configuration option in the ENV tool.

3. Save the configuration and exit the ENV tool, regenerate the project, and complete the migration.