Tencent comprehensive analysis of the latest open-source operating system loT TencentOS tiny!
Author | Ma Chao
Zebian | Hu Weiwei
Recently, Tencent low profile on GitHub open source operating its own loT TencentOS tiny, as of press time, has accumulated more than 2000 Star, caused no small concern.
Because I have done CSDN large embedded version had been a long time moderator, so the first time to https://github.com/Tencent/TencentOS-tiny downloaded all the code for the first time with everyone to interpret.
TencentOS tiny overall architecture
TencentOS tiny RTOS kernel provide a streamlined, its structure is as follows:
The moment that the core part has been developed, and has been completely open source.
Judging from the current situation TencentOS tiny to see, Tencent incoming things related to the chain has been well planned:
Deployment of embedded development board TencentOS tiny's also been produced, so it appears that competition for entrance goose factory will not have the slightest relaxation in the era of things.
Now I will respect the related interpretation TencentOS tiny kernel code and loT part of the agreement.
TencentOS tiny kernel mutex semaphore and Interpretation
TencentOS tiny official document to declare its core described as follows: TencentOS tiny comprises a real-time kernel task management, real-time scheduling, time management, interrupt management, memory management, exception handling, the software timer, linked lists, message queues, semaphores, mutual exclusion lock, event flags and other modules.
Where the timer, message queues, etc. before have had a corresponding presentation, here for everyone to interpret what semaphore and mutex relevant code.
Mutex semaphore and the similarities and differences:
1. mutex semaphore and the most fundamental difference is: mutex values can only be 1 or 0, the signal ranges of values can be defined.
2. Scope semaphore process can also be a thread, and the mutex only thread. In simple terms mutex thread can be achieved using only resource protection, and semaphores can be implemented using a number of protection between multiple threads or processes limited resources.
In a sense mutex is a semaphore only resource available.
About implemented TencentOS tiny mutex, first look at the specific data structure Interpretation of the following:
typedefstructk_mutex_st{
; pend_obj_tpend_obj list of // pendding obj
k_nesting_tpend_nesting; // number
* owner k_task_t; // now owner
k_prio_towner_orig_prio; // now owner
k_list_towner_list;
} k_mutex_t;
For LINUX kernel if we have enough understanding, then we could see through the above data structure, TencentOS Tiny did not consider spin locks, in fact, is optimized for loT scenes, cut scenes support for multi-CPU.
The main kernel code in this location: https: //github.com/Tencent/TencentOS-tiny/tree/master/kernel/core/tos_mutex.c
Below we mainly interpret pend operation functions for which the following:
__API__ k_err_t tos_mutex_pend_timed(k_mutex_t *mutex, k_tick_t timeout)
{
TOS_CPU_CPSR_ALLOC;
k_err_t err;
TOS_PTR_SANITY_CHECK(mutex);
TOS_IN_IRQ_CHECK;
#if TOS_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) {//等待数量如果超限则返回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) { //如果锁已经被占用超时时间为不等待，则直接返回
TOS_CPU_INT_ENABLE;
returnK_ERR_PEND_NOWAIT;
}
if(knl_is_sched_locked) {//如果任务被锁定，则直接返回
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的优先级更低，也就是其数值更大，则调整优先级
}
pend_task_block(k_curr_task, &mutex->pend_obj, timeout);//阻塞pending的任务
TOS_CPU_INT_ENABLE;//解锁CPU总线
knl_sched;//解锁任务高度
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 信号量的实现
首先来看k_sem_st的结构体：
typedefstructk_sem_st{
pend_obj_tpend_obj;//pending的列表
k_sem_cnt_tcount;//关键资源的数量
} k_sem_t;
其信号量实现的相关代码，在以下位置：
https://github.com/Tencent/TencentOS-tiny/tree/master/kernel/core/tos_sem.c
下面我们对于post函数进行解读：
__STATIC__ k_err_t sem_do_post(k_sem_t*sem, opt_post_topt)
{
TOS_CPU_CPSR_ALLOC;//为CPU的CPSR进行预分配为后面恢复做准备
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) {//若资源数量为-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;//恢复CPU
knl_sched;//恢复任务调度
returnK_ERR_NONE;
}
所以从上述解读相信各位读者也能看到，TencentOS tiny的内核的确是被精心修减过，针对物联网场景做了相应的优化，去掉了一些没有必要的功能代码。
TencentOS tiny对于MQTT的实现
在TencentOS tiny的官宣中对于IoT 协议栈介绍如下：TencentOS tiny 提供 lwip、AT Adapter、SAL 层，支持不同的网络硬件，例如以太网、串口 Wi-Fi、GPRS、NB-IoT、4G等通信模块。
TCP/IP 网络协议栈上提供常用的物联网协议栈，例如 CoAP、MQTT，支撑终端业务快速接入腾讯云。
其中MQTT可以算是物联网时代比较通用的基于IP网络的协议了，它基于发布/订阅消息模式，提供一对多的消息分发有三种消息传递服务质量。
1.最多一次，也就是消息发布者只会发布一次消息，不管对端是否收到也不会发布第二次。一般用于环境传感器的数据读取，因为一般环境传感器读取的密度很高，丢失几个数据并没有什么大问题。·
2.确保到达，这个一般用在数据非常重要的情况，发送端将不断重复发送直到对端响应收到。但这样可能出现数据重复。
3.确保恰好一次送达，确保消息正好到达一次。这个级别用于计费系统，重复或丢失的数据可能导致一定的损失。
由于MQTT适合在低带宽、高延时网络运行的特性所以在特联网中的应用很多。不过呢腾讯针对此部分的实现则是完全拷贝于Eclipse Paho项目（网址：http://www.eclipse.org/paho/） 个人制作的原理动画如下图：
但是考虑到物联网终端其实仅需要MQTT的发布方即可，订阅方的代码其实没有太大必要保留，而且从目前发布支持的场景来看，MQTT一些通讯质量模式其实用处也不多，不过在这方面TencentOS tiny是没有做任何优化与裁减的。所以这应该也可以看做是TencentOS tiny的一个不足吧。
后记
随着移动互联网+智能硬件的不断发展，IoT的新业态大门徐徐开启，这里不但有众多互联网企业，也有传统家电甚至金融企业不断入局。但是与传统互联网软件+硬件的模式不同，物联网除了软、硬件外还多了一个侧面-场景，能将软、硬件及场景整合化一的公司才能笑到最后。
就像HTML整合了互联网一样，MQTT等loT协议会是整合全链条的利器，所以最后笔者也呼吁各方除了重视操作系统内核外也需要大力参与loT通讯协议，尤其注重标准制订，这样才能跟上loT的时代潮流。