sal和ems区别(nucksal)

物联网设备由于网络连接和应用的多样化，大大增加了软件开发的难度和复杂度，开发方式也会与以往的嵌入式设备有很大的不同。

目前主流的软件开发模式是什么？让我们以具有MCU WiFi/NB-IoT SoC架构的典型物联网设备的开发为例(图1)。开发者需要针对特定的无线SoC/模块，开发MCU TCP/IP协议层以上的应用，包括MQTT、HTTP、Web Socket、业务应用等。

一旦用户更换无线芯片或模块，由于网络协议和编程接口的不统一，上层应用需要进行实质性的更改，甚至重新开始。

(图1:当前软件开发模式)

但如果采用RT-Thread操作系统的SAL抽象层(图2)，开发者就不需要考虑系统采用哪种无线模式、哪种无线芯片，甚至是哪个模块、哪个接口，只需要调用上层的API接口就可以实现一次开发、跨平台使用。

不仅如此，RT-Thread支持的各类物联网软件包都可以轻松安装使用。

(图2:带有SAL的软件开发模式)

由此可见，RT-Thread此次发布的SAL对物联网行业意义重大，真正实现了系统(MCU无线芯片/模块)级、ACS(Application Cross System)级的跨平台软件开发和兼容，后期的应用扩展将成为小菜一碟。

SAL，socket抽象层的缩写，意思是Socket抽象层，位于网络硬件层和应用层之间。它的前身是RT-Thread的DFS_NET组件。由于对lwIP的一定依赖和局限性，RT-Thread几乎对其进行了重构。

随着SAL的诞生，RT-Thread可以无缝接入各种网络芯片或模块(例如W5500/CH395等具有协议栈的以太网芯片、带AT指令的WiFi模块、GPRS模块、NB-IoT模块等。)，大大提高了RT-Thread与IOT领域不同网络硬件的兼容性。其主要特点如下(图3):

抽象和统一各种网络协议栈接口。

提供标准的套接字应用编程接口

统一文件描述符管理模式

(图3:网络框架图)

下面将从与SAL相关的模块的角度解释SAL的功能和实现：

应用层：做网络开发时，应用层可以直接使用SAL提供的BSD Socket API接口。接口层的统一抽象使我们的开发者能够快速应用RT-Thread提供的许多支持BSD Socket接口的物联网软件包。让我们的用户大大提高了软件在网络编程中的可重用性。

SAL实现层：该层位于SAL的底层，可以针对不同的模块、芯片或协议栈实现与SAL框架的对接。接入完成后，应用层几乎不需要关心真实的网络接入方式，减少了应用层与底层的耦合。

DFS文件系统层：SAL和DFS紧密结合，Socket描述符和fd文件描述符可以完全对应，实现了fd的统一管理。应用层可以通过读/写和轮询/选择接口操作Socket套接字，更符合POSIX标准。

应用场景：

用于对接AT指令的网络模块

在使用这些at模块进行网络开发时，不可避免地会有许多与模块相关的AT通信代码耦合到我们的应用代码中。因此，以前使用标准BSD Socket开发的组件无法重用。

有了SAL，我们只需要按照AT模块的指令模式来实现SAL的对接接口(RT-Thread已经提供了常见模块的实现，比如乐心的ESP8266，师傅的M26)，上层应用就可以愉快地对Socket进行编程。

这里有一点，RT-Thread的AT组件已经有了上述功能，即将发布，敬请关注.

具有内置对接协议栈的网络芯片

随着W5500/CH395等网络芯片的日益普及，我们的MCU不需要运行网络协议栈，大大减少了MCU的资源占用。但是，它与AT模块有相同的问题。如何才能保证应用层使用标准Socket编程仍然非常简单？让SAL解决这个问题。

SAL已经构建了适应这些芯片的轮子，这将方便我们所有使用RT-Thread W5500/CH395的开发人员。

非lwIP的TCP/IP协议栈

在一些特殊领域，lwIP可能无法满足我们的用户需求。取代TCP/IP协议栈是必然的。正是因为有了SAL帧，新的协议栈只有对接后才能被上层应用安全使用，之前的代码也可以重用。

插座控制器局域网

Socket CAN作为Linux上的一种CAN编程方式，使用方便，编程容易。很多用户也想在RT-Thread上实现Socket CAN编程，所以此时需要SAL。我们只需要用RT-Thread CAN设备实现底层SAL框架对应的接口即可。

[强烈推荐]

了解更多细节，关注RT-Thread。