1818_ChibiOS的计数信号量

         全部学习汇总: GreyZhang/g_ChibiOS: I found a new RTOS called ChibiOS and it seems interesting! (github.com)

         之前见过计数信号量,也是在FreeRTOS中看到的。也看到过这样的功能在驱动设计中的应用,但是当时没有理解这个使用的方式。

1818_ChibiOS的计数信号量_第1张图片

1. 计数信号量可能有3种数值,如果数值为负数,那么代表有N个线程在等待信号;如果是0那么代表信号全都被取走了但是没有线程等待信号;如果是正数,那么代表信号可以被线程取N次。

2. 配置选项中,可以选择是否使用这个功能,也可以配置这个信号的获取是按照优先级还是FIFO的方式来获取。

1818_ChibiOS的计数信号量_第2张图片

相比基本的计数信号量,ChibiOS提供的技术信号量还做了一些增强。包括:支持复位成指定的数值;超时处理;消息返回;信号的操作以及等待处理做成了原子化的操作。

1818_ChibiOS的计数信号量_第3张图片

         这里举例说明了技术信号量的应用场景,典型的例子是DMA通道的分配。其实,类似的处理,CAN的邮箱buffer也是一个很典型的例子。

1818_ChibiOS的计数信号量_第4张图片

         ChibiOS的很多接口处理的对象都是线程而不是数据本身。这里的wait操作其实是让线程等待指定的信号。如果超时没等到,这里有一个报错的处理。如果等到了,则调用资源的分配接口提供对应的资源分配结果。

1818_ChibiOS的计数信号量_第5张图片

         当申请的资源用完了之后,可以通过释放信号的方式归还硬件资源。这个归还会触发一个信号的发生操作,以此提示等待或者即将等待的线程有资源可用。

1818_ChibiOS的计数信号量_第6张图片

         这是软件最初的初始化设计,初始化对应的信号。其实是创建了一个DMA资源与信号的绑定关系。其中,信号的初始值代表有多少资源可用。初始化的时候,DMA还没有被分配占用,因此这里的数目为DMA的通道数目。

         之前我看到的类似的处理是基于FreeRTOS的一个CAN发送buffer资源的分配。那时候也没有弄明白这样设计的理念,而且那时候一在调试的过程中也遇到不少问题。现在想来,大概率还是OS的功能没有正常初始化就已经使用了这样的信息导致。或许,回头重新调试一下这样的问题就很容易调试通过了。

你可能感兴趣的:(ChibiOS,驱动开发,RTOS,ChibiOS)