梅科尔工作室-#14天鸿蒙设备开发实战#内核开发笔记 原创 精华
目录
HarmonyOS内核开发
内核指的是LiteOS-m内核
任务管理
参考:
任务管理简介
- 从系统的角度看,任务是竞争系统资源的最小运行单元。任务可以使用或等待CPU、使用内存空间等系统资源,并独立于其它任务运行。
- LiteOS的任务模块可以给用户提供多个任务,实现了任务之间的切换和通信,帮助用户管理业务程序流程。这样用户可以将更多的精力投入到业务功能的实现中。
- LiteOS中的任务是抢占式调度机制,高优先级的任务可打断低优先级任务,低优先级任务必须在高优先级任务阻塞或结束后才能得到调度,同时支持时间片轮转调度方式。
- LiteOS的任务默认有32个优先级(0-31),最高优先级为0,最低优先级为31。(具体有多少个优先级,可以让用户自己去配置)
任务的相关概念
任务即是线程
-
任务状态
- 任务状态通常分为以下四种:
- 就绪(Ready):该任务在就绪列表中,只等待CPU。
- 运行(Running):该任务正在执行。
- 阻塞(Blocked):该任务不在就绪列表中。包含任务被挂起、任务被延时、任务正在等待信号量、读写队列或者等待读 写事件等。
- 退出态(Dead):该任务运行结束,等待系统回收资源。
- 任务状态通常分为以下四种:
-
任务ID: 在任务创建时通过参数返回给用户,作为任务的一个非常重要的标识。
-
任务优先级: 优先级表示任务执行的优先顺序。 任务入口函数:每个新任务得到调度后将执行的函数。
-
任务控制块TCB: 每一个任务都含有一个任务控制块(TCB)。TCB包含了任务上下文栈指针(stack pointer)、任务状态、任务优先级、任务ID、任务名、任务栈大小等信息。TCB可以反映出每个任务运行情况。
-
任务栈: 每一个任务都拥有一个独立的栈空间,我们称为任务栈。
-
任务上下文: 任务在运行过程中使用到的一些资源,如寄存器等,我们称为任务上下文。LiteOS在任务挂起的时候会将本任务的任务上下文信息,保存在自己的任务栈里面,以便任务恢复后,从栈空间中恢复挂起时的上下文信息,从而继续执行被挂起时被打断的代码。
-
任务切换: 任务切换包含获取就绪列表中最高优先级任务、切出任务上下文保存、切入任务上下文恢复等动作。
任务的调度机制
任务状态迁移说明
就绪态→运行态: 任务创建后进入就绪态,发生任务切换时,就绪列表中最高优先级的任务被执行,从而进入运行态,但此刻该任务依旧在就绪列表中。
运行态→阻塞态: 任务运行因挂起、延时、获取互斥锁、读消息、读信号量等待等,在就绪列表中被删除进入阻塞。
阻塞态→就绪态(阻塞态→运行态): 阻塞的任务被恢复后(任务恢复、延时时间超时、读信号量超时或读到信号量等),此时被恢复的任务会被加入就绪列表,从而由阻塞态变成就绪态;此时如果被恢复任务的优先级高于正在运行任务的优先级,则会发生任务切换,将该任务由就绪态变成运行态。
就绪态→阻塞态: 任务也有可能在就绪态时被阻塞(挂起)。
运行态→就绪态: 有更高优先级任务创建或者恢复后,发生任务切换而进入就绪列表。
运行态→退出态: 任务运行结束,内核自动将此任务删除,此时由运行态变为退出态。
阻塞态→退出态: 阻塞的任务调用删除接口,任务状态由阻塞态变为退出态。
实现任务的管理
cmsis_os2的API任务接口简介
接口名 | 功能描述 |
---|---|
osThreadNew | 创建任务 |
osThreadTerminate | 删除某个任务(一般是对非自任务操作) |
osThreadSuspend | 任务挂起 |
osThreadResume | 任务恢复 |
-
创建任务: osThreadNew(osThreadFunc_t func,void * argument,const osThreadAttr_t * attr)
-
删除某个任务: osThreadTerminate(osThreadId_t thread_id);
-
任务挂起: osThreadSuspend(osThreadId_t thread_id)
-
任务恢复: osThreadResume (osThreadId_t thread_id)
创建任务接口详解
osThreadNew(osThreadFunc_t func, void * argument, const osThreadAttr_t * attr)
名称 | 描述 |
---|---|
func | 任务函数 |
argument | 作为启动参数传递给任务函数的指针 |
attr | 任务入口函数的参数列表 |
返回值 | 任务ID |
源码:在applications\BearPi\BearPi-HM_Nano\sample\A1_kernal_thread\thread_example.c
路径下,以下添加了部分注释
当两个任务优先级相同的时候,先创建的任务先运行
前面讲的是LiteOS中的任务优先级,现在讲的是cmsis-rtos接口封装后的任务优先级,这两个的规则是相反的
修改applications\BearPi\BearPi-HM_Nano\sample
路径下BUILD.gn,指定 thread_example
,编译、烧录、打印日志(不再描述,可参考前两篇博客)
结果如下
实验结果与扩展实验
实验现象:高优先级任务抢占低优先级任务进行运行,高优先级任务被挂起后,低优先级任务才能继续运行,最后两个任务都删除退出
源码
编译、烧录、打印日志
日志如下:
定时器管理
参考:
软件定时器基本概念
软件定时器,是基于系统Tick时钟中断且由软件来模拟的定时器,当经过设定的Tick时钟计数值后会触发用户定义的回调函数。定时精度与系统Tick时钟的周期有关。
硬件定时器受硬件的限制,数量上不足以满足用户的实际需求,因此为了满足用户需求,提供更多的定时器,LiteOS操作系统提供软件定时器功能。
软件定时器扩展了定时器的数量,允许创建更多的定时业务。
软件定时器功能上支持:
-
静态裁剪:能通过宏关闭软件定时器功能。
-
软件定时器创建。
-
软件定时器启动。
-
软件定时器停止。
-
软件定时器删除。
-
软件定时器剩余Tick数获取。
软件定时器运作机制
软件定时器使用了系统的一个队列和一个任务资源,软件定时器的触发遵循队列规则,先进先出。定时时间短的定时器总是比定时时间长的靠近队列头,满足优先被触发的准则。
软件定时器以Tick为基本计时单位,当用户创建并启动一个软件定时器时,Huawei LiteOS会根据当前系统Tick时间及用户设置的定时间隔确定该定时器的到期Tick时间,并将该定时器控制结构挂 入计时全局链表。
当Tick中断到来时,在Tick中断处理函数中扫描软件定时器的计时全局链表,看是否有定时器超时, 若有则将超时的定时器记录下来。
Tick中断处理函数结束后,软件定时器任务(优先级为最高)被唤醒,在该任务中调用之前记录下 来的定时器的超时回调函数。
实现软件定时器创建
cmsis_os2的API软件定时器接口简介
接口名 | 功能描述 |
---|---|
osTimerNew | 创建定时器 |
osTimerStart | 启动定时器 |
osTimerStop | 停止定时器 |
osTimerDelete | 删除定时器 |
- 创建定时器:osTimerNew (osTimerFunc_t func, osTimerType_t type, void *argument, const osTimerAttr_t *attr);
- 启动定时器:osTimerStart (osTimerId_t timer_id, uint32_t ticks);
- 停止定时器:osTimerStop (osTimerId_t timer_id);
- 删除定时器:osTimerDelete (osTimerId_t timer_id);
接口源码在kernel\liteos_m\components\cmsis\2.0\cmsis_os2.h
中
官方案例:applications\BearPi\BearPi-HM_Nano\sample\A2_kernel_timer\Timer_example.c
路径下,以下添加了部分注释
修改applications\BearPi\BearPi-HM_Nano\sample
路径下BUILD.gn,指定 timer_example
,编译、烧录、打印日志
日志结果:
软件定时器扩展实验
定时器的停止与删除
源码:
编译、烧录、打印日志
日志结果:
对于单次定时器,只有在定时器运行期间才能停止定时器,而删除定时器可以是任何时候
信号量
参考:
信号量基本概念
1、信号量(Semaphore)是一种实现任务间通信的机制,实现任务之间同步或临界资源的互斥访问。常用于协助一组相互竞争的任务来访问临界资源。
2、在多任务系统中,各任务之间需要同步或互斥实现临界资源的保护,信号量功能可以为用户提供这方面的支持。
3、通常一个信号量的计数值用于对应有效的资源数,表示剩下的可被占用的互斥资源数。其值的含义分两种情况:
1)0,表示没有积累下来的Post信号量操作,且有可能有在此信号量上阻塞的任务。
2)正值,表示有一个或多个Post信号量操作。
4、以同步为目的的信号量和以互斥为目的的信号量在使用有如下不同:
1)用作互斥时,信号量创建后记数是满的,在需要使用临界资源时,先取信号量,使其变空,这样其他任务需要使用临界资源时就会因为无法取到信号量而阻塞,从而保证了临界资源的安全。
2)用作同步时,信号量在创建后被置为空,任务1取信号量而阻塞,任务2在某种条件发生后,释放信号量,于是任务1得以进入READY或RUNNING态,从而达到了两个任务间的同步。
信号量运作机制
信号量运作原理
1、信号量初始化,为配置的N个信号量申请内存(N值可以由用户自行配置,受内存限制),并把所有的信号量初始化成未使用,并加入到未使用链表中供系统使用。
2、信号量创建,从未使用的信号量链表中获取一个信号量资源,并设定初值。
3、信号量申请,若其计数器值大于0,则直接减1返回成功。否则任务阻塞,等待其它任务释放该信号量,等待的超时时间可设定。当任务被一个信号量阻塞时,将该任务挂到信号量等待任务队列的队尾。
4、信号量释放,若没有任务等待该信号量,则直接将计数器加1返回。否则唤醒该信号量等待任务队列上的第一个任务。
5、信号量删除,将正在使用的信号量置为未使用信号量,并挂回到未使用链表
6、信号量允许多个任务在同一时刻访问同一资源,但会限制同一时刻访问此资源的最大任务数目。访问同一资源的任务数达到该资源的最大数量时,会阻塞其他试图获取该资源的任务,直到有任务释放该信号量。
信号量运作示意图
公共资源有四个任务数,信号量都分别被线程1、2、3、4获取后,此时此资源就会锁定而不让线程5进入,线程5及后面的线程都进入阻塞模式,当线程1工作完成而释放出信号量,线程5立即获得信号而得到执行。如此往复。
实现信号量功能
cmsis_os2的API信号量接口简介
接口名 | 功能描述 |
---|---|
osSemaphoreNew | 创建信号量 |
osSemaphoreAcquire | 获取信号量 |
osSemaphoreRelease | 释放信号量 |
osSemaphoreDelete | 删除信号量 |
- 创建信号量:osSemaphoreNew (uint32_t max_count, uint32_t initial_count, const osSemaphoreAttr_t *attr);
- 获取信号量:osSemaphoreAcquire (osSemaphoreId_t semaphore_id, uint32_t timeout);
- 释放信号量:osSemaphoreRelease (osSemaphoreId_t semaphore_id);
- 删除信号量:osMutexDelete (osMutexId_t mutex_id);
描述:
函数osSemaphoreRelease释放由参数semaphore_id指定的信号量对象的标记
注意 :该函数可以在中断服务例程调用
参数:
名字 | 描述 |
---|---|
semaphore_id | 由osSemaphoreNew获得的信号量ID |
案例代码在applications\BearPi\BearPi-HM_Nano\sample\A5_kernel_semaphore\Semaphore_example.c
路径下,以下添加了部分注释:
每释放一次信号量计数值加1,每申请一次信号量计数器减1,能不能申请到取决于信号量计数值是否大于0,计数值是否大于0的时候才能申请成功,否则申请失败
修改applications\BearPi\BearPi-HM_Nano\sample
路径下BUILD.gn,指定 semaphore_example
,编译、烧录、打印日志
日志结果:
信号量扩展实验
osSemaphoreAcquire超时时间的使用
描述:
阻塞函数osSemaphoreAcquire一直等待,直到由参数semaphore_id指定的信号量对象的标记可用为止。如果一个令牌可用,该函数立即返回并递减令牌计数。
注意:如果参数timeout设置为0,可以从中断服务例程调用。
参数:
名字 | 描述 |
---|---|
semaphore_id | 由osSemaphoreNew获得的信号量ID |
timeout | 超时值 |
编译、烧录、打印日志
日志结果:
osSemaphoreDelete的使用
删除指定的信号量,删除之后再执行获取信号量、释放信号量等操作都会失败
编译、烧录、打印日志
日志结果:
事件管理
参考:
事件基本概念
事件是一种实现任务间通信的机制,可用于实现任务间的同步,但事件通信只能是事件类型的通信,无数据传输。一个任务可以等待多个事件的发生:可以是任意一个事件发生时唤醒任务进行事件处理;也可以是几个事件都发生后才唤醒任务进行事件处理。事件集合用32位无符号整型变量来表示,每一位代表一个事件。
多任务环境下,任务之间往往需要同步操作。事件可以提供一对多、多对多的同步操作。一对多同步模型:一 个任务等待多个事件的触发;多对多同步模型:多个任务等待多个事件的触发。
任务可以通过创建事件控制块来实现对事件的触发和等待操作。LiteOS的事件仅用于任务间的同步。
事件运作机制
读事件时,可以根据入参事件掩码类型uwEventMask读取事件的单个或者多个事件类型。事件读取成功后,如果设置LOS_WAITMODE_CLR会清除已读取到的事件类型,反之不会清除已读到的事件类型,需显式清除。可以通过入参选择读取模式,读取事件掩码类型中所有事件还是读 取事件掩码类型中任意事件。
写事件时,对指定事件写入指定的事件类型,可以一次同时写多个事件类型。写事件会触发任务调度。
清除事件时,根据入参事件和待清除的事件类型,对事件对应位进行清0操作。
实现事件功能
cmsis_os2的API事件接口简介
接口名 | 功能描述 |
---|---|
osEventFlagsNew | 创建事件标记对象 |
osEventFlagsSet | 设置事件标记 |
osEventFlagsWait | 等待事件标记触发 |
osEventFlagsDelete | 删除事件标记对象 |
创建事件标记对象: osEventFlagsNew (const osEventFlagsAttr_t *attr);
设置事件标记: osEventFlagsSet (osEventFlagsId_t ef_id, uint32_t flags);
等待事件标记触发: osEventFlagsWait (osEventFlagsId_t ef_id, uint32_t flags, uint32_t options, uint32_t timeout);
删除事件标记对象: osEventFlagsDelete (osEventFlagsId_t ef_id);
案例代码在applications\BearPi\BearPi-HM_Nano\sample\A3_kernel_event\Event_example.c
路径下,以下添加了部分注释:
修改applications\BearPi\BearPi-HM_Nano\sample
路径下BUILD.gn,指定 event_example
,编译、烧录、打印日志
日志结果:
事件扩展实验
编译、烧录、打印日志
日志结果:
互斥锁
参考:
互斥锁基本概念
-
互斥锁又称互斥型信号量,是一种特殊的二值性信号量,用于实现对共享资源的独占式处理。
-
任意时刻互斥锁的状态只有两种:开锁或闭锁。
-
当有任务持有时,互斥锁处于闭锁状态,这个任务获得该互斥锁的所有权。
-
当该任务释放时,该互斥锁被开锁,任务失去该互斥锁的所有权。
-
当一个任务持有互斥锁时,其他任务将不能再对该互斥锁进行开锁或持有。
-
多任务环境下往往存在多个任务竞争同一共享资源的应用场景,互斥锁可被用于对共享资源的保护从而实现独占式访问。另外,互斥锁可以解决信号量存在的优先级翻转问题。
-
LiteOS提供的互斥锁具有如下特点: 通过优先级继承算法,解决优先级翻转问题。
互斥锁运作机制
多任务环境下会存在多个任务访问同一公共资源的场景,而有些公共资源是非共享的,需要任务进行独占式处理。互斥锁怎样来避免这种冲突呢?用互斥锁处理非共享资源的同步访问时,如果有任务访问该资源,则互斥锁为加锁状态。此时其他任务如果想访问这个公共资源则会被阻塞,直到互斥锁被持有该锁的任务释放后,其他任务才能重新访问该公共资源,此时互斥锁再次上锁,如此确保同一时刻只有一个任务正在访问这个公共资源,保证了公共资源操作的完整性。
实现互斥锁功能
cmsis_os2的API互斥锁接口简介
接口名 | 功能描述 |
---|---|
osMutexNew | 创建互斥锁 |
osMutexAcquire | 获取互斥锁 |
osMutexRelease | 释放互斥锁 |
osMutexDelete | 删除互斥锁 |
创建互斥锁: osMutexNew (const osMutexAttr_t *attr);
获取互斥锁: osMutexAcquire (osMutexId_t mutex_id, uint32_t timeout);
释放互斥锁: osMutexRelease (osMutexId_t mutex_id);
删除互斥锁: osMutexDelete (osMutexId_t mutex_id);
案例代码在applications\BearPi\BearPi-HM_Nano\sample\A4_kernel_mutex\Mutex_example.c
目录下,以下添加了部分注释:
修改applications\BearPi\BearPi-HM_Nano\sample
路径下BUILD.gn,指定 mutex_example
,编译、烧录、打印日志
日志结果:
互斥锁扩展实验
编译、烧录、打印日志
日志结果:
消息队列
参考:
消息队列基本概念
消息队列,是一种常用于任务间通信的数据结构,实现了接收来自任务或中断的不固定长度的消息,并根据不同的接口选择传递消息是否存放在自己空间。任务能够从队列里面读取消息,当队列中的消息是空时,挂起读取任务;当队列中有新消息时,挂起的读取任务被唤醒并处理新消息。
用户在处理业务时,消息队列提供了异步处理机制,允许将一个消息放入队列,但并不立即处理它,同时队列还能起到缓 冲消息作用。
LiteOS中使用队列数据结构实现任务异步通信工作,具有如下特性:
- 消息以先进先出方式排队,支持异步读写工作方式。
- 读队列和写队列都支持超时机制。
- 发送消息类型由通信双方约定,可以允许不同长度(不超过队列节点最大值)消息。
- 一个任务能够从任意一个消息队列接收和发送消息。
- 多个任务能够从同一个消息队列接收和发送消息。
- 当队列使用结束后,如果是动态申请的内存,需要通过释放内存函数回收。
消息队列运作机制
创建队列时,根据用户传入队列长度和消息节点大小来开辟相应的内存空间以供该队列使用,返回队列ID。
在队列控制块中维护一个消息头节点位置Head和一个消息尾节点位置Tail来表示当前队列中消息存储情况。Head表示队列中被占用消息的起始位置。Tail表示队列中被空闲消息的起始位置。刚创建时Head和Tail均指向队列起始位置。
写队列时,根据Tail找到被占用消息节点末尾的空闲节点作为数据写入对象。
读队列时,根据Head找到最先写入队列中的消息节点进行读取。
删除队列时,根据传入的队列ID寻找到对应的队列,把队列状态置为未使用,释放原队列所占的空间,对应的队列控制头置为初始状态。
实现消息队列功能
cmsis_os2的API消息队列接口简介
接口名 | 功能描述 |
---|---|
osMessageQueueNew | 创建消息队列 |
osMessageQueuePut | 发送消息 |
osMessageQueueGet | 获取消息 |
osMessageQueueDelete | 删除消息队列 |
创建消息队列: osMessageQueueNew(uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr)
发送消息: osMessageQueuePut(osMessageQueueId_t mq_id, const void *msg_ptr, uint8_t msg_prio, uint32_t timeout);
获取消息: osMessageQueueGet(osMessageQueueId_t mq_id, void *msg_ptr, uint8_t *msg_prio, uint32_t timeout);
删除消息队列: osMessageQueueDelete(osMessageQueueId_t mq_id);
案例代码在applications\BearPi\BearPi-HM_Nano\sample\A6_kernel_message\Message_example.c
目录下,以下添加了部分注释:
修改applications\BearPi\BearPi-HM_Nano\sample
路径下BUILD.gn,指定 message_example
,编译、烧录、打印日志
日志结果:
消息队列扩展实验
编译、烧录、打印日志
日志结果:
疑问: 为什么删除消息队列后,消息队列中的消息数一直为16(看了看osMessageQueueGetCount
实现源码,难道最后返回的是消息队列中可写的资源数?还望大佬指点)
osMessageQueueGetCount
源码附上:
6个官方案例及修改后的扩展实验源码见附件
感悟
从后面几节的学习来看,任务管理是最基础也是必须要掌握的一部分,后面的定时器、信号量、事件管理、互斥锁、消息队列都要用到任务的相关内容。官方给出的案例较为容易理解,但是扩展实验部分有些难度,尤其是在信号量部分,用了很多精力才能勉强理解,上面也写出了自己的思路(讲述不周之处还请多多包涵)。通过比较这6块内容,可以发现这6块的常用接口之间还是有一些相同之处的,都会有创建…、删除…,另外就是启动、恢复或者停止、挂起,其中的参数也很相似。官方给的源码中每一个案例附带的README.md文档,里面给出了一些常用接口的介绍,很有必要看一下,虽然有些抽象,但根据实例去理解收获还是蛮大的。内核开发部分学习耗费的时间有些多,后面四章内容需要加快进度,继续努力!!!
大佬讲解已经非常详细了,社区之前也有大佬写过类似的文章,也可以做个参考。
鸿蒙内核源码分析主页:https://ost.51cto.com/user/posts/14930441
zhushangyuan_主页:https://ost.51cto.com/user/posts/14238748
感谢感谢
学习中