全网悬赏500元感谢费找BUG! uC/OS-II@STC32G_No_PendSv新移植版

tzz1***

LAO*** 发表于 2024-4-5 04:00
你想要搞的那种最高优先级切换任务的，可能要专门针对重写一个OS, 现有的难找出！

====================== ...

首先你的目标要明确, 究竟是要关EA运行OS呢, 还是:
"把 T0 改成不可屏蔽 中断, 优点, 滴答定时器计时超准, 其他功能不变."

如果是关中断运行OS, 我对此不感兴趣. (无聊的话题)

如果只是:"滴答定时器计时超准, 其他功能不变."

我把我对OS的理解, 告诉你:
1.  OS的时钟本来就是准的,正常情况下OS的时钟不会不准.
2.  如果不准,那一定是使用者的编程习惯有问题.
     原因: 时钟滴答中断作为最低中断优先级,确实会被更高的优先级阻障并延迟触发.
              但是只要阻障的时间没有超过一个时钟滴答周期,滴答标志不溢出，就不会有丢失计数.

            如果是在其它中断里有大量耗时的代码. 就会造成滴答无法触发中断,从而丢失计数.
            但这是一个编程能力的问题. 会用OS的绝对不会在中断里有大量耗时的代码.
            通常是把"大量耗时的代码" 用信号量同步到一个任务中去.

LAO***

tzz1*** 发表于 2024-4-5 10:21
首先你的目标要明确, 究竟是要关EA运行OS呢, 还是: "把 T0 改成不可屏蔽 中断, 优点, 滴答定时器计时超准, ...

目前 滴答时钟 不准的原因:

STC51 只有进入中断后, 才自动重装 定时器, 处于最低中断优先级 的 滴答时钟,
被更高的优先级阻障并延迟触发中断很正常, 这是 目前 造成 滴答时钟 不准的根本原因.

如把 T0 改成不可屏蔽 中断, 则没有上述缺点, 滴答定时器计时超准

LAO***

当系统 中断凭繁时 ,  滴答时钟 拖长现像非常明显.

LAO***

这一点 STC51 和 标准 51 不兼容, 只有 自动重装 改成这样,  装入常数 + 定时器当前值 ---->定时器,
自动修正装载时的延时误差,  那么一切问题都不存在了.

tzz1***

LAO*** 发表于 2024-4-5 13:31
这一点 STC51 和 标准 51 不兼容, 只有 自动重装 改成这样,  装入常数 + 定时器当前值 ---->定时器,
自动 ...

尔....被你说的都不自信了, 我记得从
STC15，STC8，STC32 定时器的模式0，
都是硬件16位自动重装载的,  
不需要进中断后软件装载吧

Cos***

我在说明书中也未见到“进中断后才能重装载的说法”，应该是只要定时器溢出了硬件就会自动重装载，与是否进入定时器中断无关。

Cos***

CosyOS-II 在说明中明确指出：
1、用户中断应遵循快进快出的原则，对事件仅做必要的紧急处理，再以同步方式通知 中断服务任务 做后续处理。
2、用户中断的最大执行时间应远小于系统滴答周期，这将促使整个系统更加良性的运行。
3、临界区应遵循快进快出的原则，临界段代码的执行时间应远小于系统滴答周期，这将促使整个系统更加良性的运行。

其目的就是在实现0中断延迟的同时，又要用户注意以上事项，以实现系统滴答计数（软件定时器）的准确。

fan***

LAO*** 发表于 2024-4-5 13:14
当系统 中断凭繁时 ,  滴答时钟 拖长现像非常明显.

不会的，只要程序设计合理，延时的误差，最大为1个滴答时钟，而且这个误差是必然存在的。
如果需要更精确的时间控制，只能通过定时器来完成。但是定时器也会有一个定时器时钟的误差。
误差是必然存在的，只要在允许范围内就没问题。

LAO***

Cos*** 发表于 2024-4-5 14:13
我在说明书中也未见到“进中断后才能重装载的说法”，应该是只要定时器溢出了硬件就会自动重装载，与是否进 ...

关于这一点, 以前是某网友验证的.

我晚上抽时间亲自验证一下

Cos***

这个世界上，凡事都是辩证的，没有什么是绝对的真理，每一项技术在发挥它优势的同时也必然存在着劣势。
正如RTOS内核到底采取哪种临界段保护方案为好？
1、关闭总中断处理临界段
2、最高优先级中断中（包括T0不可屏蔽）处理临界段
3、零中断延迟
相信，每一种方案都有它的优势，在此不必细说。
然而，关键是实时性应如何保证，这是RTOS的初衷。
实时性的主体包括两方面，中断的实时性、任务的实时性。
下面只谈中断的实时性：
关闭总中断处理临界段可以吗？最高优先级中断中处理临界段可以吗？
当然都可以，但问题的关键是应同时提供一个关键参数给用户知晓，那就是
“最大关闭总中断时间”、“最大中断响应延误时间”。
否则中断的实时性又如何保证？高速中断是否会丢失响应？
用户将不得而知。。。