幕布：
文档链接: https://www.mubucm.com/doc/4za3i_lwKWm
密码: jiza

课程链接：
https://www.bilibili.com/video/BV1tv411b7SA?spm_id_from=333.999.0.0

文章目录

• HarmonyOS内核开发
• • 1. 任务管理
  • • 1.1 基本概念：
    • • • 1.1.1 任务（系统角度）
        • 1.1.2 LiteOS 的任务模块的作用
        • 1.1.3 LiteOS 的任务调度机制
        • 1.1.4 LiteOS 的优先级
    • 1.2 任务状态：
    • • • 1.2.1 就绪（Ready）
        • 1.2.2 运行（Running）
        • 1.2.3 阻塞（Blocked）
        • 1.2.4 退出态（Dead）
    • 1.3 任务相关概念：
    • • • 1.3.1 任务ID
        • 1.3.2 任务优先级
        • 1.3.3 任务入口函数
        • 1.3.4 任务控制块TCB
        • 1.3.5 任务栈
        • 1.3.6 任务上下文
        • 1.3.7 任务切换
    • 1.4 任务的调度机制：
    • • 1.4.1 任务状态迁移说明：
      • • 1.4.1.1 就绪态→运行态：
        • 1.4.1.2 运行态→阻塞态：
        • 1.4.1.3 阻塞态→就绪态（阻塞态→运行态）：
        • 1.4.1.4 就绪态→阻塞态：
        • 1.4.1.5 运行态→就绪态：
        • 1.4.1.6 运行态→退出态：
        • 1.4.1.7 阻塞态→退出态：
    • 1.5 实现任务的创建：
    • • 1.5.1 创建任务接口：
    • 1.6 实验结果与扩展实验
    • • 1.6.1 扩展实验代码
  • 2. 软件定时器
  • • 2.1 软件定时器的基本概念
    • • 2.1.1 软件定时器的概念
      • 2.1.2 软件定时器的功能支持：
    • 2.2 软件定时器运作机制
    • 2.3 实现软件定时器创建
    • • 2.3.1 cmsis_os2的API软件定时器接口简介：
    • 2.4 软件定时器拓展实验
    • • 2.4.1 拓展实验代码：
  • 3. 信号量
  • • 3.1 信号量基本概念
    • • 3.1.1 信号量的概念
    • 3.2 信号量运作机制
    • • 3.2.1 运作原理
      • 3.2.2 信号量运作示意图：
    • 3.3 实现信号量功能
    • • 3.3.1 cmsis_os2的API信号量接口简介：
    • 3.4 信号量扩展实验
    • • 3.4.1 扩展实验代码：
  • 4. 事件管理
  • • 4.1 事件基本概念
    • 4.2 事件运作机制
    • 4.3 实现事件功能
    • • 4.3.1 cmsis_os2的API事件接口简介：
    • 4.4 事件拓展实验
    • • 4.4.1 拓展实验代码：
  • 4. 互斥锁
  • • 4.1 互斥锁基本概念
    • • 4.1.1 互斥锁的概念：
      • 4.1.2 LiteOS提供的互斥锁具有如下特点：
    • 4.2 互斥锁运作机制
    • • 4.2.1 运作原理
    • 4.3 实现互斥锁功能
    • • 4.3.1 cmsis_os2的API互斥锁接口简介：
    • 4.4 互斥锁扩展实验
    • • 4.4.1 扩展实验代码
  • 5. 消息队列
  • • 5.1 消息队列基本概念
    • • 5.1.1 消息队列的概念：
      • 5.1.2 LiteOS中使用队列数据结构实现任务异步通信工作，具有如下特性：
    • 5.2 消息队列运作机制
    • • 5.2.1 运作原理
    • 5.3 实现消息队列功能
    • • 5.3.1 cmsis_os2的API消息队列接口简介：
    • 5.4 消息队列扩展实验
    • • 5.4.1 扩展实验代码

HarmonyOS内核开发

1. 任务管理

1.1 基本概念：

1.1.1 任务（系统角度）

从系统的角度看，任务是竞争系统资源的最小运行单元。任务可以使用或等待CPU、使用内存空间等系统资源，并独立于其它任务运行。

1.1.2 LiteOS 的任务模块的作用

LiteOS的任务模块可以给用户提供多个任务，实现了任务之间的切换和通信，帮助用户管理业务程序流程。这样用户可以将更多的精力投入到业务功能的实现中。

1.1.3 LiteOS 的任务调度机制

LiteOS中的任务是抢占式调度机制，高优先级的任务可打断低优先级任务，低优先级任务必须在高优先级任务阻塞或结束才能得到调度，同时支持时间片轮转调度方式。

1.1.4 LiteOS 的优先级

LiteOS的任务默认有32个优先级（0-31），最高优先级为0，最低优先级为31.

1.2 任务状态：

1.2.1 就绪（Ready）

该任务在就绪列表中，只等待CPU。

1.2.2 运行（Running）

该任务正在执行。

1.2.3 阻塞（Blocked）

该任务不在就绪列表中。包含任务被挂起、任务被延时、任务正在等待信号量、读写队列或者等待读写事件等。

1.2.4 退出态（Dead）

该任务运行结束，等待系统回收资源。

1.3 任务相关概念：

1.3.1 任务ID

在任务创建时通过参数返回给用户，作为任务的一个非常重要的标识。

1.3.2 任务优先级

优先级表示任务执行的优先顺序。

1.3.3 任务入口函数

每个新任务得到调度后将执行的函数。

1.3.4 任务控制块TCB

每一个任务都含有一个任务控制块(TCB)。TCB包含了任务上下文栈指针(stack pointer)、任务状态、任务优先级、任务ID、任务栈大小等信息。TCB可以反映出每个任务运行情况。

1.3.5 任务栈

每一个任务 都拥有一个独立的栈空间，我们称为任务栈。

1.3.6 任务上下文

任务在运行过程中使用到的一些资源，如寄存器等，我们称为任务上下文。LiteOS在任务挂起的时候会将本任务的任务上下文信息，保存在自己的任务栈里面，以便任务恢复后，从栈空间中恢复挂起时的上下文信息，从而继续执行被挂起时被挂起时被打断的代码。

1.3.7 任务切换

任务切换包含获取就绪列表中最高优先级获取任务、切出任务上下文保存、切入任务上下文恢复等动作。

1.4 任务的调度机制：

1.4.1 任务状态迁移说明：

1.4.1.1 就绪态→运行态：

任务创建后进入就绪态，发生任务切换时，就绪列表中最高优先级的任务被执行，从而进入运行态，但此刻该任务依旧在就绪列表中。

1.4.1.2 运行态→阻塞态：

任务运行因挂起、读信号量等待等，在就绪列表中被删除进入阻塞。

1.4.1.3 阻塞态→就绪态（阻塞态→运行态）：

阻塞的任务被恢复后（任务恢复、延时时间超时、读信号量超时或读到信号量等），此时被恢复的任务会被加入就绪列表，从而由阻塞态变成就绪态；此时如果被恢复任务的优先级高于正在运行任务的优先级，则会发生任务切换，将该任务由就绪态变成运行态。

1.4.1.4 就绪态→阻塞态：

任务也有可能在就绪态时被阻塞（挂起）。

1.4.1.5 运行态→就绪态：

有更高优先级任务创建或者恢复后，发生任务切换而进入就绪列表。

1.4.1.6 运行态→退出态：

任务运行结束，内核自动将此任务删除，此时由运行态变为退出态。

1.4.1.7 阻塞态→退出态：

阻塞的任务调用删除接口，任务状态由阻塞态变为退出态。

1.5 实现任务的创建：

1.5.1 创建任务接口：

osThreadNew(osThreadFunc_t func, void * argument, const osThreadAttr_t * attr)

1.6 实验结果与扩展实验

1.6.1 扩展实验代码

2. 软件定时器

2.1 软件定时器的基本概念

2.1.1 软件定时器的概念

1. 软件定时器，是基于系统Tick时钟中断且由软件来模拟的定时器，当经过设定的Tick时钟计数值后会触发用户定义的回调函数。定时精度与系统Tick时钟的周期有关。
2. 硬件定时器受硬件的限制，数量上不足以满足用户的实际需求，因此为了满足用户需求，提供更多的定时器，LiteOS操作系统提供软件定时器功能。
3. 软件定时器扩展了定时器的数量，允许创建更多的定时业务。

2.1.2 软件定时器的功能支持：

1. 静态裁剪：能通过宏关闭软件定时器功能。
   ● 软件定时器创建。
   ● 软件定时器启动。
   ● 软件定时器停止。
   ● 软件定时器删除。
   ● 软件定时器剩余Tick数获取。

2.2 软件定时器运作机制

1. 软件定时器使用了系统的一个队列和一个任务资源，软件定时器的触发遵循队列规则，先进先出。定时时间短的定时器总是比定时时间长的靠近队列头，满足优先被触发的准则。
2. 软件定时器以Tick为基本计时单位，当用户创建并启动一个软件定时器时，Huawei LiteOS会根据当前系统Tick时间及用户设置的定时间隔确定该定时器的到期Tick时间，并将该定时器控制结构挂入计时全局链表。
3. 当Tick中断到来时，在Tick中断处理函数中扫描软件定时器的计时全局链表，看是否有定时器超时，若有则将超时的定时器记录下来。
4. Tick中断处理函数结束后，软件定时器任务（优先级为最高）被唤醒，在该任务中调用之前记录下来的定时器的超时回调函数。

2.3 实现软件定时器创建

2.3.1 cmsis_os2的API软件定时器接口简介：

1. 创建定时器：

osTimerNew (osTimerFunc_t func, osTimerType_t type, void *argument, const osTimerAttr_t *attr);

2. 启动定时器：

osTimerStart (osTimerId_t timer_id, uint32_t ticks);

3. 停止定时器：

osTimerStop (osTimerId_t timer_id);

4. 删除定时器：

osTimerDelete (osTimerId_t timer_id);

2.4 软件定时器拓展实验

2.4.1 拓展实验代码：

3. 信号量

3.1 信号量基本概念

3.1.1 信号量的概念

1. 信号量（Semaphore）是一种实现任务间通信的机制，实现任务之间同步或临界资源的互斥访问。常用于协助一组相互竞争的任务来访问临界资源。
2. 在多任务系统中，各任务之间需要同步或互斥实现临界资源的保护，信号量功能可以为用户提供这方面的支持。
3. 通常一个信号量的计数值用于对应有效的资源数，表示剩下的可被占用的互斥资源数。其值的含义分两种情况：
   1. 0，表示没有积累下来的Post信号量操作，且有可能有在此信号量上阻塞的任务。
   2. 正值，表示有一个或多个Post信号量操作。
4. 以同步为目的的信号量和以互斥为目的的信号量在使用有如下不同：
   1. 用作互斥时，信号量创建后记数是满的，在需要使用临界资源时，先取信号量，使其变空，这样其他任务需要使用临界资源时就会因为无法取到信号量而阻塞，从而保证了临界资源的安全。
   2. 用作同步时，信号量在创建后被置为空，任务1取信号量而阻塞，任务2在某种条件发生后，释放信号量，于是任务1得以进入READY或RUNNING态，从而达到了两个任务间的同步。

3.2 信号量运作机制

3.2.1 运作原理

1. 信号量初始化，为配置的N个信号量申请内存（N值可以由用户自行配置，受内存限制），并把所有的信号量初始化成未使用，并加入到未使用链表中供系统使用。
2. 信号量创建，从未使用的信号量链表中获取一个信号量资源，并设定初值。
3. 信号量申请，若其计数器值大于0，则直接减1返回成功。否则任务阻塞，等待其它任务释放该信号量，等待的超时时间可设定。当任务被一个信号量阻塞时，将该任务挂到信号量等待任务队列的队尾。
4. 信号量释放，若没有任务等待该信号量，则直接将计数器加1返回。否则唤醒该信号量等待任务队列上的第一个任务。
5. 信号量删除，将正在使用的信号量置为未使用信号量，并挂回到未使用链表。
6. 信号量允许多个任务在同一时刻访问同一资源，但会限制同一时刻访问此资源的最大任务数目。访问同一资源的任务数达到该资源的最大数量时，会阻塞其他试图获取该资源的任务，直到有任务释放该信号量。

3.2.2 信号量运作示意图：

• 公共资源有四个任务数，信号量都分别被线程1、2、3、4获取后，此时此资源就会锁定而不让线程5进入，线程5及后面的线程都进入阻塞模式，当线程1工作完成而释放出信号量，线程5立即获得信号而得到执行。如此往复

3.3 实现信号量功能

3.3.1 cmsis_os2的API信号量接口简介：

1. 创建互斥锁：

osSemaphoreNew (uint32_t max_count, uint32_t initial_count, const osSemaphoreAttr_t *attr);

2. 获取互斥锁：

osSemaphoreAcquire (osSemaphoreId_t semaphore_id, uint32_t timeout);

3. 释放互斥锁：

osSemaphoreRelease (osSemaphoreId_t semaphore_id);

4. 删除互斥锁：

osMutexDelete (osMutexId_t mutex_id);

3.4 信号量扩展实验

3.4.1 扩展实验代码：

4. 事件管理

4.1 事件基本概念

1. 事件是一种实现任务间通信的机制，可用于实现任务间的同步，但事件通信只能是事件类型的通信，无数据传输。一个任务可以等待多个事件的发生：可以是任意一个事件发生时唤醒任务进行事件处理;也可以是几个事件都发生后才唤醒任务进行事件处理。事件集合用32位无符号整型变量来表示，每一位代表一个事件。
2. 多任务环境下，任务之间往往需要同步操作。事件可以提供一对多、多对多的同步操作。一对多同步模型：一个任务等待多个事件的触发；多对多同步模型：多个任务等待多个事件的触发。
3. 任务可以通过创建事件控制块来实现对事件的触发和等待操作。LiteOS的事件仅用于任务间的同步。

4.2 事件运作机制

1. 读事件时，可以根据入参事件掩码类型uwEventMask读取事件的单个或者多个事件类型。事件读取成功后，如果设置LOS_WAITMODE_CLR会清除已读取到的事件类型，反之不会清除已读到的事件类型，需显式清除。可以通过入参选择读取模式，读取事件掩码类型中所有事件还是读取事件掩码类型中任意事件。
2. 写事件时，对指定事件写入指定的事件类型，可以一次同时写多个事件类型。写事件会触发任务调度。
3. 清除事件时，根据入参事件和待清除的事件类型，对事件对应位进行清0操作。
4. 图示：
   

4.3 实现事件功能

4.3.1 cmsis_os2的API事件接口简介：

1. 创建事件标记对象：

osEventFlagsNew (const osEventFlagsAttr_t *attr);

2. 设置事件标记：

osEventFlagsSet (osEventFlagsId_t ef_id, uint32_t flags);

3. 等待事件标记触发：

osEventFlagsWait (osEventFlagsId_t ef_id, uint32_t flags, uint32_t options, uint32_t timeout);

4. 删除事件标记对象：

osEventFlagsDelete (osEventFlagsId_t ef_id);

4.4 事件拓展实验

4.4.1 拓展实验代码：

4. 互斥锁

4.1 互斥锁基本概念

4.1.1 互斥锁的概念：

1. 互斥锁又称互斥型信号量，是一种特殊的二值性信号量，用于实现对共享资源的独占式处理。
2. 任意时刻互斥锁的状态只有两种：开锁或闭锁。
3. 当有任务持有时，互斥锁处于闭锁状态，这个任务获得该互斥锁的所有权。
4. 当该任务释放时，该互斥锁被开锁，任务失去该互斥锁的所有权。
5. 当一个任务持有互斥锁时，其他任务将不能再对该互斥锁进行开锁或持有。
6. 多任务环境下往往存在多个任务竞争同一共享资源的应用场景，互斥锁可被用于对共享资源的保护从而实现独占式访问。另外，互斥锁可以解决信号量存在的优先级翻转问题。

4.1.2 LiteOS提供的互斥锁具有如下特点：

通过优先级继承算法，解决优先级翻转问题。

4.2 互斥锁运作机制

4.2.1 运作原理

1. 多任务环境下会存在多个任务访问同一公共资源的场景，而有些公共资源是非共享的，需要任务进行独占式处理。互斥锁怎样来避免这种冲突呢？
   1. 用互斥锁处理非共享资源的同步访问时，如果有任务访问该资源，则互斥锁为加锁状态。此时其他任务如果想访问这个公共资源则会被阻塞，直到互斥锁被持有该锁的任务释放后，其他任务才能重新访问该公共资源，此时互斥锁再次上锁，如此确保同一时刻只有一个任务正在访问这个公共资源，保证了公共资源操作的完整性
      

4.3 实现互斥锁功能

4.3.1 cmsis_os2的API互斥锁接口简介：

1. 创建互斥锁：

osMutexNew (const osMutexAttr_t *attr);

2. 获取互斥锁：

osMutexAcquire (osMutexId_t mutex_id, uint32_t timeout);

3. 释放互斥锁：

osMutexRelease (osMutexId_t mutex_id);

4. 删除互斥锁：

osMutexDelete (osMutexId_t mutex_id);

4.4 互斥锁扩展实验

4.4.1 扩展实验代码

5. 消息队列

5.1 消息队列基本概念

5.1.1 消息队列的概念：

1. 消息队列，是一种常用于任务间通信的数据结构，实现了接收来自任务或中断的不固定长度的消息，并根据不同的接口选择传递消息是否存放在自己空间。任务能够从队列里面读取消息，当队列中的消息是空时，挂起读取任务；当队列中有新消息时，挂起的读取任务被唤醒并处理新消息。
2. 用户在处理业务时，消息队列提供了异步处理机制，允许将一个消息放入队列，但并不立即处理它，同时队列还能起到缓冲消息作用。

5.1.2 LiteOS中使用队列数据结构实现任务异步通信工作，具有如下特性：

1. 消息以先进先出方式排队，支持异步读写工作方式。
2. 读队列和写队列都支持超时机制。
3. 发送消息类型由通信双方约定，可以允许不同长度（不超过队列节点最大值）消息。
4. 一个任务能够从任意一个消息队列接收和发送消息。
5. 多个任务能够从同一个消息队列接收和发送消息。
6. 当队列使用结束后，如果是动态申请的内存，需要通过释放内存函数回收。

5.2 消息队列运作机制

5.2.1 运作原理

1. 创建队列时，根据用户传入队列长度和消息节点大小来开辟相应的内存空间以供该队列使用，返回队列ID。
2. 在队列控制块中维护一个消息头节点位置Head和一个消息尾节点位置Tail来表示当前队列中消息存储情况。Head表示队列中被占用消息的起始位置。Tail表示队列中被空闲消息的起始位置。刚创建时Head和Tail均指向队列起始位置。
3. 写队列时，根据Tail找到被占用消息节点末尾的空闲节点作为数据写入对象。
4. 读队列时，根据Head找到最先写入队列中的消息节点进行读取。
5. 删除队列时，根据传入的队列ID寻找到对应的队列，把队列状态置为未使用，释放原队列所占的空间，对应的队列控制头置为初始状态。

5.3 实现消息队列功能

5.3.1 cmsis_os2的API消息队列接口简介：

1. 创建消息队列：

osMutexNew (const osMutexAttr_t *attr);

2. 发送消息：

osMutexAcquire (osMutexId_t mutex_id, uint32_t timeout);

3. 获取消息：

osMutexRelease (osMutexId_t mutex_id);

4. 删除消息队列：

osMutexDelete (osMutexId_t mutex_id);

5.4 消息队列扩展实验

5.4.1 扩展实验代码