硬汉嵌入式论坛

 找回密码
 立即注册
查看: 2450|回复: 2
收起左侧

[RL-RTX] 问一个关于osRtxIdleThread问题

[复制链接]

1

主题

2

回帖

5

积分

新手上路

积分
5
发表于 2018-6-1 23:33:00 | 显示全部楼层 |阅读模式
本帖最后由 Metro 于 2018-6-1 23:34 编辑

osRtxIdleThread可以用来插入低功耗模式代码,这个大家应该都知道。不过,osRtxIdleThread也可以用来做tick-less low-power operation,简单来说就是在SysTick Timer因进入深度睡眠模式而不能工作的时候,使用其它低功耗timer(如RTC)来计算睡眠的时间,并将其转换为对应的Tick数返回给RTX Kernel。官方的说明可以参考Tick-less Low-power Operation

最近我在尝试将这个功能移植到某个芯片上,但却发现了问题。首先,一个正常的osRtxIdleThread函数的代码结构如下: osRtxIdleThread.png

这里用到了WFE指令进入睡眠模式。很明显,这里不能用WFI,因为这可能会使得在osKernelSuspend到WFI之间发生的中断被“无视”,进而导致本该由中断唤醒的芯片无法退出睡眠模式。但是,仔细推敲的话,WFE用在这里也不行。我们知道,WFE会检查内部事件寄存器,只有当该位为0时才进入中断,而中断的发生和退出会置位内部事件寄存器。也就是说,当该位为1时,必须执行两次WFE才会进入睡眠模式,且其中不能发生其它事件。这里的问题出现在osKernelSuspend和osKernelResume上。这两个函数都需要进入到Handler模式执行,而进入Handler模式的方法就是使用SVC指令,而一旦SVC指令被执行,就会导致内部事件寄存器被置位,造成的后果是每次执行到WFE时CPU实际上只将内部事件寄存器清零而没有进入到睡眠模式,也就意味着这和直接执行for(;;);基本没有任何区别。

对于这个问题,我思考了很久,但没有找到太好的解决方法,特别是在考虑“随时都可能触发中断”的前提下。官方例子中的MSP432_LP_Entry函数的执行轨迹似乎也很奇怪,如果置位SLEEPONEXIT,应该会导致下个“从Handler模式返回到Thread模式”的事件发生时进入到睡眠模式,而发生这件事的时候正是调用osKernelResume的时候(因为第一个WFE实际上并未执行),我的理解对吗?总觉得好像有哪里不对……总之想请教一下大家对于这种应用有没有什么比较好的操作思路,谢谢。
回复

使用道具 举报

1万

主题

6万

回帖

10万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
106959
QQ
发表于 2018-6-1 23:41:47 | 显示全部楼层
你这句话“这里不能用WFI,因为这可能会使得在osKernelSuspend到WFI之间发生的中断被“无视””理解的不对吧,任何中断都可以唤醒WFI的。
回复

使用道具 举报

1

主题

2

回帖

5

积分

新手上路

积分
5
 楼主| 发表于 2018-6-2 11:43:41 | 显示全部楼层
eric2013 发表于 2018-6-1 23:41
你这句话“这里不能用WFI,因为这可能会使得在osKernelSuspend到WFI之间发生的中断被“无视””理解的不对 ...

是我表达不清楚哈,我想说的是中断里面做的事情可能会影响是否进入睡眠模式。举个例子,如果中断程序在osKernelSuspend到进入睡眠模式(WFI或WFE)之间调用osEventFlagsSet,那么WFI/WFE就不应该进入睡眠模式,因为接下来要调用osKernelResume对Event进行处理,直接调用WFI的话会导致无法及时处理这个Event(如果后续无中断的话芯片就会保持睡眠模式)。WFE出现的原因应该就是为了解决这种问题,参考手册规定了在发生中断后执行的第一次中断并不会置为内部事件寄存器。但是,由于SVC本身也是中断,会导致其无法区分“SVC导致的中断”(此时可以进入睡眠模式)和“其他中断”(此时不应进入睡眠模式,因为有后续任务需要及时处理)这两种情况。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|小黑屋|Archiver|手机版|硬汉嵌入式论坛

GMT+8, 2024-5-12 06:06 , Processed in 0.189577 second(s), 28 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2023, Tencent Cloud.

快速回复 返回顶部 返回列表