低优先级线程，添加比较多的条件语句，会导致高优先级的线程调度问题

发布于 2022-09-04 19:35:04 浏览：820 订阅该版

高优先级的线程播放音频，低优先级的线程负责按键和显示，当按键和显示条件越加越多，而实际上都没有执行，也会影响高优先级的调用时间片。中间多加几个sleep也没用。不理解这个是什么原理，高手帮忙解释下

2 个回答

小小李sunny 2022-09-04

这家伙很懒，什么也没写！

高优先级的线程会抢占运行，所以应该不是这个低优先级的线程所影响的。
建议排查一下其他的代码，或者把你的代码贴出来看看

Clark 2022-09-04

这家伙很懒，什么也没写！

按键处理逻辑，其中按键和显示线程优先级是21，音频接收和播放线程优先级都是19，下方有一个#if 1, 如果改成#if 0 ,播放时序就必定被打乱。实际上，AudioBox(display.ui.mode) 一直都是LCD_UI_MODE_COMMON，没有按键时不会进去其他模式，但是表现是播放时序明显变慢。

Description: KeyPad Thread entry
Para: parameter form thread creation
Return: void


void keyPad_entry(void *parameter)
{
    uint32_t  keystate=0;
    rt_kprintf("Enter KeyPad Procress\n");
    while(1)
    {
        keystate = ~(GPIO_ISTAT(KEY_PAD_GPIO_PORT)&(KEY_PAD_ALLPIN_VALUE)) & KEY_PAD_ALLPIN_VALUE;
        if(keystate & KEY_PAD_ALLPIN_VALUE)
        {
            /*execute different key event function by mode*/
            switch(AudioBox(display.ui.mode))
            {
                case LCD_UI_MODE_COMMON:
                    ProcessKeyWithCommonMode(keystate);
                    break;
                case LCD_UI_MODE_EDIT:
                    ProcessKeyWithEditMode(keystate);
                    break;
                case LCD_UI_MODE_EXTERN:
                    ProcessKeyWithExternMode(keystate);
                    break;
                default:
                    break;
            }
            /*any key will recount idle*/
            AudioBox(display.ui.ui_timeout) = 0;
            keystate = 0;
            rt_thread_mdelay(180);
        }
        LockThread();
        if(AudioBox(display.ui.pMenu->menuindex) != AudioBox(display.ui.changeMenu))/*Menu changed*/
        {
            if(AudioBox(display.ui.pMenu->menuindex) == LCD_UI_MENU_PAIREDDEV_LIST)
            {
                //free paired list
                AudioBoxPairedDevList_t * pFree = AudioBox(btdevice.paired_list);
                AudioBoxPairedDevList_t * pNextFree;
                while(pFree !=NULL)
                {
                    pNextFree = (AudioBoxPairedDevList_t *)pFree->p.next;
                    rt_kprintf("Free Device: %s\r\n",pFree->device.u8Name);
                    rt_free(pFree);
                    pFree = pNextFree;
                }
                AudioBox(btdevice.paired_num) = 0;
            }
            /*Display menu*/
            AudioBox(display.ui.pMenu) = LcdUiDisplayMenu(AudioBox(display.ui.changeMenu));
            /*Display external context*/
            LcdUiDisplayUpdateExtContext(AudioBox(display.ui.changeMenu),TRUE); 
        }
        else if(AudioBox(display.ui.changmode))/*mode changed*/
        {
            AudioBox(display.ui.changmode) = FALSE;
            LcdUiDisplayUpdateExtContext(AudioBox(display.ui.pMenu->menuindex),FALSE);
        }
        else if(AudioBox(display.ui.op_change)) /*select changed +*/
        {
#if 0
            LcdUiDisplaySelect(AudioBox(display.ui.pMenu),AudioBox(display.ui.op_value)>0,AudioBox(display.ui.op_change));
#else
            switch(AudioBox(display.ui.mode))
            {
            case LCD_UI_MODE_COMMON:
                LcdUiDisplaySelect(AudioBox(display.ui.pMenu),AudioBox(display.ui.op_value)>0,AudioBox(display.ui.op_change));
                break;
            case LCD_UI_MODE_EDIT:
                if(AudioBox(display.ui.op_value))
                {
                    AudioBox(display.ui.op_value) = FALSE;
                    LcdUiDisplayEdititem(&AudioBox(display.ui.pEdit->pEdititem)[AudioBox(display.ui.pEdit->edit_idx)],\
                                          AudioBox(display.ui.pEdit->edit_idx),LCD_CMD_INTVERT_FONT_12,AudioBox(display.ui.pEdit->value));
                }
                else
                {
                    LcdUiDisplayEditByIndex(AudioBox(display.ui.pEdit),AudioBox(display.ui.pEdit->edit_idx), 
                                            AudioBox(display.ui.pEdit->pre_edit_idx));
                }
                break;
            case LCD_UI_MODE_EXTERN:
                LcdUiDisplayExternMode(AudioBox(display.ui.pMenu->menuindex),AudioBox(display.ui.Extern.deep_level), \
                                       AudioBox(display.ui.Extern.select),AudioBox(display.ui.Extern.preselect));
                break;
            default:
                break;
            }
#endif
            AudioBox(display.ui.op_change) = FALSE;    
        }
        else
        {
            LcdUiDisplayUpdateBtState(AudioBox(display.ui.pMenu->menuindex));
        }
        UnLockThread();
        rt_thread_mdelay(20);
    }
}

Clark 2022-09-06

这家伙很懒，什么也没写！

实测就是低等级的判断逻辑或者线程数多了，就会影响高等级的处理时序，证明线程调度还不是很智能,我把msh线程删了就可以工作了

winfeng 2022-09-06

这家伙很懒，什么也没写！

1 线程调度本来就不是智能，是规则，优先级和时间片；
2 看一下你的CPU是不是够用；
3 看一下你的低优先级任务里是不是关中断、锁任务调度了；
4 看一下你的中断是不是占用过长时间；

Clark 2022-09-12

这家伙很懒，什么也没写！

@winfeng
感谢回复。
困扰了我快一周，最终验证测试，是因为代码空间超出了一定大小，可以执行，但是效率变得非常低。估计GD32的code area 超出之后512K就需要做重新寻址。

我验证方式是，低等级线程（按键处理）在一定的条件后直接退出。此时高等级的线程（音频接收和播放）调度依旧会受影响。当删除掉一点其他代码，就又正常了。所以是和代码大小有关，和线程调度应该没有关系

调查到这里就有点尴尬了。本身我是做蓝牙协议栈的。压缩得很辛苦才勉强够用。
各位大侠有什么好的建议吗？

下方粗体的是编译最终大小的信息。

Build started: Project: project
* Using Compiler ‘V5.06 update 6 (build 750)’, folder: ‘C:\Keil_v5\ARM\ARMCC\Bin’
Build target ‘rt-thread_gd32f4xx’
compiling key_pad.c…
applications\key_pad.c(765): warning: #111-D: statement is unreachable
rt_kprintf(“exit KeyPad Procress\n”);
applications\key_pad.c(359): warning: #177-D: function “ProcessKeyWithEditMode” was declared but never referenced
static void ProcessKeyWithEditMode(uint32_t keystate)
applications\key_pad.c: 2 warnings, 0 errors
linking…
Program Size: Code=345404 RO-data=115684 RW-data=1372 ZI-data=139068
FromELF: creating hex file…
“.\build\rtthread-gd32f4xx.axf” - 0 Error(s), 2 Warning(s).
Build Time Elapsed: 00:00:06
Load “C:\workspace\EsMcuStack_gd32450vit6\build\rtthread-gd32f4xx.axf”

JLink Info: Device “CORTEX-M4” selected.
Set JLink Project File to “C:\workspace\EsMcuStack_gd32450vit6\JLinkSettings.ini”
JLink Info: Device “CORTEX-M4” selected.

**

出出啊 2022-09-12

恃人不如自恃，人之为己者不如己之自为也

看 gd 的芯片手册，关于 flash 容量大小，看过了会有些莫名的被骗的感觉，宣称的大小不是一般意义的大小。跟乡镇银行推销理财产品一样一样的。
@Clark

winfeng 2022-09-12

这家伙很懒，什么也没写！

还能这样？是不是类似那种整块儿cache

Clark 2022-09-13

这家伙很懒，什么也没写！

@出出啊
是的，他有两个区域，一个代码区域，一个存储区域。
然后我自虐用他来做蓝牙音频。当然，放弃掉蓝牙电话协议，只是音频，应该也是够。
做完这波再说吧，还好是预研，不是直接上产品，要不周期不知道要拉长多久。

GD的坑不止这个，还有DMA，还有各种寄存器不清不楚

Clark 2022-09-13

这家伙很懒，什么也没写！

@winfeng
我理解的是代码区域是映射表可以操作的地方，至于IC的内核怎么设计我就不了解了。
个人觉得应该覆盖整个Flash应该也不麻烦，可能会损失性能吧。

应该不是Cahche的概念，因为RAM只保留当前运行的函数和全局变量。运行结束之后就释放了。
看起来更像是内核管理Flash区域就只有512K，多出的也可以放代码，但是要重新做一遍寻址。这样就会额外消耗运算时间。

表现现象就是，多加点代码（即使当前不运行），也会导致音频处理线程效率变低。

请登录后再发布评论，点击登录

追加回复

Clark 2022-09-04

这家伙很懒，什么也没写！

代码贴出来有点乱，大概整理下逻辑。

线程进来后。死循环，先检测是否有按键按下，如果有，休眠180ms给其他线程（且作为防抖）。
接着根据不同的操作查看是否需要更新显示。如果需要，则更新显示后休眠20ms

循环一直执行

出问题的时候打印线程
thread pri status sp stack size max used left tick error

BtStack 19 ready 0x0000006c 0x00005000 13% 0x00000033 -01
Usart_Read 19 ready 0x00000064 0x00001000 35% 0x00000064 000
Usart_Write 19 ready 0x00000074 0x00001000 04% 0x00000010 -02
Keypad 22 ready 0x00000060 0x00000800 16% 0x00000005 -02
tshell 24 suspend 0x00000070 0x00001000 02% 0x00000007 000
sys_work 23 suspend 0x00000048 0x00000800 03% 0x0000000a 000
ulog_async 30 suspend 0x0000005c 0x00000400 08% 0x00000014 000
tidle 31 ready 0x00000054 0x00000100 32% 0x00000017 000