找回密码
 立即注册
楼主: Cos***

RTOS 线上教学继续中:全局不关总中断的CosyOS for STC,20课时

 火... [复制链接]
  • TA的每日心情
    奋斗
    昨天 13:57
  • 签到天数: 171 天

    [LV.7]常住居民III

    5

    主题

    572

    回帖

    2325

    积分

    荣誉版主

    积分
    2325
     楼主| 发表于 2023-7-16 18:14:18 | 显示全部楼层
    本帖最后由 CosyOS 于 2023-7-16 20:13 编辑

    CosyOS 最新版 V3.3.0-beta 发布了!


    CosyOS 内核优化已接近完善,以后不会再有大的调整,未来主要是注释及说明文档需进一步完善。

    现发布相关的示例代码:

    一、CosyOS-STC32G-CORE-V1.0.9-Library-DemoCode-20230716(CosyOS内核版本 V3.3.0-beta,附带所有说明文档)
    CosyOS-STC32G-CORE-V1.0.9-Library-DemoCode-20230716.zip (5.23 MB, 下载次数: 49)

    二、CosyOS-STC8-TEST-V1.1.1-20230716(CosyOS内核版本 V3.3.0-beta,附带所有说明文档)
    CosyOS-STC8-TEST-V1.1.1-20230716.zip (1.42 MB, 下载次数: 53)

    三、CosyOS-STC32G-TEST-V1.1.1-20230716(CosyOS内核版本 V3.3.0-beta,附带所有说明文档)
    CosyOS-STC32G-TEST-V1.1.1-20230716.zip (4.87 MB, 下载次数: 50)


    最新版调整记录:
    1、重新调整了任务服务,采用了统一的策略,使其可适用于任何MCU和编译器且都能实现较高的性能。
    2、取消了MCU配置文件中的内存优化选项。
    3、其它调整及优化。



    未来,如非必要将不再发布上述同功能的示例代码。



    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-3-17 14:35
  • 签到天数: 2 天

    [LV.1]初来乍到

    1

    主题

    8

    回帖

    139

    积分

    注册会员

    积分
    139
    发表于 2023-7-18 10:15:33 | 显示全部楼层
    测试了一下CosyOS-STC8-TEST-V1.1.1-20230716,将其taskmagr打开,即设SYSCFG_DEBUGGING        1,得到如下测试结果:

    [10:06:23.500]接收←Co3954
                        syOS Taskmgr                      100.00%            
                        Name               TID   TPL   STA      CPU          RAM
                        
                        Taskmgr              1     7   RDY    0.26%      7B/m23B
                        Debugger             4     7   SPD       0%      7B/m23B
                        task_C               7     4   DLY    0.08%    14B/m128B
                        task_A               5     3   BIN   55.57%     9B/m128B
                        task_B               6     2   RDY   56.07%     9B/m128B
                        Sysidle              3     0   RDY       0%      7B/m23B
                        
                        Task-PC: 54C7.
                        SysTick: 21.31us.
                        
                        
    [10:06:24.500]接收←Co3954
                        syOS Taskmgr                      100.00%            
                        Name               TID   TPL   STA      CPU          RAM
                        
                        Taskmgr              1     7   RDY    0.26%      7B/m23B
                        Debugger             4     7   SPD       0%      7B/m23B
                        task_C               7     4   DLY    0.08%    14B/m128B
                        task_A               5     3   RDY   57.57%     9B/m128B
                        task_B               6     2   BIN   60.07%     9B/m128B
                        Sysidle              3     0   RDY       0%      7B/m23B
                        
                        Task-PC: 5745.
                        SysTick: 21.34us.

    发现一是性能数据从1万多降到了3954([10:06:24.500]接收←Co3954),二是TaskA和B的CPU占用率加起来超过100%。
    请问这两个现象是正常的吗?

    点评

    开启任务管理器后,测试分数急剧下降是正常现象,因为任务管理器虽是经过特别的优化处理非常高效,但相较如此简单的测试任务,还是会占用更多的时间。 再者,开启任务管理器后,会增加两个任务,Taskgmr、Debugger  详情 回复 发表于 2023-7-18 13:32
    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 13:57
  • 签到天数: 171 天

    [LV.7]常住居民III

    5

    主题

    572

    回帖

    2325

    积分

    荣誉版主

    积分
    2325
     楼主| 发表于 2023-7-18 13:32:41 | 显示全部楼层
    leonling 发表于 2023-7-18 10:15
    测试了一下CosyOS-STC8-TEST-V1.1.1-20230716,将其taskmagr打开,即设SYSCFG_DEBUGGING        1,得到如 ...


    开启任务管理器后,测试分数急剧下降是正常现象,因为任务管理器虽是经过特别的优化处理非常高效,但相较如此简单的测试任务,还是会占用更多的时间。
    再者,开启任务管理器后,会增加两个任务,Taskgmr、Debugger,使得每次任务调度时,会从Taskgmr开始查询,而未开启任务管理器时,会从task_C开始查询。
    还有CPU利用率的统计、任务PC、系统滴答时间统计等,都会占用不少时间,最终导致测试分数下降。

    CPU利用率超过100%的问题,在正常使用时是不会出现的,只有在这种极限测试下才会出现。
    但这是否是因为算法上存在bug还不好说,下一步我会针对这个问题做进一步的分析和测试,并在未来公布结论。

    感谢你的反馈,希望大家都能多多测试,多提异议!


    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 13:57
  • 签到天数: 171 天

    [LV.7]常住居民III

    5

    主题

    572

    回帖

    2325

    积分

    荣誉版主

    积分
    2325
     楼主| 发表于 2023-7-19 22:14:12 | 显示全部楼层
    本帖最后由 CosyOS 于 2023-9-10 12:18 编辑

    CosyOS 的三大技术特点

    今天,我们从实际出发,来谈一谈CosyOS的技术特点,而不是采用“假大空”、“高大上”的方式,如“某某风格”、“面向某某”,等华丽的词藻。

    一:内核对象静态创建
    CosyOS的内核对象,一般采用静态创建方式,这样可以一步完成创建,简单易用。
    调用API操作内核对象时,一般均输入内核对象的名称,而非句柄指针,具体请参考API相关说明。

    二:所有内核全局不关总中断(零中断延迟)
    此前已做过多次论述,此处不再详述,只再重复一句话:
    ★★★只要您的用户中断不是最低优先级就可实现零中断延迟★★★

    三:独家技术实现系统服务的可重入,使51彻底摆脱可重入栈全面提速
    系统服务分为滴答服务、任务服务、中断同步服务、中断异步服务等,各类服务分别调用互不干涉。
    首先您需知道,系统滴答PendSV任务临界区中,三者之间是互斥访问的。详情请参阅《CosyOS-所有内核全局不关中断原理.md》。
    滴答服务:仅在系统滴答/定时器0中断中调用,所以不会重入。
    中断异步服务:服务的结构体指针入中断服务栈后在PendSV中执行,所以不会重入。
    中断同步服务:采用特别的优化,实现了服务函数的可重入(形参和局部变量均为寄存器变量),
    再配合互斥访问机制,实现了全局资源(全局变量、消息邮箱、消息队列)的互斥访问。
    详情请参阅源码,关于互斥访问机制,请参阅《CosyOS-所有内核全局不关中断原理.md》。
    任务服务:
    任务服务大体上可分为三类,需重点讲解一下:
    1:本地代码
    do{   \
       进入任务临界区;   \
       本地执行服务;   \
       退出任务临界区;   \
    }while(false)
    由于是本地独立的代码,并非调用函数,所以不存在重入的问题。
    CosyOS仅在两种情况下才会采用本地代码:
    (1):对于51单片机来说,调用函数的代码量(仅指调用过程,即传参)比本地代码的代码量还要大(如定时中断、定时查询);
    (2):如果不采用本地代码将无法实现服务功能(如发送私信)。

    2:调用服务函数(无返回值)
    do{   \
       进入任务临界区;   \
       调用服务函数();   \
    }while(false)
    由于是在进入任务临界区之后才调用的服务函数,所以服务函数是不会重入的,也不需要可重入。
    服务函数在返回时会自动退出任务临界区。

    3:调用服务函数(有返回值)
    (   \
       __enter_critical() || true ? 调用服务函数() : 返回一个其它值   \
    )
    采用三目运算,巧妙的实现了在进入任务临界区之后再调用服务函数并返回值。三目运算的优势在于可进行常量优化。
    __enter_critical()返回后,|| true,其结果必然为真,编译后将不再做条件判断,而是直接调用服务函数并返回值。“为假时返回一个其它值”也会被优化掉。

    下面以启动任务为例加以说明:

    /* API */
    #define /*|ecode|*/uStartTask(task, state)  sUSV_StartTask(&vTaskHandle_##task, state)

    /* 服务 */
    #define sUSV_StartTask(thdl, state) \
    ( \
       __enter_critical() || true ? __start_task(thdl, !state ? __READY__ : __READY__ | __SUSPENDED__) : false \
    )

    C51应用示例:
    uStartTask(sensor_task, __READY__);
    编译后:
    C:0xC026    12DA0B   LCALL    enter_critical(C:DA0B)
    C:0xC029    7E14        MOV      R6,#0x14
    C:0xC02B    7F06        MOV      R7,#0x06
    C:0xC02D    E4            CLR       A
    C:0xC02E    FD            MOV      R5,A
    C:0xC02F    12D4E8   LCALL    _start_task(C:D4E8)
    可见,编译后为三步:
    1、调用enter_critical();
    2、传参(R6、R7为任务句柄的指针,R5为任务状态);
    3、调用__start_task()。
    优化掉了其它无用的环节,厉害了吧?

    对于这一类服务又分为两种情况:
    一、在服务函数内会一气呵成,最后退出任务临界区并返回常量或寄存器变量。
    。。。。。。

    进入任务临界区 本地执行服务 退出任务临界区并返回
    。。。。。。
    这一类服务函数,在退出任务临界区之前是不会重入的,在退出之后是可重入的。
    由于这一类服务比较简单,不再举例说明。

    二、会中途退出任务临界区并触发任务调度,当再次回到当前位置时(任务切换回来时),会再次进入任务临界区并继续执行服务而后再退出任务临界区并返回常量或寄存器变量。
    。。。。。。
    第一阶段:进入任务临界区 服务入[vTASKING] 退出任务临界区并触发任务调度
    PendSV中切换任务(可能)
    第二阶段:再次进入任务临界区 继续执行服务 退出任务临界区并返回
    。。。。。。
    这一类服务是含有超时机制的服务,共包括八大服务:等待或获取二值信号量、获取互斥信号量、获取计数信号量、等待标志组、任务中接收飞信、任务中接收私信、任务中接收邮件、任务中接收消息。
    具体过程:(vTASKING 为当前任务节点的指针)
    1、在第一阶段,已将内核对象指针存入vTASKING->ptr
    2、而后在PendSV中,会访问非延时阻塞(超时阻塞)状态的各任务节点->ptr以调整任务状态、查找最高优先级的就绪任务
    3、在第二阶段,再次进入任务临界区后,将vTASKING->ptr赋值给内核对象指针变量,继续执行服务。
    这一类服务函数,在第一阶段是不会重入的,第二阶段也是不会重入的,但服务函数可能已经重入了(因为可能切换过其它任务)
    对于51来说,内核对象指针可能已经改变(因为内核对象指针变量有可能是内存变量,服务重入后指针将改变),
    所以需要将vTASKING->ptr再次赋值给内核对象指针变量以恢复原值,然后再执行服务。

    下面以获取二值信号量为例加以说明:

    /* API */
    #define /*|res|*/uTakeBin(bin, tc)  sUSV_TakeBin(bin, tc)

    /* 服务 */
    #define sUSV_TakeBin(bin, tc) \
    ( \
       __enter_critical()||true?__take_bin((bool *)&bin, tc):false \
    )

    /* 服务函数 */
    bool __take_bin(bool _XDATA_MEM_ *p, tDelay tc) // p为二值信号量指针变量,对于51来说,_XDATA_MEM_为xdata
    {
            if(*p) goto __RET_TRUE;
            if(!tc) goto __RET_FALSE;
            
            vDELAY_STMR[vTASKING->TID] = tc; // 赋值超时时间给延时定时器
            vTASKING->state = __BLOCKED__;     // 赋值当前任务状态为阻塞
            vTASKING->blocktype = __BINARY__ | sizeof(bool); // 赋值阻塞类型为二值信号量阻塞,指针为单字节数据类型
            vTASKING->ptr = p;               // 将二值信号量指针存入vTASKING->ptr
            suTaskScheduler;                    // 退出任务临界区并触发任务调度,当再次回到当前位置时,服务函数可能已经重入,对于51来说,内核对象指针可能已经改变
            p = (bool *)vTASKING->ptr; // 所以需要将vTASKING->ptr重新赋值给二值信号量指针变量
            if(*p) goto __RET_TRUE;       // 再次访问二值信号量指针变量
            
    __RET_FALSE:
            mExitCritical;
            return false;
            
    __RET_TRUE:
            *p = false; // 再次访问二值信号量指针变量
            mExitCritical;
            return true;
    }

    可见,通过上述方法,可完美实现这一类服务的可重入,使51彻底摆脱可重入栈全面提速。
    上述方法虽然会导致251、Arm等内核执行服务的性能稍有下降,但对于51来说,性能却有质的提升。
    而且此法还适用于任何MCU和编译器,都能确保安全可靠和卓越性能。
    对于51来说,在类型定义(os_redef.h)和服务函数中,内核对象指针变量一律指定指针域为xdata,这样操作不仅可显著的减少内存占用和代码量,还可提速。
    对于51来说,用户需注意,内存模型一定要选择Large。

    以上就是CosyOS的三大技术特点。(完)









    回复 支持 反对 送花

    使用道具 举报

    该用户从未签到

    551

    主题

    9441

    回帖

    1万

    积分

    管理员

    积分
    13983
    发表于 2023-7-19 23:13:47 | 显示全部楼层
    感谢,32位8051世界又向前跨了一大步
    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-3-17 14:35
  • 签到天数: 2 天

    [LV.1]初来乍到

    1

    主题

    8

    回帖

    139

    积分

    注册会员

    积分
    139
    发表于 2023-7-21 10:41:06 | 显示全部楼层
    假设一个任务是发送报文的,然后阻塞延时等待回应,根据回应的信息,这个任务可能会被立即激活发送下一个报文,也可能被设置等待更长的时间来让系统完成一些工作。这就要求可以激活阻塞延时任务的API和更改指定任务延时的API,但我没有在手册中看到。请问有这样的API吗?

    点评

    哦,我明白你的意思了,就是操作指定任务,让它立即结束阻塞延时状态并转为就绪状态,或更改它的阻塞延时时间,这些服务现在确实没有。 你的提议非常好,我考虑在下一版中,增加这些服务。  详情 回复 发表于 2023-7-21 13:52
    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 13:57
  • 签到天数: 171 天

    [LV.7]常住居民III

    5

    主题

    572

    回帖

    2325

    积分

    荣誉版主

    积分
    2325
     楼主| 发表于 2023-7-21 13:52:40 | 显示全部楼层
    本帖最后由 CosyOS 于 2023-7-21 14:42 编辑
    leonling 发表于 2023-7-21 10:41
    假设一个任务是发送报文的,然后阻塞延时等待回应,根据回应的信息,这个任务可能会被立即激活发送下一个报 ...

    哦,我明白你的意思了,就是操作指定任务,让它立即结束阻塞延时状态并转为就绪状态,或更改它的阻塞延时时间,这些服务现在确实没有。
    你的提议非常好,我考虑在下一版中,增加这些服务。

    对于“结束阻塞延时”的功能,可采用另一方法来实现。创建一个二值信号量,初值为false,发送报文后获取它(进入超时阻塞状态),解析完成后再释放它。
    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 13:57
  • 签到天数: 171 天

    [LV.7]常住居民III

    5

    主题

    572

    回帖

    2325

    积分

    荣誉版主

    积分
    2325
     楼主| 发表于 2023-7-26 21:23:56 | 显示全部楼层
    本帖最后由 CosyOS 于 2023-7-26 21:39 编辑

    CosyOS 最新版 V3.3.3-beta 发布了!


    版本更新记录

    V3.3.1-beta
    取消了报警信息:rts(任务栈重分配发生),因为任务栈重分配机制被定义为一种标准功能、常规手段。

    V3.3.2-beta
    调整了互斥信号量,使其均支持递归,最大嵌套深度:255。
    也就是说,从V3.3.2-beta版开始,互斥信号量就是递归互斥信号量。
    释放互斥信号量,由返回结果调整为返回错误码。
    优化并调整了系统配置文件和MCU配置文件。

    V3.3.3-beta
    新增服务:“设置延时”、“清除延时”,支持在任务、滴答、中断中调用。
    设置延时:设置指定任务的阻塞延时时间,前提是该任务当前为阻塞延时状态。
    清除延时:清除指定任务的阻塞延时状态,并使其就绪。


    CosyOS最新版下载(内核版本 V3.3.3-beta,附带所有说明文档):
    cosyos-master.zip (1.01 MB, 下载次数: 34)

    所有说明文档均已更新!!!
    CosyOS的套路有别于传统的RTOS,花一些时间来了解这些是非常必要的,《技术要点.md》有助于用户对CosyOS的了解。
    《开发流程.md》可使读者详尽的了解CosyOS的开发流程及注意事项,是非常重要的。





    回复 支持 1 反对 0 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-3-17 14:35
  • 签到天数: 2 天

    [LV.1]初来乍到

    1

    主题

    8

    回帖

    139

    积分

    注册会员

    积分
    139
    发表于 2023-7-27 07:47:16 | 显示全部楼层
    CosyOS 发表于 2023-7-26 21:23
    CosyOS 最新版 V3.3.3-beta 发布了!

    非常棒,这样我的更改任务延时值的问题就解决了。
    回复 支持 反对 送花

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-3-17 14:35
  • 签到天数: 2 天

    [LV.1]初来乍到

    1

    主题

    8

    回帖

    139

    积分

    注册会员

    积分
    139
    发表于 2023-7-27 09:08:16 | 显示全部楼层
    假设一个任务是处理报文的,处理好了检测下有没有新报文,没有就uSuspendTasking。报文到了有中断,所以在中断中iResumeTask(task, svid)。由于CosyOS全局不关中断,如果在uSuspendTasking的过程中新报文的中断来了,会不会造成这个任务最终被挂起而错过了新报文?
    另外,手册中关于svid的解释很少,调用时该如何设置这个值呢?

    点评

    uSuspendTasking是在任务临界区中执行的,iResumeTask(task, svid)是在PendSV中执行的,SysTick、PendSV、任务临界区中,三者是互斥访问的。 如果uSuspendTasking的过程中中断来了,在中断中恢复这个任务iResumeTask  详情 回复 发表于 2023-7-27 13:31
    回复 支持 反对 送花

    使用道具 举报

    高级模式
    B Color Image Link Quote Code Smilies |上传

    本版积分规则

    QQ|手机版|深圳国芯人工智能有限公司 ( 粤ICP备2022108929号-2 )

    GMT+8, 2024-5-16 05:03 , Processed in 0.088389 second(s), 68 queries .

    Powered by Discuz! X3.5

    © 2001-2024 Discuz! Team.

    快速回复 返回顶部 返回列表