【RTOS训练营】上节回顾、轻量级队列、轻量级事件组和晚课提问

一：上节回顾

在上次课程中，我们从代码的角度深入探讨了任务通知的内部机制。让我们回顾一下，通过图形和链表的方式展示这些内部机制。

1.1 初始状态

假设初始状态有两个任务，它们的优先级都是n，放在一个就绪链表中。可以看到任务一和任务二，它们的TCB中有一个状态：

TCB.ucNotifyState[0] = taskNOT_WAITING_NOTIFICATION

初始状态表示任务没有在等待通知。

1.2 等待通知

假设一开始并没有人发出通知，任务想要得到通知时就会阻塞，从ready list移到delay list。

TCB.ucNotifyState[0] = taskWAITING_NOTIFICATION

表示任务正在等待通知。

1.3 别的任务发出通知后

当别的任务发出通知后，任务可以从delay list移到ready list。TCB结构中有两个成员：

如果目标任务没有在等待通知，但你仍然给他发了通知，只会记录通知的值并修改状态：

TCB.ucNotifyState[0] = taskNOTIFICATION_RECEIVED

普通队列不使用TCB.ucNotifyState[0]，但使用任务通知模拟的队列则需要使用。

二：轻量级队列

2.1 写队列

注意上述函数的最后一个参数：

• eSetValueWithoutOverwrite：不覆盖
• eSetValueWithOverwrite：覆盖

2.2 读队列

我们先回顾一下普通队列的特点：

1. 队列是一个环形缓冲区，可以存放多个数据，数据大小可以事先指定。
2. 写队列时，如果队列满了，写者可以阻塞。
3. 读队列时，如果队列空了，读者可以阻塞。

再看看任务通知，在TCB结构体中：

任务通知只能保存一个数值，因此使用任务通知实现的轻量级队列只能保存一个32位的数据。

与普通队列的不同点：

2.1 其他任务只能写。 2.2 可以多对一。 2.3 写时不阻塞。

最大的不同是写时不能阻塞。

我们来看示例代码：

一边是发出通知，另一边是等待通知。

看看这个写队列、发送通知的函数：

圈出了两个地方，大家可以与普通队列对比。

这里可以指定是否覆盖。

我们可以看看代码：

三：轻量级事件组

如何设置位？使用的是同一个函数。

作为轻量级队列，操作的是整个值；作为轻量级事件组，操作的是某些位。

使用任务通知，能否像事件组一样，等待指定的位？

不能，一旦有事件就会唤醒任务。

我们来看看代码：

轻幕

轻幕是一个综合性短视频制作平台，诗词、故事、小说等一键成片转视频，让内容传播更生动！

36

查看详情

上图中三个圆圈：

1. set bit
2. 累加
3. 整个赋值

对应：轻量级事件组、轻量级信号量、轻量级队列。

任务通知的唯一、稍微有难点的函数是：

xTaskNotifyWait(ulBitsToClearOnEntry, ulBitsToClearOnExit, pulNotificationValue, xTicksToWait)

1. 第1个参数：调用这个函数时，要不要清除某些位，OnEntry：在函数入口处。
2. 第2个参数：退出这个函数时，要不要清除某些位，OnExit：退出时。
3. 如果没有通知值，阻塞的时间。

看看代码：

实际的例子：

四：晚课学员提问

1. 问：轻量级信号量的发送函数一直发送，加满了会怎样？ 答：信号量是一个整数，什么叫做加满了？那就是加到整数的最大值，然后溢出变为0。

2. 问：在入口处清除是先清除，在读取值，在出口清除是先读取值后，在清除是这样的吗？ 答：入口处：直接清除；中间：读值；出口处：直接清除。

1. 清除的是之前遗留下来的数值。

2. 然后等待。

3. 等待过程中，别的任务发来新的通知值。

4. 然后目标任务被唤醒，记录通知值。

5. 最后清除掉某些位，返回。

6. 问：清除之前遗留下来的，是担心这些遗留的影响通知值吗？ 答：这些参数只是组合起来给你使用，我举几个例子。

4. 问：事件组那个，想要等待全新的数据，可以清除吗？ 答：可以清除，他只是提供这些参数给你，你觉得：我要等待，从现在开始的全新数据，当然就可以在入口清除。

5. 问：其实对于轻量级事件组，入口处清除不清楚其实没影响？ 答：我们看看代码：

6. 问：其实对于轻量级事件组，入口处清除不清除其实没影响？ 答：有影响。假设一种情况：

   1. task1发出通知值：0x1
   2. task2发出通知值：0x1
   3. 现在通知值是：0x3
   4. 目标任务是task3，得到了通知值0x3，它知道：发生了bit0、bit1事件
   5. task3都不清除事件：入口、出口处都不清除
   6. task3再次等待通知
   7. task1发出通知值：0x1
   8. 因为没有清除通知值，他仍然是0x3
   9. 目标任务是task3，得到了通知值0x3，它知道：发生了bit0、bit1事件

   在第9步：task3误以为再次发生了bit0, bit1事件。

7. 问：老师，我知道在HANDLE模式下LR的后四位有特殊含义，表示返回thread还有使用PSP出栈，我的疑问点在这个Handle模式下的LR的值是哪里来的，正常理解从任务到中断，这个时候虽然入栈了但寄存器里的值应该还是原任务运行中寄存器的值，但现在情况是一中断这个LR的值就改变了，那么肯定有个机制：中断后就把任务的LR替换成Handle的LR了，这个LR改变跟出入栈也没有关系，那这个值肯定是存在某个地方的，我就是想了解这个替换LR的机制是怎样的，还有这个Handle的LR保存在何处。 答：参考项目3的10-3：异常处理深入分析_保存现场

   1. 发生中断
   2. LR保存中断处理完后的返回地址
   3. 调用中断函数前，LR保存进栈
   4. LR被替换为一个特殊的值，硬件去设置LR寄存器
   5. 调用中断处理函数
   6. 中断处理函数执行完，返回到特殊的LR值
   7. CPU就知道：哦，你是中断处理完了
   8. 从栈里取出之前的LR，跳过去执行

8. 问：

答：他们都是设置优先级来禁止中断，一个会记录禁止中断之前的中断优先级，我们看看代码

都是通过设置basepri寄存器来屏蔽更低优先级的中断，

在中断里使用的portSET_INTERRUPT_MASK_FROM_ISR：

1. 先记录basepri原先的优先级
2. 再去修改basepri

在任务里使用portEXIT_CRITICAL，只是修改basepri

差别就在这里：是否记录原来的basepri

1. 为什么在中断里面我关中断之前要记录basepri？ 因为重新开中断时，就是恢复basepri

2. 为什么在任务里，关中断之前不需要记录basepri？ 因为在运行到任务时，所以的中断都是可以使能的，basepri本来就等于0

现在就可以回答你的问题了：

我们假设一个场景：

我来举一个真实的场景示例：

1. 有I2C中断，优先级为B

2. 有GPIO中断，优先级为A

   注意：A < B

3. 发生了GPIO中断，在GPIO中断处理过程中，不想被I2C中断打扰

4. 设置basepri = B，就是屏蔽I2C中断

5. GPIO中断函数要调用写队列函数，为了互斥地访问队列，调用portSET_INTERRUPT_MASK_FROM_ISR

   设置basepri = configMAX_SYSCALL_INTERRUPT_PRIORITY

   这里就要提问了:写完队列之后, basepri是不是应该恢复回原来的值？

   basepri应该等于步骤5之前的值，就是：basepri=B，继续屏蔽I2C中断

   所以，portSET_INTERRUPT_MASK_FROM_ISR有两个作用：记录当前basepri的值，设置basepri= configMAX_SYSCALL_INTERRUPT_PRIORITY

6. 访问完队列，basepri恢复原来的值B

7. 处理完GPIO中断，恢复原来的basepri 0

以上就是【RTOS训练营】上节回顾、轻量级队列、轻量级事件组和晚课提问的详细内容，更多请关注php中文网其它相关文章！