一：上节回顾

在上次课里，我们从代码的角度来分析了任务通知的内部机制

先来回顾一下，用图形的方式，用链表的方式来展示内部机制

1.1初始状态

假设一开始有两个任务：他们优先级都是n，放在一个就绪链表里

可以看到任务一或者任务二，它们的TCB里面有一个状态：

TCB.ucNotifyState[0] = taskNOT_WAITING_NOTIFICATION
1

初始状态就是：我没有在等待通知

1.2等待通知

可以看到，假设一开始并没有人给他发出通知

他想去得到通知，那就阻塞：从ready list移到了delay list

 TCB.ucNotifyState[0] = taskWAITING_NOTIFICATION
1

表示在等待，正在等待通知

1.3别的任务发出通知后

别的任务给他发通知后：他就可以从delay list移到ready list

Tcb结构里面有两个成员:

如果目标任务并没有在等待通知

你也给他发了通知:那只会把通知的值记录下，并且修改状态：

 TCB.ucNotifyState[0] = taskNOTIFICATION_RECEOVED
1

普通的队列并没有使用到TCB.ucNotifyState[0]

使用任务通知模拟的队列：要用到TCB.ucNotifyState[0]

二：轻量级队列

2.1.写队列

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

• eSetValueWithoutOverwrite：不覆盖
• eSetValueWithOverwrite：覆盖

2.2.读队列

我们先来回顾一下，普通的队列是怎么一回事：

1.队列就是一个环形缓冲区：可以存放多个数据，数据的大小是可以事先指定的

2.写队列的时候：如果队列满了，写者可以阻塞

3.读队列的时候：如果队列空了，读者可以阻塞

再来看看任务通知，在tcb结构体里：

他只能保存一个数值

所以：我们要使用任务通知来实现一个轻量级的队列，他就只能够保存一个数据，这个数据的大小是32位的

跟普通队列的第2个不同点：

2.1 其他任务只能写

2.2 可以多对1

2.3 写的时候不阻塞

这里最大的不同就是写的时候不能够阻塞

我们来看看示例代码：

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

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

圈出了两个地方，大家再跟普通的队列来对比一下。

这里可以指定覆盖，也可以指定有不覆盖

我们可以来看看代码：

三：轻量级事件组

怎么去设置位？用的是同一个函数

作为轻量级队列：操作是整个值

作为轻量级事件组：操作的是某些位

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

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

我们来看看代码：

上图中三个圆圈：

1.set bit

2.累加

3.整个赋值

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

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

xTaskNotifyWait(ulBitsToClearOnEntry, ulBitsToClrarOnExit,pulNotificationValue,xTicksTowati)
1

1.第1个参数：调用这个函数的时候，要不要清除掉某些位

OnEntry: 在函数入口处

2.第2个参数：退出这个函数的时候，要不要清除某些

OnExit：退出时

3.如果没有通知值，阻塞的时间

看看代码：

实际的例子：

四：晚课学员提问

1. 问： 轻量级信号量的发送函数一直发送,加满了会怎样？

答： 信号量是一个整数，什么叫做加满了？

那加到整数的最大值，然后溢出变为0

2. 问： 在入口处清除是先清除，在读取值， 在出口清除是先读取值后， 在清除是这样的吗？

答： 入口处：直接清除

中间：读值

出口处：直接清除

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

2.然后等待

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

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

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

3. 问： 清除之前遗留下来的 是担心这些遗留的影响通知值吗？

答： 这些参数只是组合起来给你使用，我举几个例子

4. 问：事件组那个，想要等待全新的数据，可以清除吗？

答： 可以清除，他只是提供这些参数给你，你觉得：我要等待，从现在开始的全新数据，当然就可以在入口清除

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

答： 我们看看代码：

6. 问： 其实对于轻量级事件组，入口处清除不清除其实没影响？

**答：**有影响

假设一种情况：

1.task1发出通知值：(1<<0)

2.task2发出通知值：(1<<1)

现在通知值时：0x3

3.目标任务是task3，得到了通知值0x3，它知道：发生了bit0、bit1事件

4.task3都不清除事件：入口、出口处都不清除

5.task3再次等待通知

6.task1发出通知值：(1<<0)

因为没有清除通知值，他仍然是0x3

7.目标任务是task3，得到了通知值0x3，它知道：发生了bit0、bit1事件

在第7步：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 < configMAX_SYSCALL_INTERRUPT_PRIORITY

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