tzz1983 发表于 2024-3-25 21:31
你要去偿试吗，这个估计要判断中断嵌套，我对FreeRTOS是真忘的差不多了，不知道FreeRTOS有没有现成的中断 ...
这么麻烦吗{:4_199:}
tzz1983 发表于 2024-3-25 21:31
你要去偿试吗，这个估计要判断中断嵌套，我对FreeRTOS是真忘的差不多了，不知道FreeRTOS有没有现成的中断 ...
好像也是，容易的话，之前移植的大神早就弄了
本帖RTOS移植版存在重大BUG，特此声明，已下载的坛友请及时回吐，避免造成不必要的损失。
BUG说明：最高优先级滴答中断可能在嵌套时直接返回任务级。造成中断系统紊乱。RETI指令缺少执行次数，可能使同级及以下所有中断无法再触发。
此BUG后果严重，由于晚上突然想到，来不及再次确认代码，便手机发出声明，如果说错了，明日自我删除，并向楼主道歉。
本帖最后由 tzz1983 于 2024-3-28 09:48 编辑
gentleman 发表于 2024-3-25 21:21
FreeROTS其实留了个 portYIELD_FROM_ISR() 接口
但移植后port里没实现
（1）“FreeROTS其实留了个 portYIELD_FROM_ISR() 接口，但移植后port里没实现”
是的，所以在官方范例里的ISR的编程模式大多数中断仍然停留在裸机编程的形式，没有说明，也没有做任何RTOS处理，这样的中断实际工作起来就可能产生危险。
（2）在中断ISR处理这方面 tzz1983的UCOS2最新移植版是做的最规范，最符合uC/OS-II的原设计理念的。可惜这位网友总是不擅长介绍自己的工作，也经常把已经研究到手宝贝随意放弃，玩性太大！
我这里就代他介绍一下他的UCOS2最新移植版的“中断服务程序ISR规范”，有我介绍得不清楚的地方或者有问题的，网友可以到他的主贴去提问，或者在这里向他提问，结合FreeRTOS一起研究交流。
《【uGFX/GUI + uC/OS-II】 @STC32G；uGFX/GUI@STC32G裸机》（https://www.stcaimcu.com/forum.php?mod=viewthread&tid=7130&extra=page%3D1）
《UCOS-II@STC32G12K128 移植, 堆栈MSP+PSP模式，最新版本2024/3/19, tzz1983》（https://www.stcaimcu.com/forum.php?mod=viewthread&tid=4702&extra=page%3D1）
（3）以UART1串口1中断为例，下图第41到第48行程序为UART1的中断矢量：
下图第588到第611行程序为UART1的中断服务处理程序ISR：
在图中可以看到很规范的uC/OS-II中断处理程序
第596行 中断嵌套计数增加 OSIntNesting++;
第597行 打开总中断给用户 EA=1;
第598行 调用用户中断处理钩子 ISR_Handler_Hook4();
第599行 uC/OS系统退出中断处理 OSIntExit();
第600行关闭总中断进入系统临界区EA=0;
（4）下图第149行程序为UART1的中断处理钩子名转换，将绝对中断号转换为不同系列的STC单片机对应的设备名，方便用户使用：
下图第44到第50行程序为UART1的用户中断钩子函数：
图中是预留的空函数，实际应用时用户将自己的中断服务处理程序填在空白处就可以了。
下面是tzz1983的原程序：
tzz1983 发表于 2024-3-26 00:46
本帖RTOS移植版存在重大BUG，特此声明，已下载的坛友请及时回吐，避免造成不必要的损失。
BUG说明：最高优 ...
谢谢，最好明天详细解释一下，大家一起研究
tzz1983 发表于 2024-3-26 00:46
本帖RTOS移植版存在重大BUG，特此声明，已下载的坛友请及时回吐，避免造成不必要的损失。
BUG说明：最高优 ...
总算等到一个知音了, {:handshake:}
这个问题其实我早就在思考了, 难以解决.
否则也不会出 这么个一大堆人, 只要谁肯花力气, 就能轻松移植 OS 解决的题目了.
只是, 我不敢言, 被 XX 拍砖拍怕了
由于 XX 要求以实例 说话, 连点基本的理论常识也不认可, 我只能在努力测试,
以实时抓捕 OS 中, 程序返回出错跳飞的瞬间, 由于 STC32的仿真器实时性太差,
目前还没有成功抓捕到 OS 中的哪一瞬间.
当然, 抓捕到了 OS 中的那一瞬间, 也只能存认 OS的设计不够完美, 考虑不周全.
不能认为 XX 是错的, XX 永远正确.
咱们是草根, 常在河边走, 哪有不湿鞋?
我现在都不敢回话了, 回一句就一堆高帽子, 再回一句, 就如你所言:"被XX带歪了"
另外, 不希望你删此贴, 他代表了我的心声, 我想说而不敢说的话, 如错了, 我和你一起道歉,
如正确, 希望此贴继续红火下去, 为 STC论坛 打造一个高含金量的技术讨论贴, 而不是灌水贴.
在这里, 我要感谢 XX , 高高在上, 尽管从没正面回答过我的任何提问,
但是, 他的不回答, 给我带来了对问题的思考.
1. XX 有一贴, 讲的 STC32 完胜 STC8, 例举了 STC32 的 vprintf(可重入)完胜 STC8 的 printf(不可重入),
引起了我的兴趣, 最后成功改写了 51的 printf函数(可重入), 绕开了 c51必须使用固定区域 ram 传送可变参数的难题.
2. 很早之前, XX 曾有句话: 关闭中断, OS无法工作. (在小熊搞 os的时候, 谁说的现在没必要去追究),
但是, 这句话引起了我的思考, 使用 T0不可关闭定时模式, 超高中断级, 当嘀嗒定时器, 碰到的问题就是现在 tzz1983
提出的问题, 我一直在思考这个问题, 不断的设想各种解决方案, 再后来, 大家知道的, 我把本题拿出来讨论.
说实话, 当时我也没指忘谁能解决, 结果 XX 认为 本题 很简单, 他早就轻松解决, 拿出来对我口珠笔伐,
群众的眼睛是雪亮的, 大家都看在眼里.
不知 tzz1983 在哪工作.
你是及时雨, 我的福星, 看了你回贴, 我激动的无法用语言来形容, 这年代, 知音难寻啊~~~
如有机会, 路过你那里请你吃饭. 到时不要拒决哦
团结就是力量，砥砺前行
楼上 tzz1983 提的问题, 我来回答:
任务的切换（上下文切换）, 需保存 上下文（寄存器）+ 修正返回地址,
无论用时钟滴答定时器切换, 还是 PendSv 中断调用, 假如处于最低优先级.
其中断压栈内容是可知可控的(此时没有其他中断响应)
在任务中调用 PendSv, 其压栈内容也是可知可控的(此时没有其他中断响应)
同理, 无论在 时钟滴答定时器调用 软中断切换, 还是在任务中调用 软中断切换,
尽管 软中断具有排外性, 超高优先级(相当于关闭总中断) , 但其压栈内容也是可知可控的(此时也没有其他中断响应)
这样, OS就很容易 计算并 修正返回地址在 SP的存储位置,
假如单纯通过时钟滴答定时器切换(不可屏蔽超高优先级), 那么可能在响应中断时,
是打断了某级或多级中断嵌套后, 才进入 滴答定时器 中断, 而前面已响应中断的(某级或多级)压栈内容是不可控的, 随机的, 也可能在没有其他中断发生(无压栈内容) .
当没有其他中断发生时, OS 计算并 修正返回地址正确, 任务成功切换.
当有其他中断发生时, OS 计算并 修正返回地址不正确, 任务切换失败, 程序跑飞.
以上是纯理论分析, 当然, XX 要实例, 我还在努力, 努力捕捉 OS程序跑飞的那一刻.