本帖最后由 tzz1983 于 2023-11-6 22:05 编辑
CosyOS 发表于 2023-11-6 16:43
我只是简单介绍一下CosyOS对栈的处理，仅供参考，当然也欢迎大家批评指正。
我观STC官方移植的FreeRTOS-S ...
说的很到位
我有一个想法: 进入中断时,保存一下当前的堆栈指针, 然后把MSP(main函数用的那个堆栈指针)写入SP, 中断函数内的开支就只会用MSP, 退出中断时, 恢复进入中断时的堆栈指针,然后再RETI.
如果能以这种简单方法实现, 那就是 开支小 作用大, 确实有必要了去实践一下了.
先沉淀一些时日, 过几天再动手.
动态堆栈应该没那么简单吧, 代码会增加不少, 个人理解, 重新匹配堆栈时, 切换任务的时间会不确定.
Cosyos 有很多前卫的理念, 确实是值得学习的.
我还有一个想法: 就是为每个任务单独设置临界区, 各个任务相互之间没有影响,这样的话, 可以在临界区内进阻塞，或切换任务了, 毫无顾忌.因为进入到新的任务时, 是用新的临界区设置, 而不是一直关闭EA, 一直关闭EA导致新的任务功能受限, 如果不是有意为之,那就是犯错.
还有一个好处就是,在临界区调用外部代码时, 有时候会无意中触发了阻塞，或切换任务, 如果没有相关的支持, 则后果无法预料。
但是也很纠结， 从原则上来说, 临界区应该是对应整体的, 进入临界区后就是不能被打断, 也不能切换.
我以前是很讨厌这种花里胡哨, 不实用的东西的. 但现在为什么自己也会往这方面想呢.
放个话题出来, 大家一起来讨论一下
本帖最后由 CosyOS 于 2023-11-6 23:28 编辑
tzz1983 发表于 2023-11-6 22:00
说的很到位
我有一个想法: 进入中断时,保存一下当前的堆栈指针, 然后把MSP(main函数用的那个堆栈指针)写 ...
你的这个想法很好。
这个想法我最早就产生过，就是让251也如同arm一样，实现MSP+PSP模式，不过还是失败了。
最近我又思考了这个问题，结果仍然是实现不了。
但你可以实现，其它的RTOS也能实现，唯有CosyOS不行。
祝你早日成功！
关于临界区的问题，我也有自己的观点，不过等再沉淀一段时间再说，时间是个好东西。
本帖最后由 CosyOS 于 2023-11-7 00:05 编辑
任务栈重分配机制是做为一种补救手段，不建议用户过分依赖。
开发调试时，还是要配置够用的任务栈，保证测试阶段不会溢出。
但正所谓没有人能够确定明天的太阳一定会升起，但实时上它总是会升起来的。
概率问题，也许你测试一年也不会碰到一次任务栈溢出，但大批量产品投入使用后不一定哪天就会碰到。
如果内存足够大，问题也好解决，但51/251的内存有限，既要节约着用还不要栈溢出就得用点策略了。
任务栈重分配机制的意义就在于此。
时间不确定又能有多不确定呢？我经常做这种测试，没见过一次由于任务栈重分配而导致的系统卡顿，不确定总比系统瘫痪要强的多。
但重点还是说，任务栈重分配机制是做为一种补救手段，不建议用户过分依赖。
开发调试时，还是要配置够用的任务栈，保证测试阶段不会溢出（不会发生重分配）。
任务栈重分配次数多了会导致内存碎片，如果过分依赖的话，反而会导致内存更加不够用了。
任务栈重分配机制，就是为了当 “万一哪一天任务栈溢出了呢？”能够满血复活。
本帖最后由 CosyOS 于 2023-11-8 13:38 编辑
tzz1983 发表于 2023-11-6 22:28
我还有一个想法: 就是为每个任务单独设置临界区, 各个任务相互之间没有影响,这样的话, 可以在临界区内进 ...
关于临界区的问题，我先说一下我的观点，也即CosyOS的指导建议：
对于临界区的应用，要坚持“快进快出”的基本原则，耗时长的代码尽量不用临界区，能用互斥量保护的尽量不用临界区保护，
整个临界区内代码的运行时长要远小于系统滴答周期，这将促使整个系统良性的运行。
CosyOS为实现零中断延迟，把系统滴答中断放到了最低优先级，如果临界区内代码的运行时间过长，可能会延误系统滴答，使系统节拍、软件定时器等计时不准（变慢）。
我认为我的这个观点是符合现代RTOS理念的，不知大家意见如何？
关于RTOS临界区内是否应该允许任务切换，我看还是专门开一个帖子讨论为好。
本帖最后由 tzz1983 于 2023-11-8 13:47 编辑
CosyOS 发表于 2023-11-8 13:18
关于临界区的问题，我先说一下我的观点，也即CosyOS的指导建议：
对于临界区的应用，要坚持“快进快出” ...
是的，临界区是影响OS快速响应的关键因素， 要尽量减短执行时间， 商用的OS就有最大响应时间这样一个指标。
有一些技巧可以避免过长的临界区，我见过比较经典的是，在UCOS的一段代码里， 把一个长临界区分成两个， 先执行一部分做好名项标识， 中途退出执行一个空函数调用（这个时间如果有中断请求就可以响应，故意这样做的）， 接头又一头砸进临界区了，做没做完的事情。
一般的用法都是做好标识，独占资源后就退出临界区，千万不要直接在临界区内执行大量代码
如果数据只在任务间共享是不用进临界区的，暂停一下调度器即可
请问RTOS的教程应该看哪个帖子
WangChong 发表于 2023-11-9 12:27
请问RTOS的教程应该看哪个帖子
先海选, 然后根据自己的感觉挑一个重点学习, 我本人觉得UCOSII入门不错, 网上资料比较多, 代码量不大, 功能很全, (麻雀虽小, 五脏俱全)
tzz1983 发表于 2023-11-9 13:52
先海选, 然后根据自己的感觉挑一个重点学习, 我本人觉得UCOSII入门不错, 网上资料比较多, 代码量不大, 功 ...
谢谢
本帖最后由 tzz1983 于 2023-11-15 21:38 编辑
UCOSII - 251内核实现MSP(中断专用堆栈)代码已实现
介绍:
STC32G12K128 内含4K EDATA, 植入UCOSII后, 去掉1500字节左右固定开销外, 实际剩下2500字节可用.
在没有MSP(中断专用堆栈)前, 中断发生在哪个任务, 即沿用哪个任务的堆栈. 实际上中断用栈量很大. 举例说明: 如果中断内调用函数, 就是寄存器全入栈, 大约38字节, 4个优先级最多嵌套3次 38*3=114字节.
使用MSP(中断专用堆栈)后, 每个任务可节省 114字节, 假设8个任务+2个系统任务(空闲, 统计),则节省114*10=1140字节,这都差不多是2500总数的一半了, 说性能翻倍也不过份.
代码已做完, 正在整理中, 估计明天会发出.
先给两张实测数据图:更直观的体现出用MSP功能以后, 单个任务节省的用栈量!
这是由UCOSII内置统计任务产生的数据, 由prinft()函数打印到CDC串口.
测试条件: 人为故意产生4个中断,嵌套3级, 每个中断代码都简单的调用一个空函数, 以演示寄存器全入栈的极端情况.
实测数据: 单个任务相差179-72=107字节, 与理论计算值相差不大.(当然了, 实际上代码会变简单或复杂, 结果都会不一样的, 这里只做一个参考, 而不是绝对)
这次代码改动比较大, 正在整理中, 先发个预热{:lol:}， 估计明天发代码