欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

標(biāo)題: 關(guān)于單片機(jī)任務(wù)模式的解惑,時間片輪詢法 [打印本頁]

作者: 我,菜雞    時間: 2022-12-14 22:44
標(biāo)題: 關(guān)于單片機(jī)任務(wù)模式的解惑,時間片輪詢法
從接觸單片機(jī)開始,從開始的Delay延時,經(jīng)同事提醒Delay函數(shù)會空耗CPU弊端,所以逐漸少用Delay函數(shù)。因?yàn)榭紤]通用性(可能也因?yàn)閼校罱诜庋b模塊函數(shù),定時器、串口參數(shù),還有I/O口的宏定義以便于硬件修改。類似于下面這種:
#include "OLED.h"                //OLED小屏幕,模擬IIC
//SDA:PA6
#define OLED_SDA_GPIO_PORT        GPIOA        
#define OLED_SDA_GPIO_PIN                GPIO_Pin_6
//SCL:PA7                                                                                                               
#define OLED_SCL_GPIO_PORT  GPIOA        
#define OLED_SCL_GPIO_PIN     GPIO_Pin_7
這周一開始,逐漸有封裝任務(wù)函數(shù)的想法:時間片輪詢法,至于短期用不到的系統(tǒng)就先不搞了。
今天晚上突然反省一下:用時間片輪詢法,好處是什么?在數(shù)量比較少的情況下,用這種任務(wù)模式是不是多此一舉?
也煩請路過的各位大佬解惑,感謝!


作者: Y_G_G    時間: 2022-12-15 00:46
對于簡單而且是單一的程序而言,所謂'效率'有時候并不重要
比如我就一個LED手電,按鍵就是開關(guān)的作用而已,這個時候,去抖動,沒有什么比delay更爽的了,手電開了就開了,ADC用中斷,就再也沒有其它的事情做了,我還怕單片機(jī)累著了不成?
但是你也必須要學(xué)會提高單片機(jī)效率,有的系統(tǒng)對效率確實(shí)是有很高的要求的
對于你說的"時間片輪詢法"我沒學(xué)過,基于百度的理解,感覺這也不怎么好
我常用的辦法是:
1,先聲明一個全局變量 time,key結(jié)構(gòu)體其實(shí)也行,個人習(xí)慣而已
2,按鍵按下之后,time清除,key置位
3,在systick或者定時器中斷中,time++
4,主函數(shù)就是  if(key&&(time >= 50ms)//50mS由自己決定延時時間
{
key = 0;
執(zhí)行按鍵相關(guān)處理
}
這樣一來,隨便你按鍵怎么按,怎么抖動,它只作一個處理:       time = 0;  key = 1;
永遠(yuǎn)是以你最后松開按鍵之后,穩(wěn)定了之后的50mS,再執(zhí)行按鍵相關(guān)操作
按鍵讀取就只占用兩個語句的時間而已

作者: Hephaestus    時間: 2022-12-15 07:50
看樣子你用的是STM32,用CMSIS自帶的RTX5好了。
作者: 我,菜雞    時間: 2022-12-15 08:44
Y_G_G 發(fā)表于 2022-12-15 00:46
對于簡單而且是單一的程序而言,所謂'效率'有時候并不重要
比如我就一個LED手電,按鍵就是開關(guān)的作用而已,這 ...

有道理。所以我昨天晚上就突然反思了一下,好像沒什么明顯的提升,但是又想不出個所以然來。
作者: 我,菜雞    時間: 2022-12-15 08:46
Hephaestus 發(fā)表于 2022-12-15 07:50
看樣子你用的是STM32,用CMSIS自帶的RTX5好了。

對,雖然具體芯片不是STM的,但是用的是STM32的庫。CMSIS自帶的RTX5,我去搜一下。感謝
作者: coody_sz    時間: 2022-12-15 12:23
其實(shí)就是不用軟件延時,不要空耗時間,實(shí)現(xiàn)方式各種各樣,RTOS、時間片、時間觸發(fā)等等均可。
作者: Hephaestus    時間: 2022-12-15 16:44
我,菜雞 發(fā)表于 2022-12-15 08:46
對,雖然具體芯片不是STM的,但是用的是STM32的庫。CMSIS自帶的RTX5,我去搜一下。感謝

我似乎發(fā)過一個完整的Cortex-M0 RTX5工程,你用“53歲”做關(guān)鍵字搜一下舊帖子。
作者: xianfajushi    時間: 2022-12-15 17:28
對于中高級開發(fā)來說時間安排就必須考慮,論壇有的是因?yàn)闀r間安排不好提問的,因此,在帖子里面提及了對時間安排的一點(diǎn)思路.
作者: Hephaestus    時間: 2022-12-15 19:14
用過TCP協(xié)議棧、FATFS、GUI等等復(fù)雜中間件就知道好處了,這里面到處都是delay,如果用傻等那種delay,系統(tǒng)早就卡死了。用RTOS時間片,OSTimeDly的概念是把CPU控制權(quán)交給OS,如果有任務(wù)就緒,就讓那個任務(wù)去執(zhí)行,效率高太多了。如果不用RTOS,自己寫任務(wù)調(diào)度理論上可行,實(shí)際上太復(fù)雜了,個人很難做到?jīng)]有bug。
作者: 我,菜雞    時間: 2022-12-15 22:33
coody_sz 發(fā)表于 2022-12-15 12:23
其實(shí)就是不用軟件延時,不要空耗時間,實(shí)現(xiàn)方式各種各樣,RTOS、時間片、時間觸發(fā)等等均可。

也就是說,可以生成一個類似中斷,來打破一些死循環(huán)。從而讓單片機(jī)不會一直進(jìn)入無意義死循環(huán)。
作者: 我,菜雞    時間: 2022-12-15 22:34
Hephaestus 發(fā)表于 2022-12-15 16:44
我似乎發(fā)過一個完整的Cortex-M0 RTX5工程,你用“53歲”做關(guān)鍵字搜一下舊帖子。

厲害,53歲仍繼續(xù)奔跑啊。
作者: 我,菜雞    時間: 2022-12-15 22:37
xianfajushi 發(fā)表于 2022-12-15 17:28
對于中高級開發(fā)來說時間安排就必須考慮,論壇有的是因?yàn)闀r間安排不好提問的,因此,在帖子里面提及了對時間安 ...

類比于公司,上了一定規(guī)模,就要考慮制度,提高效率?
作者: 我,菜雞    時間: 2022-12-16 08:49
Hephaestus 發(fā)表于 2022-12-15 19:14
用過TCP協(xié)議棧、FATFS、GUI等等復(fù)雜中間件就知道好處了,這里面到處都是delay,如果用傻等那種delay,系統(tǒng) ...

雖然那種中間件我沒怎么用過,但是你說的道理我大概明白了。感謝
作者: xianfajushi    時間: 2022-12-16 08:50
我,菜雞 發(fā)表于 2022-12-15 22:37
類比于公司,上了一定規(guī)模,就要考慮制度,提高效率?

打個比方,任務(wù)分配多人,那么,是要等待某個完成后再問下一個,還是只問所有任務(wù)是否完成,然后就去做自己的事,哪個更好?所謂的多任務(wù)無非如此而已.
作者: 我,菜雞    時間: 2022-12-17 11:26
xianfajushi 發(fā)表于 2022-12-16 08:50
打個比方,任務(wù)分配多人,那么,是要等待某個完成后再問下一個,還是只問所有任務(wù)是否完成,然后就去做自己的 ...

原來如此
作者: Longan.Wang    時間: 2022-12-19 14:43
大家都講的好!
作者: 123789】】    時間: 2022-12-20 13:34
xianfajushi 發(fā)表于 2022-12-16 08:50
打個比方,任務(wù)分配多人,那么,是要等待某個完成后再問下一個,還是只問所有任務(wù)是否完成,然后就去做自己的 ...

明白了
作者: laohu_zz    時間: 2022-12-28 16:59
Y_G_G 發(fā)表于 2022-12-15 00:46
對于簡單而且是單一的程序而言,所謂'效率'有時候并不重要
比如我就一個LED手電,按鍵就是開關(guān)的作用而已,這 ...

學(xué)習(xí)啦,學(xué)習(xí)啦
作者: laohu_zz    時間: 2022-12-28 17:03
單片機(jī)多任務(wù)處理,了解下
作者: 船長丶    時間: 2022-12-29 18:18
就算用不到操作系統(tǒng)也該去了解一下時間片輪詢這個東西  并不是只有操作系統(tǒng)才能用到 這只是一個方法而已




歡迎光臨 (http://m.raoushi.com/bbs/) Powered by Discuz! X3.1