近期騰訊低調(diào)地在GitHub上開源了自己的loT操作TencentOS tiny，截至發(fā)稿，已經(jīng)累積了2000多個Star，引發(fā)了不小的關(guān)注。由于筆者曾經(jīng)做過CSDN的嵌入式大版當過很長時間的版主，所以第一時間到https://github.com/Tencent/TencentOS-tiny下載了全部的代碼，第一時間為大家?guī)斫庾x。

TencentOS tiny整體架構(gòu)

TencentOS tiny 提供精簡的 RTOS內(nèi)核，其架構(gòu)圖如下：

目前看其內(nèi)核部分已經(jīng)開發(fā)完成，并已經(jīng)完全開源。從目前TencentOS tiny的情況看，騰訊入局物聯(lián)網(wǎng)的相關(guān)鏈條已經(jīng)規(guī)劃完整：

布署了TencentOS tiny的的嵌入式開發(fā)板也已經(jīng)制造出來，所以看來鵝廠在物聯(lián)網(wǎng)時代對于入口的爭奪也不會有絲毫的放松。

下面我將對于TencentOS tiny代碼中內(nèi)核及l(fā)oT協(xié)議部分進行相關(guān)解讀。

TencentOS tiny內(nèi)核信號量與互斥鎖解讀

TencentOS tiny的官宣文檔中對于其內(nèi)核的描述如下：TencentOS tiny 實時內(nèi)核包括任務(wù)管理、實時調(diào)度、時間管理、中斷管理、內(nèi)存管理、異常處理、軟件定時器、鏈表、消息隊列、信號量、互斥鎖、事件標志等模塊。其中定時器、消息隊列等在之前都有過相應(yīng)介紹，這里就為大家來解讀一下信號量與互斥鎖的相關(guān)代碼。信號量與互斥鎖的異同：1.信號量與互斥鎖最根本的不同點在于：互斥鎖的取值只能是0或者1，而信號量的取值范圍則可以定義。2.信號量的作用域可以進程也可以是線程，而互斥鎖只能是線程。簡單來說互斥鎖可以實現(xiàn)線程對于唯一資源的使用保護，而信號量則可以實現(xiàn)多線程或者進程間數(shù)量有限資源的使用保護。從某種意義上講互斥鎖是只能一個資源可用的信號量。關(guān)于TencentOS tiny互斥體的實現(xiàn)，首先來看其數(shù)據(jù)結(jié)構(gòu)具體解讀如下：

__API__k_err_ttos_mutex_pend_timed(k_mutex_t*mutex,k_tick_ttimeout) { TOS_CPU_CPSR_ALLOC(); k_err_terr; TOS_PTR_SANITY_CHECK(mutex); TOS_IN_IRQ_CHECK(); #ifTOS_CFG_OBJECT_VERIFY_EN>0u if(!pend_object_verify(&mutex->pend_obj,PEND_TYPE_MUTEX)){ returnK_ERR_OBJ_INVALID; } #endif TOS_CPU_INT_DISABLE();//將CPU鎖住，防止其它進程進入 if(mutex->pend_nesting==(k_nesting_t)0u){//沒有等待 mutex_fresh_owner_mark(mutex,k_curr_task);//將此mutex的owner置為當前task TOS_CPU_INT_ENABLE();//將CPU解鎖 returnK_ERR_NONE;//返回成功 } if(knl_is_self(mutex->owner)){ if(mutex->pend_nesting==(k_nesting_t)-1){//等待數(shù)量如果超限則返回overflow TOS_CPU_INT_ENABLE(); returnK_ERR_MUTEX_NESTING_OVERFLOW; } ++mutex->pend_nesting; TOS_CPU_INT_ENABLE(); returnK_ERR_MUTEX_NESTING; } if(timeout==TOS_TIME_NOWAIT){//如果鎖已經(jīng)被占用超時時間為不等待，則直接返回 TOS_CPU_INT_ENABLE(); returnK_ERR_PEND_NOWAIT; } if(knl_is_sched_locked()){//如果任務(wù)被鎖定，則直接返回 TOS_CPU_INT_ENABLE(); returnK_ERR_PEND_SCHED_LOCKED; } if(mutex->owner->prio>k_curr_task->prio){ tos_task_prio_change(mutex->owner,k_curr_task->prio);//如果owner的優(yōu)先級更低，也就是其數(shù)值更大，則調(diào)整優(yōu)先級 } pend_task_block(k_curr_task,&mutex->pend_obj,timeout);//阻塞pending的任務(wù) TOS_CPU_INT_ENABLE();//解鎖CPU總線 knl_sched();//解鎖任務(wù)高度 err=pend_state2errno(k_curr_task->pend_state); if(err==K_ERR_NONE){//如果沒有錯誤 TOS_CPU_INT_DISABLE(); mutex_new_owner_mark(mutex,k_curr_task);//刷新mutex當前的owner TOS_CPU_INT_ENABLE(); } returnerr; }

TencentOS tiny信號量的實現(xiàn)

首先來看k_sem_st的結(jié)構(gòu)體：

__STATIC__k_err_tsem_do_post(k_sem_t*sem,opt_post_topt) { TOS_CPU_CPSR_ALLOC();//為CPU的CPSR進行預(yù)分配為后面恢復(fù)做準備 TOS_PTR_SANITY_CHECK(sem); #ifTOS_CFG_OBJECT_VERIFY_EN>0u if(!pend_object_verify(&sem->pend_obj,PEND_TYPE_SEM)){ returnK_ERR_OBJ_INVALID; } #endif TOS_CPU_INT_DISABLE();//CPU鎖定防止其它進程入 if(sem->count==(k_sem_cnt_t)-1){//若資源數(shù)量為-1則返回超限 TOS_CPU_INT_ENABLE(); returnK_ERR_SEM_OVERFLOW; } if(pend_is_nopending(&sem->pend_obj)){//如果無pending的情況則直接返回 ++sem->count; TOS_CPU_INT_ENABLE(); returnK_ERR_NONE; } pend_wakeup(&sem->pend_obj,PEND_STATE_POST,opt);//喚醒pending的進程 TOS_CPU_INT_ENABLE();//恢復(fù)CPU knl_sched();//恢復(fù)任務(wù)調(diào)度 returnK_ERR_NONE; }

所以從上述解讀相信各位讀者也能看到，TencentOS tiny的內(nèi)核的確是被精心修減過，針對物聯(lián)網(wǎng)場景做了相應(yīng)的優(yōu)化，去掉了一些沒有必要的功能代碼。

TencentOS tiny對于MQTT的實現(xiàn)

在TencentOS tiny的官宣中對于IoT 協(xié)議棧介紹如下：TencentOS tiny 提供 lwip、AT Adapter、SAL 層，支持不同的網(wǎng)絡(luò)硬件，例如以太網(wǎng)、串口 Wi-Fi、GPRS、NB-IoT、4G等通信模塊。TCP/IP 網(wǎng)絡(luò)協(xié)議棧上提供常用的物聯(lián)網(wǎng)協(xié)議棧，例如 CoAP、MQTT，支撐終端業(yè)務(wù)快速接入騰訊云。其中MQTT可以算是物聯(lián)網(wǎng)時代比較通用的基于IP網(wǎng)絡(luò)的協(xié)議了，它基于發(fā)布/訂閱消息模式，提供一對多的消息分發(fā)有三種消息傳遞服務(wù)質(zhì)量。1.最多一次，也就是消息發(fā)布者只會發(fā)布一次消息，不管對端是否收到也不會發(fā)布第二次。一般用于環(huán)境傳感器的數(shù)據(jù)讀取，因為一般環(huán)境傳感器讀取的密度很高，丟失幾個數(shù)據(jù)并沒有什么大問題。·2.確保到達，這個一般用在數(shù)據(jù)非常重要的情況，發(fā)送端將不斷重復(fù)發(fā)送直到對端響應(yīng)收到。但這樣可能出現(xiàn)數(shù)據(jù)重復(fù)。3.確保恰好一次送達，確保消息正好到達一次。這個級別用于計費系統(tǒng)，重復(fù)或丟失的數(shù)據(jù)可能導(dǎo)致一定的損失。由于MQTT適合在低帶寬、高延時網(wǎng)絡(luò)運行的特性所以在特聯(lián)網(wǎng)中的應(yīng)用很多。不過呢騰訊針對此部分的實現(xiàn)則是完全拷貝于Eclipse Paho項目個人制作的原理動畫如下圖：

但是考慮到物聯(lián)網(wǎng)終端其實僅需要MQTT的發(fā)布方即可，訂閱方的代碼其實沒有太大必要保留，而且從目前發(fā)布支持的場景來看，MQTT一些通訊質(zhì)量模式其實用處也不多，不過在這方面TencentOS tiny是沒有做任何優(yōu)化與裁減的。所以這應(yīng)該也可以看做是TencentOS tiny的一個不足吧。

后記

隨著移動互聯(lián)網(wǎng)+智能硬件的不斷發(fā)展，IoT的新業(yè)態(tài)大門徐徐開啟，這里不但有眾多互聯(lián)網(wǎng)企業(yè)，也有傳統(tǒng)家電甚至金融企業(yè)不斷入局。但是與傳統(tǒng)互聯(lián)網(wǎng)軟件+硬件的模式不同，物聯(lián)網(wǎng)除了軟、硬件外還多了一個側(cè)面-場景，能將軟、硬件及場景整合化一的公司才能笑到最后。就像HTML整合了互聯(lián)網(wǎng)一樣，MQTT等loT協(xié)議會是整合全鏈條的利器，所以最后筆者也呼吁各方除了重視操作系統(tǒng)內(nèi)核外也需要大力參與loT通訊協(xié)議，尤其注重標準制訂，這樣才能跟上loT的時代潮流。