最新版本uC-OS2-2.93.01已移植到STC8上，请帮忙查错

熊***

刚仿真试了一下，是先跳转的。
EA=1应该在TF0=1的前面。跳转完后才进入那个中断。

熊***

所以最保守还是在入口处++操作，然后跳转。因为跳转后，还没来得及执行++，进入高优先级中断。

tzz***

是的, 我刚才也试了, 是来不及加的, 这算不算一个BUG, 哈哈. 应该算的, 虽然之前你注意到, 但是现有版本却没有应用, 所以还是要算一个BUG, 看来官网欠我200RMB了

tzz***

我建议你在向量口放CLR EA 指令, 这样不管中断代码中调用OSIntEnter()还是直接 OSIntNesting++ 都能兼容, 同时也满足在中断代码里操作OSIntNesting的习惯. 不过确实有些麻烦, 系统要为每个向量入口加一个CLR EA 指令. 不过STC的库里好像本来就有一个ASM文档, 里面有全部的的中断向量入口, 不用自己去打全部的代码, 稍改就可以

熊***

tzz1983 发表于 2023-9-16 08:17
我建议你在向量口放CLR EA 指令, 这样不管中断代码中调用OSIntEnter()还是直接 OSIntNesting++ 都能兼容,  ...

之前在完善2.91版本的时候，就是杨老师整理过的原网友提供的那个版本。就是想到这种极限的问题。
后面看到普遍都这么干的。移植到在2.93的时候又把它去掉了。
如果真的会存在这个问题。目前移植到其他单片机上的都有这个问题。都是在跳转之后关中断操作或者++操作。

通过仿真确实是会有这种情况。但是STC的仿真属于模拟的，这个还是需要STC官方解释一下。

如果入口放CLR EA,后面还需要开中断。
直接++效率更高的。但是需要考虑客户提前打开中断的情况，所以内核函数在--的时候改一下。这个我在杨老师那个帖子里面有跟贴说明。新版本为什么没有这个操作呢？就是确保不改源码。当然使用者不会提前打开中断，这样用也没问题。

tzz***

熊仔 发表于 2023-9-16 08:49
之前在完善2.91版本的时候，就是杨老师整理过的原网友提供的那个版本。就是想到这种极限的问题。
后面看 ...

这是嵌套问题, 和提不提前开中断没关系, 就是说已进入任务了, 也会发生. 只要是在执行中断向量口那条转移指令时, 如果此时响应了更高级的中断, 就会来不及+ . 我现在也需要STC来解释一下, 这个地方是否会响应更高级的中断.
但是, 别的做法是不一定有问题的, 你见过我另一个贴, 说的是用中断切换任务的, 这个方式, 在这里就不会有问题, 因为OSIntNesting已经作用不大了, 之所以保留, 就是不想动别人的东西呗.
另外我认为用中断切换任务才是正统的方式, 作者之所保留OSIntNesting也是为了兼容更多的做法, 我在绍贝贝司的书上,看到有一段话, 说 OSCtxSw() 本来是来对应中断代码的
在我另一个贴上, 杨老师提到了"正统"二字, 反面映射就是说我的方法不正统啊, 呵呵, 我发现我现在就是喜欢怼杨老师, 自己也不知为什么, 网友会不会反感这种行为?

熊***

tzz1983 发表于 2023-9-16 09:38
这是嵌套问题, 和提不提前开中断没关系, 就是说已进入任务了, 也会发生. 只要是在执行中断向量口那条转移 ...

“但是需要考虑客户提前打开中断的情况，所以内核函数在--的时候改一下。”
你试试系统没有启动的时候搞一个EA=1；在搞一个定时器1中断开启。就乱套了。因为系统还没有开启，一直OSIntNesting++，但是不会OSIntNesting--，ucos代码是默认OS启动后才会++操作。
所以我最后一句也说了 “当然使用者不会提前打开中断，这样用也没问题。”


参考我在杨老师的跟帖的28#
https://www.stcaimcu.com/forum.p ... p;extra=&page=3

熊***

我也同意触发中断切换任务，这个才是正统的方式。直接切换方式，是没有软中断方式才用的，但是也可以借助其他不用的中断。

tzz***

熊仔 发表于 2023-9-16 09:59
我也同意触发中断切换任务，这个才是正统的方式。直接切换方式，是没有软中断方式才用的，但是也可以借助其 ...

嗯 是的, 两种方法都可以用, 各有所长. 用中断就是简单, 可以说直接套娃就用.  用代码需要考虑的东西更多一点, 好处是不占用中断资源.  但是现在片上资源多了, 不像90年代时那么紧巴巴的

熊***

这样对比触发最低优先级中断方式，还真的不用考虑中断嵌套呢。反正这个嵌套硬件自动完成。