老板說(shuō)我技術(shù)需要有長(zhǎng)進(jìn)，不能只做一個(gè)crud boy。 于是我選來(lái)選去，終于選定了，來(lái)學(xué)習(xí)操作系統(tǒng)。因?yàn)椴僮飨到y(tǒng)一直被看做是計(jì)算機(jī)軟件的基石。

本系列是我學(xué)習(xí)操作系統(tǒng)的筆記，操作系統(tǒng)是以AliOS Things為例子。其他的操作系統(tǒng)也是差不多。

本文主要是講操作系統(tǒng)的設(shè)備驅(qū)動(dòng)模型，后面會(huì)有更多的操作系統(tǒng)內(nèi)容介紹。

國(guó)慶假期學(xué)門新技術(shù)，拒絕只做crud boy, 就從操作系統(tǒng)開(kāi)始 - 中斷管理

國(guó)慶假期學(xué)門新技術(shù)，拒絕只做crud boy, 就從操作系統(tǒng)開(kāi)始 - 定時(shí)器管理

1. AliOS Things 設(shè)備驅(qū)動(dòng)模型

開(kāi)源操作系統(tǒng)中系統(tǒng)驅(qū)動(dòng)框架做的最好的無(wú)疑是Linux系統(tǒng)，Linux系統(tǒng)中設(shè)計(jì)精良的驅(qū)動(dòng)框架、設(shè)備樹(shù)等功能會(huì)硬件廠商對(duì)接驅(qū)動(dòng)系統(tǒng)的成本降到很低，并且通過(guò)接入VFS系統(tǒng)統(tǒng)一了Linux系統(tǒng)驅(qū)動(dòng)對(duì)應(yīng)用程序提供的接口，為操作系統(tǒng)中使用驅(qū)動(dòng)相關(guān)的應(yīng)用程序在不同的Linux系統(tǒng)間的移植掃平了障礙。反觀傳統(tǒng)的RTOS系統(tǒng)大多數(shù)比較注重在內(nèi)核功能的開(kāi)發(fā)上，欠缺對(duì)驅(qū)動(dòng)架構(gòu)方面的設(shè)計(jì)。前文曾經(jīng)提到過(guò)物聯(lián)網(wǎng)操作系統(tǒng)大多是從傳統(tǒng)RTOS系統(tǒng)發(fā)展而來(lái)的，所以大多數(shù)的物聯(lián)網(wǎng)操作系統(tǒng)在驅(qū)動(dòng)框架上面的沒(méi)有經(jīng)過(guò)太多設(shè)計(jì)，總結(jié)下來(lái)可以分為以下幾類：

1. 完全沒(méi)有對(duì)設(shè)備驅(qū)動(dòng)進(jìn)行任何定義
2. 簡(jiǎn)單定義了硬件接口層后完全由芯片廠實(shí)現(xiàn)
3. 實(shí)現(xiàn)了簡(jiǎn)單的設(shè)備驅(qū)動(dòng)，提供統(tǒng)一的應(yīng)用程序訪問(wèn)接口

第1類和第2類系統(tǒng)對(duì)應(yīng)用程序不太友好，即使是相同的操作系統(tǒng)上面寫(xiě)的應(yīng)用程序移植到不同平臺(tái)后也會(huì)因?yàn)榻涌诓灰恢拢蛘呤请m然接口形式一致但接口底層實(shí)現(xiàn)的差別導(dǎo)致應(yīng)用程序大概率沒(méi)辦法跨平臺(tái)移植或跨平臺(tái)無(wú)需調(diào)試即可運(yùn)行。第3類對(duì)應(yīng)用程序的移植性比較友好，但有一個(gè)問(wèn)題是，很多系統(tǒng)實(shí)現(xiàn)的通用驅(qū)動(dòng)實(shí)現(xiàn)的都“過(guò)于簡(jiǎn)單”，這就導(dǎo)致有些硬件的總線的特性沒(méi)辦法被發(fā)揮出來(lái)，隨著物聯(lián)網(wǎng)應(yīng)用場(chǎng)景越來(lái)越復(fù)雜，其缺點(diǎn)也是越來(lái)越明顯。

在總結(jié)了物聯(lián)網(wǎng)領(lǐng)域設(shè)備框架的問(wèn)題之后，AliOS Things從“易用性”的角度出發(fā)進(jìn)行設(shè)計(jì)，設(shè)計(jì)了下圖所示的驅(qū)動(dòng)框架。

?驅(qū)動(dòng)框架對(duì)應(yīng)用程序統(tǒng)一提供兩種類型的接口：

• AOS API，如aos_gpioc_get/ aos_gpioc_set等
• VFS API，即open/close/read/write/ioctl/poll等

AOS API對(duì)進(jìn)行傳統(tǒng)RTOS應(yīng)用開(kāi)發(fā)的人比較友好。對(duì)于RAM/ROM要求非常嚴(yán)格的應(yīng)用場(chǎng)景，可以直接呼叫AOS形式的API，減少對(duì)VFS驅(qū)動(dòng)子系統(tǒng)的依賴，從而減少固件大小。

VFS API對(duì)Linux開(kāi)發(fā)者比較友好，遵循POSIX接口定義，基于POSIX標(biāo)準(zhǔn)實(shí)現(xiàn)的應(yīng)用程序在AliOS Things和其它遵循POSIX接口的操作系統(tǒng)之間相互移植就會(huì)簡(jiǎn)便很多。

驅(qū)動(dòng)框架定義了HAL API的標(biāo)準(zhǔn)，一般是由芯片廠商來(lái)實(shí)現(xiàn)的。HAL API的定義 的過(guò)程中主要考慮了以下兩點(diǎn)：

• 硬件強(qiáng)相關(guān)：只有和硬件強(qiáng)相關(guān)的功能才會(huì)被定義到HAL API中
• 原子功能：所有HAL API功能都很獨(dú)立，很多API只需要操作硬件的幾個(gè)寄存器就可以實(shí)現(xiàn)了

在HAL API和AOS API之間則是設(shè)備驅(qū)動(dòng)子系統(tǒng)的實(shí)現(xiàn)層。設(shè)計(jì)設(shè)備驅(qū)動(dòng)子系統(tǒng)的主要目的有兩個(gè):

• 隔離性：將應(yīng)用程序和HAL API隔離開(kāi)，徹底解決應(yīng)用和芯片廠之間的耦合關(guān)系
• 統(tǒng)一性：驅(qū)動(dòng)程序只依賴與驅(qū)動(dòng)子系統(tǒng)提供的API，驅(qū)動(dòng)子系統(tǒng)保證對(duì)應(yīng)用層提供的API行為在不同平臺(tái)之間是一致的。

除了提供AOS或VFS API之外和定義HAL API的功能之外，驅(qū)動(dòng)框架還提供了以下功能，下面分別進(jìn)行介紹。

2、驅(qū)動(dòng)自動(dòng)分級(jí)加載機(jī)制

隨著現(xiàn)代物聯(lián)網(wǎng)系統(tǒng)的應(yīng)用場(chǎng)景越來(lái)越復(fù)雜，同一個(gè)物聯(lián)網(wǎng)硬件設(shè)備對(duì)外設(shè)的需求也越來(lái)越多。不同驅(qū)動(dòng)程序之間可能會(huì)存在依賴關(guān)系。為了能讓驅(qū)動(dòng)開(kāi)發(fā)者比較方便的將自己的驅(qū)動(dòng)以模塊的方式添加到系統(tǒng)中和盡量減少添加/刪除設(shè)備驅(qū)動(dòng)過(guò)程中所需要修改的代碼，設(shè)計(jì)了驅(qū)動(dòng)自動(dòng)加載機(jī)制。AliOS Things將設(shè)備驅(qū)動(dòng)一共分為9個(gè)級(jí)別，每個(gè)級(jí)別的驅(qū)動(dòng)初始化聲明宏定義及其在系統(tǒng)啟動(dòng)過(guò)程中的啟動(dòng)順序如下表所示。

采用上面的宏定義進(jìn)行初始化函數(shù)聲明之后，用同樣的宏定義聲明的函數(shù)指針會(huì)被分到一組中，相同組會(huì)在鏈接階段放到固件特定的代碼段中。系統(tǒng)啟動(dòng)的時(shí)候，驅(qū)動(dòng)框架會(huì)依次從這些特定的代碼段去讀取函數(shù)指針并呼叫這些函數(shù)指針指向的函數(shù)，每個(gè)段被編譯進(jìn)的段名稱如上表所示。這套機(jī)制可以保證用不同宏定義聲明的多個(gè)驅(qū)動(dòng)初始化函數(shù)會(huì)嚴(yán)格按照表格中從1到9的順序被呼叫，用相同宏定義聲明的多個(gè)驅(qū)動(dòng)初始化函數(shù)則是隨機(jī)的。

除此之外，驅(qū)動(dòng)框架還提供了設(shè)備后臺(tái)初始化方式的宏定義（VFS_DRIVER_BG_ENTRY（driver_entry_api_name）），可以用于低優(yōu)先級(jí)驅(qū)動(dòng)初始化函數(shù)的聲明。被聲明做低優(yōu)先級(jí)驅(qū)動(dòng)的初始化函數(shù)會(huì)在被低優(yōu)先級(jí)的線程在后臺(tái)運(yùn)行，通過(guò)這樣的方式可以提高整個(gè)系統(tǒng)啟動(dòng)的速度。假設(shè)將將藍(lán)牙驅(qū)動(dòng)初始化過(guò)程聲明成后臺(tái)初始化（VFS_DRIVER_BG_ENTRY(bluetooth_drv_init, NULL, 4096)），常規(guī)加載過(guò)程和驅(qū)動(dòng)分級(jí)加載過(guò)程的軟件流程的差異可以參考下圖所示的流程圖。

?

3、驅(qū)動(dòng)線程/消息/事件模型

AliOS Things在3.3版版本中支持的彈性內(nèi)核對(duì)驅(qū)動(dòng)框架提出了比較高的要求，驅(qū)動(dòng)框架既要能運(yùn)行在宏內(nèi)核架構(gòu)下，又要能運(yùn)行在微內(nèi)核架構(gòu)下，甚至還需要同時(shí)運(yùn)行在內(nèi)核態(tài)和用戶態(tài)。針對(duì)這種需求，AliOS Things設(shè)計(jì)了在適用于彈性內(nèi)核架構(gòu)下線程/消息/事件模型。

當(dāng)設(shè)備驅(qū)動(dòng)運(yùn)行在內(nèi)核態(tài)的時(shí)候，內(nèi)核功能可以通過(guò)直接函數(shù)調(diào)用的方式來(lái)調(diào)用驅(qū)動(dòng)提供的服務(wù)；用戶態(tài)應(yīng)用程序可以通過(guò)VFS接口或這是通過(guò)系統(tǒng)調(diào)用的方式訪問(wèn)AOS接口。

但當(dāng)驅(qū)動(dòng)運(yùn)行在用戶態(tài)的時(shí)候，其它應(yīng)用程序訪問(wèn)驅(qū)動(dòng)提供的服務(wù)則需要通過(guò)RPC（Remote Procure Call，遠(yuǎn)程過(guò)程調(diào)用）的方式。在這種情況下，AliOS Things只提供VFS的服務(wù)訪問(wèn)方式，如上圖所示。這樣同一套硬件的驅(qū)動(dòng)程序無(wú)需修改就可以運(yùn)行在用戶態(tài)或內(nèi)核態(tài)，跟RPC和VFS相關(guān)的邏輯全部由驅(qū)動(dòng)框架完成，從而簡(jiǎn)化硬件驅(qū)動(dòng)程序的設(shè)計(jì)。微內(nèi)核架構(gòu)下驅(qū)動(dòng)線程/消息模型的流程圖如下圖所示，詳細(xì)代碼可以查看aos_device_register函數(shù)的實(shí)現(xiàn)，這里就不進(jìn)行詳細(xì)展開(kāi)。

?

?

4、設(shè)備驅(qū)動(dòng)子系統(tǒng)

下表是各個(gè)設(shè)備驅(qū)動(dòng)子系統(tǒng)源代碼位置，接口定義頭文件、使用案例說(shuō)明以及芯片廠對(duì)接接口頭文件所在位置。讀者可以根據(jù)自己的需求進(jìn)行詳細(xì)解讀。

其中每個(gè)設(shè)備驅(qū)動(dòng)子系統(tǒng)都有對(duì)應(yīng)的AOS API模塊和VFS API模塊，VFS API模塊是依賴于AOS API的。用戶可以根據(jù)需求選擇使用哪種類型的API。

其中各驅(qū)動(dòng)子系統(tǒng)在設(shè)計(jì)實(shí)現(xiàn)過(guò)程中可以滿足下表的場(chǎng)景需求。

?