具体的“时间参数”不好说，在未来我会尽可能的把一些“时间参数”具体化。
本帖最后由 CosyOS 于 2024-1-8 16:23 编辑
CosyOS-II 任务队列
CosyOS全局只有一个任务队列，为双向循环链表，所有已启动且未删除的任务，都会在队列上排队。
[*]排队原则
1、 在队列上从头至尾，按任务优先级由大到小排列。
2、 如果任务优先级相同，则按任务启动顺序排列（先启动的任务排在前面）。
3、 如果启用了任务管理器，那它一定是任务队列上的第一个任务（头节点）。
4、 唯一的例外，系统空闲任务是任务队列上的最后一个任务（尾节点），其它所有任务都会排在它的前面。
CosyOS任务管理器真实的反应了整个任务队列的当前形态。
其中任务ID（TID）是按任务的启动顺序动态分配的（从1开始++），真实的反应了任务的启动顺序。
下方示例中消失的任务（TID：2）为系统启动任务（Starter），任务启动完成后，该任务默认被自动删除。
感谢分享
我一直再找一个类rtos的在51上运行
rtx51 tiny也挺好用的
感谢分享,看着很酷,有空研究研究
本帖最后由 CosyOS 于 2024-1-24 15:29 编辑
CosyOS-II 最新版 V1.3.0 发布！
最新版新增了部分线程通信的临时调度，使CosyOS-II 任务切换的实时性进一步提升。
CosyOS的 任务调度时机 分为 定时调度 与 临时调度。
[*]定时调度
在每个系统滴答周期，系统滴答中断都会触发一次任务调度。
[*]临时调度
一、自动调度
当满足特定条件时，由系统自动触发的临时性的任务调度。
1、当前任务被阻塞、挂起、删除时，会立即触发任务调度。
2、恢复任务时，如果该任务被恢复后可以运行并且它的优先级高于当前任务的优先级，会立即触发任务调度。
3、设置任务优先级时，如果该任务可以运行并且它的新优先级高于当前任务的优先级，会立即触发任务调度。
4、设置阻塞时间为零或清除阻塞时，该任务会转为就绪状态，如果它的优先级高于当前任务的优先级，会立即触发任务调度。
5、归还互斥信号量完成时，如果发生了优先级继承（任务优先级被提升），会恢复该任务的原优先级，并立即触发任务调度。
6、归还二值信号量时，如果有任务因获取该信号量而阻塞，会立即触发任务调度。
7、归还计数信号量时，如果有任务因获取该信号量而阻塞，会立即触发任务调度。
8、给予二值信号量时，如果有任务因获取该信号量而阻塞，如果该任务的优先级高于当前任务的优先级，会立即触发任务调度。
9、给予计数信号量时，如果有任务因获取该信号量而阻塞，如果该任务的优先级高于当前任务的优先级，会立即触发任务调度。
A、发送私信至某任务时，如果该任务因接收私信而阻塞，如果该任务的优先级高于当前任务的优先级，会立即触发任务调度。
B、发送飞信时，如果有任务因接收该信箱的飞信而阻塞，如果该任务的优先级高于当前任务的优先级，会立即触发任务调度。
C、发送邮件时，如果有任务因接收该邮箱的邮件而阻塞，如果该任务的优先级高于当前任务的优先级，会立即触发任务调度。
D、发送消息时，如果有任务因接收该队列的消息而阻塞，如果该任务的优先级高于当前任务的优先级，会立即触发任务调度。
[*]以上 6~D 为最新版新增的自动临时调度。
二、手动调度
由用户手动触发的临时性的任务调度，包括任务级任务调度和中断级任务调度。
当无法满足自动调度条件，用户又期望特定线程能够更及时的处理事件，可采用手动调度。
[*]如事件标志组的应用，事件处理任务因等待标志组而阻塞，事件发生线程中设置标志位后，如希望事件被及时处理，可采用手动调度。
由此导致以下功能发生改变
1、创建二值信号量，原为：uCreateBin(bin) = init; 现调整为：uCreateBin(bin, init);
2、二值信号量不再支持查询功能。
3、消息邮箱必须声明，因为要在声明时类型定义。
4、创建消息邮箱，原为：uCreateMailbox(mbox, type); 现调整为：uCreateMailbox(mbox)，不再输入数据类型，仅在声明时输入即可。
5、事件标志组必须声明，因为要在声明时类型定义，以前的版本也是如此。
6、新增服务“发送信号”：iSendSign(sign)，被设计用来以同步方式实现在全局变量钩子中及时更新副本，详情待以后再做说明。
相关代码及说明文档待以后再发布。
CosyOS-II有关中断的部分说明
一、什么是零中断延迟？...略。
二、零中断延迟基本原理...略。
三、零中断延迟的意义
MCU的核心价值在于中断的使用，实现对紧急事件的及时响应并处理。如果RTOS内核以关闭总中断的方式来处理内核服务、保护临界段，则意味着可能会丢失对高速中断的响应，并导致处理延误。而 “丢失响应” 往往是致命的，“处理延误” 可能会引发不良后果。
[*]误区
即使关闭了总中断，中断被触发后标志位仍可置位，当开启总中断后仍可响应中断。
首先，这已经导致了“处理延误”，如果延误时间超出了允许范围，危害是可想而知的。
其次，如果关闭总中断期间，某个高速中断发生了两次或多次，当开启总中断后，也仅能响应并处理一次，即“丢失响应”。而有的事件，发生一次就得处理一次，如果有遗漏将导致致命的错误。
[*]示例
高速通讯（接收丢帧）
高速捕获（丢失脉冲）
高速PWM
高速ADC
事实上，RTOS以关闭总中断的方式来保护临界段，是最为直接有效的，可实现最少的指令。CosyOS通过特殊的方法来保护临界段，必然是走了一条弯路，需要执行更多的指令，牺牲了整体的运行效率，但同时确换取了零中断延迟，这一点与RTOS通过牺牲整体的运行效率来换取实时性（对紧急事件的优先处理）是相同的道理。
四、中断使用注意事项
[*]在CosyOS中，中断是系统脱管的，用户对中断的使用与裸机编程是一样的。
[*]只要中断不是最低优先级，就可实现零中断延迟。因此，用户中断应尽量避免使用最低优先级。[注1]
[*]用户中断应遵循快进快出的原则，对事件仅做必要的紧急处理，再以同步方式通知 中断服务任务 做后续处理。
[*]用户中断的最大执行时间应远小于系统滴答周期，这将促使整个系统更加良性的运行。
注1：其实，即使用户中断是最低优先级，也可能是零中断延迟的（当任务临界区未使用BASEPRI寄存器时），只不过
系统中断可能会与其抢占。而系统中断相对来说还是会占用更多的时间，可能会导致用户中断丢失响应或处理延误。
零中断延迟是CosyOS的宗旨，是原则和底线，必须坚决贯彻落实。
建议直接把顶楼改成最新最强大的说明，大家直接用最新的，
新程序打包时，里面含个旧版目录/含旧程序/方便想比较的
我技术推广转发时，直接转 【顶楼的文字截图图片+链接】 就行了
我如下风格转发的，所以顶楼说明永远更新到最新，无需历史上的版本说明
全局不关总中断的RTOS / CosyOS-II for STC MCU，最新版本2023/12/22更新说明 - FreeRTOS/实时操作系统/文件系统/嵌入式系统软件，TFT-GUI/uGFX - 国芯论坛-STC全球32位8051爱好者互助交流社区 - STC全球32位8051爱好者互助交流社区 (stcaimcu.com)
看的我热血沸腾的，加油STC，看好你，