本文主要是介绍FreeRTOS内部机制学习03（事件组内部机制），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- 事件组使用的场景
- 事件组的核心以及Set事件API做的事情
- 事件组的特殊之处
- 事件组为什么不关闭中断
- xEventGroupSetBitsFromISR内部是怎么做的？
事件组使用的场景
学校组织秋游，组长在等待：
张三：我到了
李四：我到了
王五：我到了
组长说：好，大家都到齐了，出发！
秋游回来第二天就要提交一篇心得报告，组长在焦急等待：张三、李四、王五谁先写好就交谁的。
在这个日常生活场景中：
出发：要等待这3个人都到齐，他们是"与"的关系
交报告：只需等待这3人中的任何一个，他们是"或"的关系
在FreeRTOS中，可以使用事件组(event group)来解决这些问题。
事件组的核心以及Set事件API做的事情
核心是：关调度器、位操作、链表
事件组中的Set永远不会阻塞，因为事件的发生是一瞬间发生的，哪里有等待一说辞呢？等待就会有阻塞的一说法！
几乎RTOS的每个东西的使用都离不开链表，由此可见链表是多么的重要，多么的强大，事件组亦是如此，在创建事件组的时候也分配了一个结构体，那么里面到底又有什么东西呢？
这个链表在唤醒那些阻塞的任务的时候发挥了很大作用，那些阻塞的任务都会在这个链表里面登记一下，到时候唤醒的时候就会去里面找到并唤醒它！
上面多说的就是Seg事件API所要做的事情！
事件组的特殊之处
学习了队列以及信号量和互斥量，发现它们里面内部操作都是“关闭中断”，而现在要学习的事件组截然不同
看看队列的内部代码：
而相比事件组的内部是怎么操作的呢？事件组不是关闭中断，而是关闭调度器！
关闭了中断，调度器就用不了了，那我事件组为什么不和他们一样做法关闭中断呢？而是仅仅关闭调度器呢？他们的做法都是为了防止资源冲突！那事件组的这样做的原因到底是什么呢？
事件组为什么不关闭中断
不难发现队列以及信号量、互斥量都有两套函数
都可以在中断中“访问资源”，所以它们就需要关闭中断来互斥的访问，不然就会起竞争，但是事件组不也有着两个Set函数吗（一个中断中使用）？
那它就不怕中断中的Api也来竞争资源吗？不怕同时访问（Set）吗？
这就不能被他们的外表所迷惑了，需要他们的外表都有着相同的特点，但是他们的内部的操作是不一样的！事件组比较特殊！
在队列、信号量、互斥量使用他们的函数后，可能你使用之前就会有一个任务或者索多个因为写满了或者没数据可读因此阻塞了，然后假如你在中断中使用了API函数了，就会因此去唤醒他们吧，但是队列它们三个都只会去唤醒一个任务（优先级最高的），相反事件组会去唤醒所有符合这个事件发生条件的任务，那万一一个工程里面真有很多事件在等着同一个事件呢？（比如主人回到家后，自动唤醒灯，风扇，空调，煮饭，。。。。。。。。）那么唤醒它们不是要很长事件吗？在中断中卡住这么一段时间是很要命的！不就显的很卡了吗？为了避免这种情况发生，事件组的xEventGroupSetBitsFromISR函数就不像队列它们那样这么直接了！
xEventGroupSetBitsFromISR内部是怎么做的？
xEventGroupSetBitsFromISR不是直接的去唤醒，而是写队列去唤醒一个任务，然后让这个任务去唤醒那些未知数目的符合条件的任务！
这篇关于FreeRTOS内部机制学习03（事件组内部机制）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
