本文主要是介绍1818_ChibiOS的计数信号量，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
全部学习汇总： GreyZhang/g_ChibiOS: I found a new RTOS called ChibiOS and it seems interesting! (github.com)
之前见过计数信号量，也是在FreeRTOS中看到的。也看到过这样的功能在驱动设计中的应用，但是当时没有理解这个使用的方式。
1. 计数信号量可能有3种数值，如果数值为负数，那么代表有N个线程在等待信号；如果是0那么代表信号全都被取走了但是没有线程等待信号；如果是正数，那么代表信号可以被线程取N次。
2. 配置选项中，可以选择是否使用这个功能，也可以配置这个信号的获取是按照优先级还是FIFO的方式来获取。
相比基本的计数信号量，ChibiOS提供的技术信号量还做了一些增强。包括：支持复位成指定的数值；超时处理；消息返回；信号的操作以及等待处理做成了原子化的操作。
这里举例说明了技术信号量的应用场景，典型的例子是DMA通道的分配。其实，类似的处理，CAN的邮箱buffer也是一个很典型的例子。
ChibiOS的很多接口处理的对象都是线程而不是数据本身。这里的wait操作其实是让线程等待指定的信号。如果超时没等到，这里有一个报错的处理。如果等到了，则调用资源的分配接口提供对应的资源分配结果。
当申请的资源用完了之后，可以通过释放信号的方式归还硬件资源。这个归还会触发一个信号的发生操作，以此提示等待或者即将等待的线程有资源可用。
这是软件最初的初始化设计，初始化对应的信号。其实是创建了一个DMA资源与信号的绑定关系。其中，信号的初始值代表有多少资源可用。初始化的时候，DMA还没有被分配占用，因此这里的数目为DMA的通道数目。
之前我看到的类似的处理是基于FreeRTOS的一个CAN发送buffer资源的分配。那时候也没有弄明白这样设计的理念，而且那时候一在调试的过程中也遇到不少问题。现在想来，大概率还是OS的功能没有正常初始化就已经使用了这样的信息导致。或许，回头重新调试一下这样的问题就很容易调试通过了。
这篇关于1818_ChibiOS的计数信号量的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
