1302_FreeRTOS中CoRoutine设计实现分析

全部学习汇总: GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

在FreeRTOS中有一个功能叫做CoRoutine,在很久之前使用某个MCU的SDK中集成的FreeRTOS功能的时候就发现过这个配置,但是没有深究其作用。

这个是官方的介绍,从介绍的内容来看,其实这个CoRoutine很大的一个特点就是对资源的需求会少一些。从其支持的状态来看,少了挂起以及恢复等操作。因此,应该在调度实现上也更简单。这是一个轻量的、弱化的Task功能。

从文档的描述看,其实这个CoRoutine也是支持DELAY操作的。我觉得很多人用FreeRTOS习惯了之后可能很喜欢任务中的delay设计,的确是很方便,可以简化很多设计的思路。

这里介绍了CoRoutine的几个特点。第一个是单一堆栈,这也就意味着不会有类似创建任务时候的那样的stack开销。第二个特点,不允许在switch case的结构中进行阻塞调用。前面的可以理解是一个简单的话任务调度的舍弃,后面这个,到了后面分析代码的时候可以看出来。其实CoRoutine的阻塞实现本身就是一个switch case的组合,因此会出现破坏性的影响。

这个是CoRoutine用到的一些状态量,从命名上都能够看出来跟Task的实现有一些相似之处。

这里是就绪任务链表的处理,中间判断了优先级,但是其实是没有出现实质的任务调度的。这也是调度轻量化实现的一点体现,牺牲了一些优秀的细节机理实现。

如果看完了任务的创建在看这个,其实还是很容易的。整体的套路其实是差不多的,最重要的一个差异在于少了对战的处理。

这个是往delayed list增加元素的一个过程,涉及到了计数器的溢出这里也做了相应的处理考虑。

这个处理的方式跟任务的处理方式也非常相似,主要是实现一个pending ready到ready状态的搬运。而搬运总是发生在调度器的执行过程中。

这个处理的方式跟Task的处理方式也有一定的相似之处,其实,很多处理都是少了stack的处理或者调度的请求处理。其他的实现都有一定的相似之处。这个接口也是在调度器服务接口中调用的,而那个调度服务本质上其实是一个类似前后台模式的设计中的状态扫描器。

这个是“调度器”,其实本质上没有什么太多调度的概念。这里主要是实现一个状态的查询,然后执行相应的绑定CODE函数。整个CoRoutine涉及到的ready、pending ready、delayed list等几个链表会在这里进行相应的同步或者更新处理。

这个是链表初始化的处理,其实就是一些元素或者数值的填充。

这个是CoRoutine事件处理的支持,这个调用的点跟前面就不同了。调度其实是有一定预判性的查询提取,而事件其实是有一定突发性或者激活性的。这个事件的处理机制采用了一个队列的概念,这个也是FreeRTOS的队列概念。但是,从代码的框架看了下,其实CoRoutine的队列实现跟Task支持的队列实现又是两个独立的实现。这部分具体的实施这里不做进一步的分析了,留到后面跟其他的队列一起。但是,简单考虑一下也是能够基本清晰的,即使是队列的信息发生了变化,修改改动的还是相应的链表实现。而本身这个接口有链表元素的处理,那么肯定是这个接口后期在队列处理的接收动作中进行调用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值