物联网主流的软件开发模式是怎么样的？

物联网设备，因为要连接网络和应用的多样化，导致软件的开发难度和复杂度大幅地增加，开发方式也会与之前的嵌入式设备大不一样。当前主流的软件开发模式是怎么样的呢？我们以一个典型的MCU+WiFi/NB-IoT SoC架构的IoT设备开发为例（图示一），开发人员需要针对特定的无线SoC/模块，开发MCU TCP/IP协议层以上的应用，包括MQTT、HTTP、Web Socket、业务类应用等等。一旦用户更换了无线芯片或模块，因为网络协议、编程接口等的不统一，上层应用都需要做大幅的改动甚至要重头来过。

（图示一：当前的软件开发模式）

而如果采用了RT-Thread操作系统的SAL抽象层（图示二），开发者则无须考虑系统采用的是哪种无线方式、哪种无线芯片、甚至哪种模块，哪种接口，只需调用上层的API接口，即可实现一次开发，跨平台使用。不仅如此，RT-Thread支持的各种IoT软件包，都可以很方便的“即装即用”。

（图示二：具备SAL的软件开发模式）

以上可见，RT-Thread此次发布的SAL可谓对IoT产业意义重大，真正实现了系统（MCU+无线芯片/模块）层面的跨平台软件开发及兼容，暨ACS（Application Cross System），后期的应用扩展也会变得易如反掌。

SAL介绍

SAL，即Socketabstraction layer的缩写，意为套接字抽象层，处于网络硬件层与应用层之间。 其前身是RT-Thread 的 DFS_NET 组件，由于其对lwIP 有一定的依赖，存在局限性，RT-Thread对其进行了近乎重构的再造。SAL 的孕育而出，使得 RT-Thread 可以无缝接入各式各样的网络芯片或模块（例如： W5500/CH395 这类自带协议栈的以太网芯片，带 AT指令的 WiFi 模块、GPRS 模块、NB-IoT模块等等），极大地提升了RT-Thread 在 IoT 领域对于不同网络硬件的兼容性。其主要特性如下（图示三）：

抽象、统一多种网络协议栈接口

提供标准 BSDSocket API

统一 fd（file descriptor）管理方式

（图示三：网络框架图）

下面将站在与 SAL 相关联的模块角度，说明SAL 的功能与实现：

应用层 ：应用层在做网络开发时，可以直接使用 SAL 提供的 BSD Socket API 接口。接口层的统一抽象，使得我们的开发者也可以快速应用 RT-Thread 提供的众多支持 BSDSocket 接口的 IoT 软件包。让我们的用户 在网络编程方面极大的提升了软件的可重用性。

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

DFS 文件系统层：SAL 与 DFS 紧密结合， Socket 描述符与fd文件描述符可以完全对应起来，实现了fd的统一管理。使得应用层可以通过read/write 、 poll/select 接口操作 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 框 架，新的协议栈，只需要与其对接完毕，上层应用即可放心使用，以前的代码照样也可以被拿来重用。

SocketCAN

Socket CAN 做为Linux上CAN编程的一种方式，它简易易用，编程顺手。很多用户也想在 RT-Thread 上实现 Socket CAN 编程，这个时候就需要 SAL 上场了。只需要我们在底层使用 RT-Thread CAN 设备实现 SAL框架对应的接口即可。

从 DFS_NET 到 SAL 迁移指南

原先的 DFS_NET 配置位于：RT-Thread Components → Device virtual file system

现有的 SAL 配置位于： RT-ThreadComponents → Network → Socketabstraction layer

迁移相关步骤如下：

确定之前项目中是否开启 RT_USING_DFS_NET 选项，若开启需要进行迁移。

RT_USING_DFS_NET 选项在SAL 组件添加之后被废弃，由 SAL_USING_POSIX 选项代替，若需要迁移，在 ENV 工具中开启上述 SAL 配置选项。

保存配置并退出ENV 工具，重新生成工程，完成迁移。