CosyOS 发表于 2023-10-31 11:32
不确定就是不可靠，所以... ...
所以我自己用中断切换任务，避开了这个点。 对于其他人，用代码切换任务，并用变量跟踪中断嵌套的, 我呼吁他们重视这一点。
本帖最后由 CosyOS 于 2023-10-31 14:37 编辑
tzz1983 发表于 2023-10-31 11:50
所以我自己用中断切换任务，避开了这个点。 对于其他人，用代码切换任务，并用变量跟踪中断嵌套的, 我呼 ...
说来，我当初设计CosyOS时，还真没考虑这么多，只是单纯为了实现不关总中断、零中断延迟，
才用的软中断（替代）法，真可谓是无心插柳柳成荫啊 {:4_226:}
本帖最后由 tzz1983 于 2023-11-2 08:21 编辑
UCOSII - STC32G12K128使用技巧提示：
有些中断发生频率特别高，对于这种情况，减少中断代码可以大幅减轻系统总负荷。
本文介绍如何在UCOSII-STC32G中 ，什么时候可以避免使用OSIntNesting++;和OSIntExit(); 来优化中断代码
此方法尽限于适用本人移植的UCOSII - STC32G版本：
原理简述：
OSIntNesting的主要作用是跟踪中断嵌套，此版本的UCOS是基于中断切换任务，本身含有硬件自动嵌套。所以此版本中OSIntNesting作用有一些细节变化-> 即现在OSIntNesting的主要作用是：如果在中断代码里有使用OS服务，OSIntNesting用来通知OS服务当前正在执行中断例程。
使用方式也有一些变化：
1. 现在不要求OSIntNesting++必须放在中断代码第一句，只要放在OS服务之前就可以了。
2. 如果在中断代码里没有调用任何OS服务，并且比自身中断更高级的中断也没有调用任何OS服务，则中断代码里可以同时取消使用语句：OSIntNesting++;和OSIntExit();（有OS服务的中断代码，不能取消）。
3. 仍兼容常规的做法，即每个中断代码里都同时包含语句：OSIntNesting++;和OSIntExit(); 也是可以的。
4. 必须配对使用，比如只有 OSIntNesting++; 或 只有OSIntExit(); 都是错误的做法。
5. 只要是中断代码里没有使用OS服务，就可以取消使用OSIntNesting++和OSIntExit()，不会出错。
但是建议只在比自身优先级更高的中断代码里也没有使用OS服务时，才取消OSIntNesting++;OSIntExit();
只有这样，低优先级的OSIntExit()才能避免重复执行更新OS核心参数，真正提高效率。
问答解释：
1. 为什么不彻底取消OSIntNesting? 因为OSIntNesting穿插于整个UCOS原码的许多地方，改动太大。
2. 为什么中断代码里使用OS服务之前一定要OSIntNesting++? 因为OS服务会通过OSIntNesting的值来判断当前是否在中断里。
3. 为什么一定要配对使用OSIntNesting++; 和 OSIntExit(); 因为一个负责加，一个负责减。
4. 连续中断嵌套时，OSIntNesting值可能会和实际嵌套层数不符，执行OS服务时会不会有BUG？不会！ OS服务基于OSIntNesting判断时，只有0和非0值的区别，不关心是几层.
这就是为什么只要在OS服务前OSIntNesting++就可以了的原因。
5. 连续中断嵌套时，OSIntNesting值可能会和实际嵌套层数不符，执行OSIntExit()时会不会有BUG?不会！ OSIntExit()内更新OS核心参数和置位PendSv标志都是可以重复执行的。
综上所述， 没有对原代码做任何更改，即实现了不受OS管理的高优先级中断差不多的效果。对此方法的正确性欢迎大家一起探讨
CosyOS 发表于 2023-10-31 14:32
说来，我当初设计CosyOS时，还真没考虑这么多，只是单纯为了实现不关总中断、零中断延迟，
才用的软中断（ ...
（1）LZZ1983移植的uC/OS-II系统是有明确的中断嵌套保护功能的，在他的程序中：
/*-----------------------------------------------------------*
时钟滴答中断
*-----------------------------------------------------------*/
void Timer0_ISR_Handler (void) interrupt 1
{
OSIntNesting++; //单指令加 OSIntNesting
OSTimeTick(); //调用ucos的时钟服务程序
OSIntExit(); //退出中断
}
这句“OSIntNesting++; //单指令加 OSIntNesting ”就是“用变量跟踪中断嵌套的”，其中的变量OSIntNesting就是用来跟踪中断嵌套的。
（2）“说来，我当初设计CosyOS时，还真没考虑这么多”
你这是明确地告诉大家，你研发的CosyOS系统没有包括中断嵌套保护功能吗？今天你能不能直接回答一下，你的CosyOS有没有使用类似“OSIntNesting”这样的跟踪变量来进行中断嵌套保护，或者你是用什么别的方法来进行中断嵌套保护的，也请介绍一下，这样大家使用你的CosyOS时心里才有底。
本帖最后由 CosyOS 于 2023-10-31 20:01 编辑
杨为民 发表于 2023-10-31 18:23
（1）LZZ1983移植的uC/OS-II系统是有明确的中断嵌套保护功能的，在他的程序中：
/*------------------- ...
CosyOS 根本不存在中断嵌套保护这一说法（需求），原因是 CosyOS 不可能在中断嵌套的时候切换任务。
用户在中断中调用的服务，包括任务切换功能，都会挂起到PendSV（最低优先级中断）中统一执行，也就是说任务切换仅发生在PendSV中。
而PendSV是最低优先级中断，不可能在中断嵌套中（被套在其它中断里面）。
所以，不会出现由于任务切换而导致某个中断响应（LCALL）之后未返回（RETI）的情况。
本帖最后由 CosyOS 于 2023-10-31 20:07 编辑
我说当时设计CosyOS时，没考虑这么多，是因为根本就不需考虑，这是不存在的问题。
CosyOS没有类似 OSIntNesting++; OSIntExit(); 这样的代码。
UCOS中，OSIntNesting 可能还有别的其它用途（与服务调用相关），所以即使是在最低优先级中断PendSV中切换任务，可能也不能省略。
但 CosyOS 完全不需要这个功能。
本帖最后由 杨为民 于 2023-10-31 20:56 编辑
CosyOS 发表于 2023-10-31 19:25
CosyOS 根本不存在中断嵌套保护这一说法（需求），原因是 CosyOS 不可能在中断嵌套的时候切换任务。
用户 ...
所以，你还是要明确回答才好，否则我们也不好猜测，也不不好点评。首先肯定你采用的方法确实是一种好方法，只是你的说法不准确，下面我换个说法你看看会不会更准确一些，使得网友更能理解一些。
（1）在RTOS系统里中断嵌套保护的需求在实际应用中是确实存在的。其实这种需求一是可以从fanxsp网友在第15楼的理论分析得到证实，二是可以从主流RTOS都具有中断嵌套保护这个功能得到证实。
（2）最近在论坛中讨论很多的uC/OS-II简单明了地使用了一种“采用中断嵌套变量来跟踪中断嵌套的层数“”的中断嵌套保护方法。但是这不是中断嵌套保护的唯一方法，更不是、甚至不是一种中断嵌套保护的优秀方法。不同类型的单片机有不同的中断机制，自然有不同的RTOS系统中断嵌套保护方法。甚至现代的单片机CPU架构专门为此做了设计，在硬件机制和指令架构层面提供了这种保护。
（3）具体到对于现在的STC32G/F和STC8系列单片机，CosyOS采用了一种特殊的中断嵌套保护方法：最低优先级中断任务切换法。
1）这种方法将“用户在中断中调用的服务，包括任务切换功能，都会挂起到PendSV（最低优先级中断）中统一执行，也就是说任务切换仅发生在PendSV中。”
2）“而PendSV是最低优先级中断，不可能在中断嵌套中（被套在其它中断里面）。”
3）“所以，不会出现由于任务切换而导致某个中断响应（LCALL）之后未返回（RETI）的情况。”
因此对于CosyOS系统根本不存在中断嵌套时进行任务切换的情况，自然对于CosyOS 根本不再需要其他的中断嵌套保护方法。
（4）最低优先级中断任务切换法的优点是不再涉及中断时和退出时到底执行几条指令的细节，只需要将含有任务切换的中断放在最低优先级中断即可，但缺点是如果要允许在其他高优先级中断中使用系统功能请求，就需要为这些请求建立队列。这也就是CosyOS为系统请求建立队列的原因。（题外话，对于CosyOS的请求队列，我认为采用LIFO比FIFO好。固然FIFO满足因果的时间序列关系，但是LIFO是按中断嵌套的中断优先级先处理优先级高的任务，可以保证实时性要求）
（5）对于移植已经成型的像uC/OS-II和FreeRTOS，其实也可以采用这种“低优先级中断任务切换法”的。熊仔盯着我问为什么我的移植版教学范例中要使用两个定时器中断，现在公布正式答案：将系统节拍放在定时器0中断，并将优先级提到最高，保证RTOS系统节拍中断精确性（比如休眠时间），将任务切换放在最低优先级的定时器4就是一种“中断嵌套保护方法”。
CosyOS 发表于 2023-10-31 19:54
我说当时设计CosyOS时，没考虑这么多，是因为根本就不需考虑，这是不存在的问题。
CosyOS没有类似 OSIntNes ...
“UCOS中，OSIntNesting 可能还有别的其它用途（与服务调用相关），所以即使是在最低优先级中断PendSV中切换任务，可能也不能省略。”
这个结论很正确！
杨为民 发表于 2023-10-31 20:54
“UCOS中，OSIntNesting 可能还有别的其它用途（与服务调用相关），所以即使是在最低优先级中断PendSV中 ...
杨老师总结的非常到位！
CosyOS 不是没有中断嵌套保护，只是未采用中断嵌套变量跟踪法，而是采用的最低优先级中断任务切换法。
其实LIFO实现起来要比FIFO相对简单许多（Arm内核时），正是考虑到服务的执行时序（尤其是一个中断的多次进入），
才采用了FIFO。Keil RTX 也是采用的FIFO。CosyOS-I 时，就想用FIFO，只是限于个人当时的技术水平未能实现。
本帖最后由 tzz1983 于 2023-10-31 21:39 编辑
CosyOS 发表于 2023-10-31 19:25
CosyOS 根本不存在中断嵌套保护这一说法（需求），原因是 CosyOS 不可能在中断嵌套的时候切换任务。
用户 ...
我认同CosyOS的观点, 用中断切换任务, 确实是可以没有OSIntNesting这个功能的.
对于OSIntNesting, 我自己也是感觉到很不舒服. 平白无辜的让中断加上两条语句, 这不是我想要的.
之前fanxsp也提到过考虑彻底取消OSIntNesting功能.
看来OSIntNesting是犯众怒了哈.
如果让我重新编写一个全新的OS, 我会和CosyOS一样毫不犹豫的彻底取消OSIntNesting这个功能. 因为用中断切换任务没这个必要.
但是, 对于UCOSII移植, 只是做了一个移植. OSIntNesting穿插于OS大量篇幅, 取消它不是一个好的选项.
也是鉴于此, 我在"UCOSII - STC32G12K128使用技巧提示" 一贴中详细描述了, 现有版本什么时候可以不使用OSIntNesting和OSIntExit(), 从而让一部分中断可以从中解脱出来.
大家可以帮我找找 "UCOSII - STC32G12K128使用技巧提示" 论贴中是否有未考虑周到, 遗漏的地方.或者是说错的地方.