经测试, 没问题,
谢谢 楼上 几位帮我纠正记忆错误.
LAOXU 发表于 2024-4-5 18:03
经测试, 没问题,
谢谢 楼上 几位帮我纠正记忆错误.
{:4_245:}, 你都好几次提过这个问题了, 差点倒逼老姚把定时器改成CCP/PCA模块了, 这下总算弄明白了
STC15/STC8/STC32的 【定时器n】 的模式0，
都是支持16位硬件自动重装载，这样无误差，
都可以工作在最低优先级
STC15/STC8/STC32的定时器0的模式0，
支持16位硬件自动重装载，这样无误差，
可以工作在最低优先级
STC15/STC8/STC32的定时器0的模式3，
支持16位硬件自动重装载，这样无误差，
定时器0的模式3，打开并允许工作后，
不可屏蔽，就是最高优先级 ！
还不可关闭，但你 TR0 = 0, 他也没辙/没时钟
部分还有 8位预分频，那就是24位的定时器，
其中16位重装载
CosyOS 发表于 2024-4-5 16:04
这个世界上，凡事都是辩证的，没有什么是绝对的真理，每一项技术在发挥它优势的同时也必然存在着劣势。
正 ...
中断会被挂起等待响应，但同一个中断，第一次产生，还没去响应，又第二次来了，肯定就会丢1次中断
CosyOS-II 专业版测试程序 在 STC32G 上的测试结论
TASK_0 每秒钟 printf 输出一次任务计数，用的是软件定时器，uDelay_s(1);
误差通常在1ms左右波动（1ms为一个滴答周期），而且是在多个高优先级中断频繁打断的情况下，
尤其是任务管理器专用的串口中断，115200bps，每86多us打断一次，每包发出460个bytes。
可见，即使系统滴答中断为最低优先级，只要处理得当，软件定时器仍可满足一般的精度要求。
神农鼎 发表于 2024-4-5 19:13
STC15/STC8/STC32的 【定时器n】 的模式0，
都是支持16位硬件自动重装载，这样无误差，
都可以工作在最低优 ...
STC15/STC8/STC32的 【定时器n】 的模式0，
都是支持16位硬件自动重装载，这样无误差，
都可以工作在最低优先级
是不是可以这样理解：
假设时钟主频是24MHz，定时器n中断设置在低优先级，每毫秒产生1次中断
（1）假如定时器n计数器溢出到0，产生了中断请求，
然后不管中断请求是否得到响应，不管是否进入到中断服务程序
因为优先级低，被高优先级的中断阻塞了），
这时在主频1个时钟周期内，定时器n计数器就被硬件立即自动重装到初始值，
并且在下个主频时钟周期开始时，就继续重新计数了。
如果这样，自然就在主频时钟周期的量级上没有误差了。
（2）如果是这样，只要定时器n中断被阻塞的时间小于1毫秒，就不会丢节拍了。
比如这个周期被阻塞了0.5毫秒才执行ISR，
但是下次只再需0.5毫秒定时器n计数器就会溢出到0，产生中断请求。
这样1毫秒的节拍误差不会累计下去。
是，16位硬件自动重装，无误差
看来焦虑症不分“产前”和“产后”，弄得大家都跟着焦虑了
tzz1983 发表于 2024-4-5 18:28
, 你都好几次提过这个问题了, 差点倒逼老姚把定时器改成CCP/PCA模块了, 这下总算弄明白了 ...
没人回答帮忙纠错
本帖最后由 杨为民 于 2024-4-12 07:35 编辑
LAOXU 发表于 2024-4-5 23:43
没人回答帮忙纠错
因为大家被你带领去和风车打架了呀！回想整个过程：
（1）指风车为魔鬼：目前 滴答时钟 不准的原因:STC51 只有进入中断后, 才自动重装 定时器, 处于最低中断优先级 的 滴答时钟,被更高的优先级阻障并延迟触发中断很正常, 这是 目前 造成 滴答时钟 不准的根本原因.
（2）魔鬼好可怕：当系统 中断凭繁时 ,滴答时钟 拖长现像非常明显
（3）照着魔鬼就是一刀：这一点 STC51 和 标准 51 不兼容, 只有 自动重装 改成这样,装入常数 + 定时器当前值 ---->定时器,自动修正装载时的延时误差,那么一切问题都不存在了.
（4）结果有点尴尬,根本就是个正常的风车:
STC15/STC8/STC32的 【定时器n】 的模式0，
都是支持16位硬件自动重装载，这样无误差，
都可以工作在最低优先级