全局不关总中断的 RTOS，CosyOS-III-V1.2.0, 送 擎天柱-AI8051U转89C52核心板

PANE***

支持大神原创，助力STC32位8051腾飞！

web***

很不错，收藏学习

cn_Star***

还没玩过RTOS， 期待

Yang.***

楼主，
我觉得定时查询的行为有点诡异，是我哪里搞错了？
我用定时器记录电压变化，
如果我在 start_hook 里面设置时间，无论时间设置多长，开机后1秒内大概被触发11次左右，大概记录了11次数据读取，然后恢复正常，按定时器设定时间读取
如果我在 init_hook 里面设置时间，定时查询触发都是正常的，但是第0秒并不会有触发任何动作

Cos***

Yang.*** 发表于 2024-10-2 12:00
楼主，
我觉得定时查询的行为有点诡异，是我哪里搞错了？
我用定时器记录电压变化，

如果我在 init_hook 里面设置时间，定时查询触发都是正常的，但是第0秒并不会有触发任何动作
这可能与 syscfg.h 中，定时中断/查询设置，用户定时查询初始化状态 有关。

如果我在 start_hook 里面设置时间，无论时间设置多长，开机后1秒内大概被触发11次左右，大概记录了11次数据读取，然后恢复正常，按定时器设定时间读取
这个我现在也想不到原因，代码能否发上来，方便分析研究？

Cos***

CosyOS-II 最新版 V3.0.4 发布！


最新版本解决了 定时查询 不能为一个，至少要两个的问题。
历史版本中，如果未开启 任务管理器，用户创建的 定时查询 至少要两个，
否则相应任务或钩子不能运行，这个问题是由一个bug导致的，在最新版中得以修正。
自 CosyOS-II V3.0.4 版本开始，无论是否开启 任务管理器，
用户创建的 定时中断 或 定时查询，至少都可为一个（当然也可为0）。

另外需要注意的就是，syscfg.h 中，用户定时中断总数、用户定时查询总数，
如果定义数量大于实际数量，编译器会告警；如果定义数量小于实际数量，编译器无法察觉。

所以，为防止定义出错，定义的数量可以先大一些，让编译器告警，
再逐渐减小，直到编译器没有告警。
当然，仔细统计一下实际的数量再设定正确的值，是最为直接有效的。

Cos***

Yang.*** 发表于 2024-10-2 12:00
楼主，
我觉得定时查询的行为有点诡异，是我哪里搞错了？
我用定时器记录电压变化，

首先，我猜测你的
用户定时查询初始化状态 设置为 查询状态，=> #define SYSCFG_USERTIMQRYINIT    1
且该 定时查询 已开启 自动重装载。

定时中断/查询任务 都是在 Starter 中启动的，而后是调用 start_hook。
而在 main() 中，是先 s_init_timing()、再 init_hook()，而后是启动 Starter、调度 Starter。

1、如果在 init_hook 中定时，
     此时该定时任务还未启动，所以该定时任务启动后，首次便会按照用户的定时来运行；

2、如果在 start_hook 中定时，
     此时该定时任务已经启动，并且该定时器早已初始化为0，在 s_init_timing() 中，

        for(i = 0; i < OS_TIMQRYTOTAL; i++){
                s_timqry_loader = (s_timqry_t)(SYSCFG_USERTIMQRYINIT - 1);
                s_timqry_reload = (s_timqry_t)(SYSCFG_USERTIMQRYINIT - 1);
        }

所以在你定时操作之前，该任务早已运行，由于已经开启自动重装载，所以该任务每被恢复一次后又
重新定时为0，所以该任务在你定时之前已运行 n 次。

结论：
1、如果 定时查询初始化状态 设置为 查询状态，所有 定时查询 都应在 init_hook 中进行 初始定时。
2、如果 定时查询初始化状态 设置为 停止状态，所有 定时查询 都可在 任意位置    进行 初始定时。
3、对于 定时中断初始化状态 固定为 停止状态，所有 定时中断 都可在 任意位置    进行 初始定时。

Cos***

定时中断/查询 详解

定时中断：

1、定时中断初始化状态 固定为 停止状态

               时间到后
定时操作 ————> 定时中断任务/钩子

先进行定时操作，待时间到后，调度/调用 定时中断任务/钩子。
定时中断是仅   时间关键。


定时查询：

1、定时查询初始化状态 设置为 停止状态

               时间到后                 事件为真
定时操作 ————> 查询事件 ————> 定时查询任务/钩子

先进行定时操作，待时间到后，查询事件，若事件为真，调度/调用 定时查询任务/钩子。
其实就是，每次运行的条件都是先时间关键，再事件关键。


2、定时查询初始化状态 设置为 查询状态

               事件为真
查询事件 ————> 定时查询任务/钩子
      ↑                             ↓
      └───────── 定时操作
               时间到后

用法1、系统初始化后，已经开始查询用户定义的事件了，若事件为真，调度/调用 定时查询任务/钩子，
而后关联触发定时操作，待时间到后，再查询事件，若事件为真，再 调度/调用 定时查询任务/钩子。
注意，此用法，用户无需对定时器进行 初始定时。
其实就是，首次运行的条件是仅事件关键，无时间关键。

用法2、在 init_hook 中进行 初始定时，待时间到后，再查询事件... ...
此时，便等效于 定时查询初始化状态 为 停止状态。

zji***

非常方便

Yang.***

Cos*** 发表于 2024-10-14 08:55
首先，我猜测你的
用户定时查询初始化状态 设置为 查询状态，=> #define SYSCFG_USERTIMQRYINIT    1
且 ...

先说明，以下我说的都 定时查询初始化状态 设置为 查询状态

后来，我看了一下代码，我意识到，可能是你说的这个原因。
立刻改了一下代码，所有的定时查询都不设置时间，而是触发以后再设置时间，这样就完美的解决了这个问题。

如果在 init_hook 中，设置时间，实际上，是不会触发第一次的。这样就和定时查询设计的初衷背道而驰了

我建议可以参考 libuv 的API设置原文在这里 https://docs.libuv.org/en/v1.x/timer.html
libuv 中，定时器设计了两个参数，timeout 和 repeat，其中timeout 控制第1次延时，repeat 控制第1次以后的其他延时，举个例子
timeout = 0 , repeat= 0 下一个循环就执行1次，然后结束;
timeout = 1000, repeat=0 延时1秒后执行1次，然后结束；
timeout = 1000, repeat=2000 延时1秒以后执行1次，再延时2秒再执行，以后永远按照2秒间隔执行下去