tzz1983 发表于 2023-10-31 21:30
我认同CosyOS的观点, 用中断切换任务, 确实是可以没有OSIntNesting这个功能的.
对于OSIntNesting, 我自己 ...
全新编写一个RTOS实在是太累了，我都不知道自己是怎么坚持到今天的，无数个不眠的夜晚，才有了今天的一点成绩。
如果能重新选择一次的话，我一定会说 {:4_212:}。
现在也来得及呀
本帖最后由 tzz1983 于 2023-10-31 22:17 编辑
CosyOS 发表于 2023-10-31 22:05
现在也来得及呀
来不及的, 现今太忙, 手上新旧板子独立项目加起来至少百来个. 不年轻了, 被房绑了, 没冲劲了呀. 有空必客串
tzz1983 发表于 2023-10-31 22:14
来不及的, 现今太忙, 手上新旧板子独立项目加起来至少百来个. 不年轻了, 被房绑了, 没冲劲了呀. 有空必客 ...
随时欢迎{:4_196:}
【已经在去响应中断，并且是在去中断向量入口地址的途中】，就不可能被打断，去到中断服务程序后，就是高中断优先级打断低中断优先级的事 神农鼎已确认不会，那在中断向量表放关中断指令或 OSNesting++ ,应该也可以。
fanxsp 发表于 2023-11-1 00:21
【已经在去响应中断，并且是在去中断向量入口地址的途中】，就不可能被打断，去到中断服务程序后，就是高中 ...
是的
本帖最后由 tzz1983 于 2023-11-1 09:30 编辑
fanxsp 发表于 2023-11-1 00:21
【已经在去响应中断，并且是在去中断向量入口地址的途中】，就不可能被打断，去到中断服务程序后，就是高中 ...
我的理解是：响应中断过程相当于一个元子操作，不可分割.但这一过程在到达向量口时就已经算结束了。
“路上不可打断” 和 “在中断向量表放关中断指令或 OSNesting++ 仍然保险” 没有因果关系.
他说的是在路上不会被打断。对于响应来说，到达向量口己是路的终点，之后就是高优先级打断低优先级的事情了 ，如此说在中断向量表放关中断指令或 OSNesting++ 是不保险的
CosyOS 发表于 2023-10-31 21:19
杨老师总结的非常到位！
CosyOS 不是没有中断嵌套保护，只是未采用中断嵌套变量跟踪法，而是采用的最低优 ...
送佛送到底，你的队列都已经研究过FIFO和LIFO了，建议在单片机RTOS中你再采用标准操作系统理论中的“高优先级先处理的策略”试试：对于一个操作请求队列，将队列按任务的优先级排列，高优先级的任务先处理，对于相同优先级的任务的操作请求，按照请求的次序处理。
（1）对于uC/OS-II这样的每个任务优先级不同的RTOS，对于同一任务，按时序处理，可以满足你前面关于CosyOS按FIFO处理的正确的考虑，避免出现因果冲突。对于不同优先级，由于不是同一个任务，不存在时序因果冲突，按优先级处理，是抢占式任务调度的原则，可以保证RTOS的实时响应。
（2）对于那些具有分时任务功能的RTOS，当同一优先级对应多个任务时，可以采用为同一优先级的任务组里的每个任务静态地分配不同的“子优先级”或者动态地分配不同的“子优先级”（当前任务优先级最高，下一个分时任务优先级次之，等等）的方法将所有的任务划分为不同的优先级就可以使用这种策略。
（3）实现这种“高优先级先处理的策略”的程序思路并不困难，只是如果队列是采用链式表时程序要复杂一些，相信以你的功力实现只是要花点时间而已。期待你的CosyOS能将这三种队列处理方法都实现作为选项提供给用户选择使用。
tzz1983 发表于 2023-11-1 06:32
我的理解是：响应中断过程相当于一个元子操作，不可分割.但这一过程在到达向量口时就已经算结束了。
“ ...
也有道理，还得请神农鼎来回答
请问神农鼎