當前主流的軟件開發模式是怎么樣的呢?我們以一個典型的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，即Socket abstraction layer的縮寫，意為套接字抽象層，處于網絡硬件層與應用層之間。 其前身是 RT-Thread 的 DFS_NET 組件，由于其對 lwIP 有一定的依賴，存在局限性，RT-Thread對其進行了近乎重構的再造。
SAL 的孕育而出，使得 RT-Thread 可以無縫接入各式各樣的網絡芯片或模塊(例如： W5500/CH395 這類自帶協議棧的以太網芯片，帶 AT指令的 WiFi 模塊、GPRS 模塊、NB-IoT 模塊等等)，極大地提升了RT-Thread 在 IoT 領域對于不同網絡硬件的兼容性。其主要特性如下(圖示三)：
抽象、統一多種網絡協議棧接口
提供標準 BSD Socket API
統一 fd(file descriptor)管理方式
(圖示三：網絡框架圖)
下面將站在與 SAL 相關聯的模塊角度，說明 SAL 的功能與實現：
應用層 ：應用層在做網絡開發時，可以直接使用 SAL 提供的 BSD Socket API 接口。接口層的統一抽象，使 得我們的開發者也可以快速應用 RT-Thread 提供的眾多支持 BSD Socket 接口的 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 框 架，新的協議棧，只需要與其對接完畢，上層應用即可放心使用，以前的代碼照樣也可以被拿來重用。
Socket CAN
Socket CAN 作為Linux上CAN編程的一種方式，它簡易易用，編程順手。很多用戶也想在 RT-Thread 上實現 Socket CAN 編程，這個時候就需要 SAL 上場了。只需要我們在底層使用 RT-Thread CAN 設備實現 SAL框架對應的接口即可。
京公網安備 11010502049343號