找回密碼
 立即注冊

QQ登錄

只需一步,快速開始

帖子
查看: 2924|回復(fù): 28
打印 上一主題 下一主題
收起左側(cè)

一個關(guān)于單片機(jī)串口通信協(xié)議的問題

[復(fù)制鏈接]
跳轉(zhuǎn)到指定樓層
樓主
ID:404263 發(fā)表于 2022-4-25 16:37 | 只看該作者 回帖獎勵 |倒序瀏覽 |閱讀模式
如果說單片機(jī)串口的通信協(xié)議是以字符串的形式來通信的話,大佬們有沒有好的處理方式,比如這個協(xié)議的字符長短是不固定的,模塊會給我單片機(jī)下發(fā)GETxxxxxxx,SETXXXXXX,RESETxxxxxx,之類的一堆字符串,我之前的做法是識別開頭的字符,結(jié)束就判斷\r\n,但是感覺不同指令用不同的頭碼識別,這個好像不太高效,隨著協(xié)議的增加,程序會變得十分臃腫,希望有大佬能指導(dǎo)一下這種字符串協(xié)議的該怎么寫好
分享到:  QQ好友和群QQ好友和群 QQ空間QQ空間 騰訊微博騰訊微博 騰訊朋友騰訊朋友
收藏收藏 分享淘帖 頂 踩
回復(fù)

使用道具 舉報

沙發(fā)
ID:390416 發(fā)表于 2022-4-25 18:24 | 只看該作者
參考MODBUS 協(xié)議,以時間間隔作為一串?dāng)?shù)據(jù)的結(jié)束和下一次數(shù)據(jù)的開始
回復(fù)

使用道具 舉報

板凳
ID:624769 發(fā)表于 2022-4-25 19:10 來自觸屏版 | 只看該作者
沒必要糾結(jié)這個效率,當(dāng)你定義指令以字符串方式來收發(fā)時,表示你已經(jīng)不在意這個效率了,能識別即可,
回復(fù)

使用道具 舉報

地板
ID:401564 發(fā)表于 2022-4-25 20:25 | 只看該作者
上位機(jī)和下位機(jī)之間串口通訊基本都是這種樣子的呀,有的還是固定長度的呢,長度不夠的話,還得加上0x00或者0xff補(bǔ)齊再發(fā)送,有的后面還會跟上一堆結(jié)束符,比如說3個0xff或者是3個0x00之類的
就連數(shù)據(jù),有的上位機(jī)都是要求發(fā)送ASCII字符串的,比如255就不會發(fā)送0xff,而是分開發(fā)送"2" "5" "5"
效率和程序代碼大小并不是任何時候都要做到極致的
比如STC8A,它有64K程序空間,那省下來的幾百個字節(jié)的內(nèi)存,一點意義都沒有
STM有的代碼空間有512K,那就更不用說了
只有你的程序有實際運行,的確是因為效率或者代碼真的太大了,才會開始考慮優(yōu)化算法
回復(fù)

使用道具 舉報

5#
ID:320097 發(fā)表于 2022-4-25 21:58 | 只看該作者
我覺得只要不產(chǎn)生BUG,程序能正常運行,硬件資源也夠的話,不用考慮那么多
回復(fù)

使用道具 舉報

6#
ID:47286 發(fā)表于 2022-4-26 00:20 | 只看該作者
你自己編個協(xié)議不就行了 所謂協(xié)議就是呼叫和應(yīng)答雙方能明白的約定 和硬件鏈路無關(guān)  你認(rèn)為分別用不同前綴導(dǎo)致效率下降 你完全可以自己定義 1=GET 2=SET 3=RESET 然后結(jié)果就是1xxxxxxx 2XXXXXX 3xxxxxx 只要接收方能解釋 你寫100個字符和寫1個沒區(qū)別 這就是約定 和英語用縮寫是一個意思
回復(fù)

使用道具 舉報

7#
ID:47286 發(fā)表于 2022-4-26 00:29 | 只看該作者
188610329 發(fā)表于 2022-4-25 19:10
沒必要糾結(jié)這個效率,當(dāng)你定義指令以字符串方式來收發(fā)時,表示你已經(jīng)不在意這個效率了,能識別即可,

純瞎聊天

雖然大家都認(rèn)為這個效率是無需考慮的 但我個人還是偏執(zhí)的認(rèn)為能節(jié)省一點還是好一點

假設(shè)57600bps的速率 我理解就是1秒內(nèi)有57600個1 假設(shè)8個1產(chǎn)生一次接收中斷 那就是每隔大約0.14ms會中斷一次 如果用查詢法ADC轉(zhuǎn)換 還是次低速 大約就是這么久得到結(jié)果 但因為時序起點不對位 等待ADC結(jié)果的時候有可能被打斷 如果用中斷法 串口中斷高于ADC中斷 也會打斷 速率越高打斷的次數(shù)就越多

我這算法不一定對 而且打斷是必然 只是偏執(zhí)吧 總希望盡量少 感覺 可能 也許 會好一點 只是感覺 實際使用里好象也沒什么影響 哈哈
回復(fù)

使用道具 舉報

8#
ID:1013784 發(fā)表于 2022-4-26 03:56 | 只看該作者
串口的協(xié)議頭都是固定的,可以寫個數(shù)組來保存這些數(shù)據(jù),然后判斷解析
回復(fù)

使用道具 舉報

9#
ID:404263 發(fā)表于 2022-4-26 08:06 | 只看該作者
dzbj 發(fā)表于 2022-4-26 00:20
你自己編個協(xié)議不就行了 所謂協(xié)議就是呼叫和應(yīng)答雙方能明白的約定 和硬件鏈路無關(guān)  你認(rèn)為分別用不同前綴導(dǎo) ...

主要是很多模塊協(xié)議是固定的,如果是我自己把兩個程序都寫了肯定是怎么簡單怎么來,但是實際項目中如果需要用別人的模塊,協(xié)議只能按著他們的來
回復(fù)

使用道具 舉報

10#
ID:401564 發(fā)表于 2022-4-26 10:22 | 只看該作者
dzbj 發(fā)表于 2022-4-26 00:29
純瞎聊天

雖然大家都認(rèn)為這個效率是無需考慮的 但我個人還是偏執(zhí)的認(rèn)為能節(jié)省一點還是好一點

串口通訊本身就不是追求非常的速度和一直在接收的狀態(tài),除非是大容量的存儲
更多的時候就是接收一數(shù)據(jù)而已,你要是一直以57600的速率,一直在接收,什么算法在這都沒用,程序都卡
因為你一直在進(jìn)入中斷,主程序根本就沒有多少時間去干活
所以,你會看到9600這個設(shè)置是最常用的
回復(fù)

使用道具 舉報

11#
ID:47286 發(fā)表于 2022-4-26 10:29 | 只看該作者
Y_G_G 發(fā)表于 2022-4-26 10:22
串口通訊本身就不是追求非常的速度和一直在接收的狀態(tài),除非是大容量的存儲
更多的時候就是接收一數(shù)據(jù)而 ...

明白 你說的是 所以會有網(wǎng)關(guān)這種東西 專心處理通訊問題的模塊
回復(fù)

使用道具 舉報

12#
ID:213173 發(fā)表于 2022-4-26 10:43 | 只看該作者
cokesu 發(fā)表于 2022-4-26 08:06
主要是很多模塊協(xié)議是固定的,如果是我自己把兩個程序都寫了肯定是怎么簡單怎么來,但是實際項目中如果需 ...

如果所采用的模塊其通信協(xié)議是供方固定的,那只能按模塊供方的通信協(xié)議編程。如果采用多種不同模塊(不可能太多),是會給編程帶來麻煩,也沒有一招天下通吃的處理方法。只能根據(jù)具體應(yīng)用來規(guī)劃適合的方式。串口函數(shù)本身只要能準(zhǔn)確收發(fā)字節(jié)數(shù)據(jù)即可,幀字節(jié)長度不同也不是問題。至于數(shù)據(jù)的含義則是由解析函數(shù)來完成�?傊魏魏弦�(guī)的通信協(xié)議都有其特征,以此辨識解析也不是什么難事。
回復(fù)

使用道具 舉報

13#
ID:624769 發(fā)表于 2022-4-26 11:57 | 只看該作者
dzbj 發(fā)表于 2022-4-26 00:29
純瞎聊天

雖然大家都認(rèn)為這個效率是無需考慮的 但我個人還是偏執(zhí)的認(rèn)為能節(jié)省一點還是好一點

既然,你開了頭,我現(xiàn)在又閑的快啥啥啥的, 就陪你瞎聊天一下.

雖然,我也喜歡追求效率,但是不太喜歡做無用功,何為無用功呢? 對于字符串的解析來講,你無論如何優(yōu)化解析方案,效率能提高 1/10 就燒高香了。但是,你如果把傳輸?shù)?ASCII 變成 HEX 其他什么都不干,效率至少提高 1/2,基于這一點,對于已經(jīng)選擇了 字符串方式傳輸?shù)倪@個原則,個人覺得,再考慮優(yōu)化已經(jīng)沒什么大的意義了,這就類似,我會去團(tuán)購小作坊生產(chǎn)的雨刮片,而不會去砍價4S店的雨刮器一樣。要么不弄,要么弄到極致。
回復(fù)

使用道具 舉報

14#
ID:624769 發(fā)表于 2022-4-26 12:24 | 只看該作者
Y_G_G 發(fā)表于 2022-4-26 10:22
串口通訊本身就不是追求非常的速度和一直在接收的狀態(tài),除非是大容量的存儲
更多的時候就是接收一數(shù)據(jù)而 ...

沒別的意思,實在太無聊了,上�,F(xiàn)在這情況,你應(yīng)該也能理解,就當(dāng)我找你嘮嗑吧。

前段時間折騰光立方(很沒技術(shù)含量,但能逗娃的東西),為了折騰"極致"以 STC15W104 為核心,HC595為驅(qū)動,看看可以做到什么程度,STC15W104 是沒有串口的, 就用軟件模擬串口,這個效率對比硬件串口來講,大約是硬件串口的 1/10 的效率吧,畢竟每個位都要中斷。光立方(3D8)的上位機(jī)軟件,傳輸速率是 57600/115200 二選一,   由于我的光立方,陣列標(biāo)準(zhǔn)和這個上位機(jī)軟件的陣列標(biāo)準(zhǔn)不符,收到上位機(jī)的數(shù)據(jù)后需要重排, 上位機(jī)的功能還挺多,除了LED陣列的控制,還有亮度,模式的控制,所以,接受到串口數(shù)據(jù)后,判斷處理工作也算比較多。一下子感覺,對于沒有硬件串口的STC15W104來說,還挺有挑戰(zhàn)的。一頓的摩拳擦掌,做好準(zhǔn)備,單片機(jī)處理速度跟不上,需要反復(fù)優(yōu)化,打算和效率大戰(zhàn)300回合。結(jié)果三下五除二,隨便寫一個重排代碼,合并到模擬串口里面邊收邊重排,57600波特率毫無壓力,再嘗試115200依然毫無壓力……。然后降低晶振速度到22118400,依然毫無壓力。然后……,又沒事干了……

我只想說,模擬串口115200都能游刃有余,在不停的接收數(shù)據(jù)的同時,處理各種其他工作。硬件串口57600的話,真沒啥可以讓系統(tǒng)干不了活得情況,我覺得,按現(xiàn)在單片機(jī)效率,57600應(yīng)該屬于比較標(biāo)準(zhǔn)的速率了,沒必要再去9600了。
回復(fù)

使用道具 舉報

15#
ID:401564 發(fā)表于 2022-4-26 13:40 | 只看該作者
188610329 發(fā)表于 2022-4-26 12:24
沒別的意思,實在太無聊了,上�,F(xiàn)在這情況,你應(yīng)該也能理解,就當(dāng)我找你嘮嗑吧。

前段時間折騰光立方 ...

串口通訊本身就不是說一定要很高速率的,除了大容量傳輸以外
所以,很多模塊,上位機(jī)什么的,大多都是默認(rèn)9600的,當(dāng)然,更高的速率也可以,只是沒必要而已
至于你說的把數(shù)據(jù)變成HEX格式收發(fā),如果是自己DIY點小玩意還可以
如果是有協(xié)議的模塊,那是肯定不行,像GPS模塊,人家協(xié)議就是發(fā)送字符串,那你程序就得這樣接收
回復(fù)

使用道具 舉報

16#
ID:123289 發(fā)表于 2022-4-26 15:02 | 只看該作者
你對通訊協(xié)議的目的還未理解。
想想為什么要用協(xié)議呢?
回復(fù)

使用道具 舉報

17#
ID:47286 發(fā)表于 2022-4-26 15:43 | 只看該作者
188610329 發(fā)表于 2022-4-26 11:57
既然,你開了頭,我現(xiàn)在又閑的快啥啥啥的, 就陪你瞎聊天一下.

雖然,我也喜歡追求效率,但是不太喜歡做 ...

明白 是你說的那樣 單一字符效率再怎么提也就那樣 整體提高作用會更大 是這意思吧

還是閑聊

雨刮片那東西 一直感覺最好的還是進(jìn)口SWF 國產(chǎn)的各種品牌包括SWF(也許是假貨)壽命都不好 你們那邊暖和可能感覺不大 我這邊冬天會刮冰雪 這種情況下國產(chǎn)的倒是耐搞 比進(jìn)口的不愛壞 可老蹦啊 刮起來呼啦呼啦的 我聽說咱的刮片也出口啊 咋就買不到又便宜又好的呢 進(jìn)口刮片比國產(chǎn)刮片好的性能不值貴出了那價格

有一陣子大眾4s可以單獨買刮片自己換 那個用著還行
回復(fù)

使用道具 舉報

18#
ID:47286 發(fā)表于 2022-4-26 15:48 | 只看該作者
188610329 發(fā)表于 2022-4-26 12:24
沒別的意思,實在太無聊了,上海現(xiàn)在這情況,你應(yīng)該也能理解,就當(dāng)我找你嘮嗑吧。

前段時間折騰光立方 ...

“然后降低晶振速度到22118400”

你。。。。。。你。。。。。。。沒降速的時候開的多大啊 那東西總共也沒多高

我是在11.0592下搞搞優(yōu)化啥的 開到22.1148 嗯。。。。。呃。。。。。。我那些優(yōu)化都是無用功

我這是個病 早年落下的病 Intel就是不換核一點一點累主頻 然后自己超頻玩 然后我就習(xí)慣在低頻折騰了
回復(fù)

使用道具 舉報

19#
ID:47286 發(fā)表于 2022-4-26 15:58 | 只看該作者
Y_G_G 發(fā)表于 2022-4-26 13:40
串口通訊本身就不是說一定要很高速率的,除了大容量傳輸以外
所以,很多模塊,上位機(jī)什么的,大多都是默認(rèn)96 ...

有時鐘模塊 為所有其它模塊提供時鐘服務(wù) 從系統(tǒng)角度講 時鐘模塊不斷電而其它所有模塊都可以斷電 那么 在所有模塊都上電的時候 都先發(fā)送申請時間指令 這就相當(dāng)于短時間內(nèi)集中發(fā)包 如果速率高 每個模塊占用信道時間短 會比速率低好很多的 57600發(fā)25位的時間比9600發(fā)25位短太多了

當(dāng)然 這也不是必須 可以每個模塊設(shè)置嘗試次數(shù) 我只是想表達(dá)一下意思 總覺得通訊可靠性不降低的情況下 速率高些還是有益處吧
回復(fù)

使用道具 舉報

20#
ID:47286 發(fā)表于 2022-4-26 16:04 | 只看該作者
cokesu 發(fā)表于 2022-4-26 08:06
主要是很多模塊協(xié)議是固定的,如果是我自己把兩個程序都寫了肯定是怎么簡單怎么來,但是實際項目中如果需 ...

如果這樣 基本就是沒啥優(yōu)化空間了 人家就那么發(fā) 你不那么收就沒法解析

可以每個模塊再配一個自己的小模塊 目的就是轉(zhuǎn)換通訊 把人家的協(xié)議轉(zhuǎn)換成你自定義的 這么做從硬件上基本就是個浪費 但如果模塊多 種類多 范圍較大 對管理來說就有好處 可以統(tǒng)一通訊協(xié)議 便于后期開發(fā)乃至上位機(jī)開發(fā) 通常在技術(shù)論壇討論的都是技術(shù)成本 但假設(shè)是個項目 實際上要考慮人工成本 管理成本 還有運維成本 硬件系統(tǒng)貴一點其它費用可能下來好多也不一定
回復(fù)

使用道具 舉報

21#
ID:624769 發(fā)表于 2022-4-26 16:47 | 只看該作者
dzbj 發(fā)表于 2022-4-26 15:48
“然后降低晶振速度到22118400”

你。。。。。。你。。。。。。。沒降速的時候開的多大啊 那東西總共 ...

額…… 51系列單片機(jī),只要時鐘頻率支持35MHz以上的,如STC89, STC12, STC15等等, 當(dāng)有且只有一個硬件串口的,在有外接電源的情況下,我一般頻率定義在 29.4912MHz, 主要原因有兩個,一個是沒必要用低頻率節(jié)省那所謂的功耗,二是,這個速率用串口模式二的話,可以省下一個定時器,直接用系統(tǒng)時鐘64分頻作波特率發(fā)生器,產(chǎn)生比較常用的460800波特率,當(dāng)然如果,電池供電,或者需要對接的設(shè)備,串口速率不支持那么高的話,我會用  7.3728MHz的頻率,產(chǎn)生115200的波特率。
對于多串口,或者沒有串口必須軟件模擬的,即必須定時器來產(chǎn)生波特率的,如果外接電源,我大多會用 33.1776MHz, 電池供電的話,多用5.5296MHz,是不是做事很極端?
效率的極端優(yōu)化,我大多是在折騰(或者說在試驗?zāi)硞€功能,或者說通過這個過程,更深度的理解某個工作原理),實際做出東西,如果不是在決定的頻率下,無法及時處理得話,相對于效率的優(yōu)化,我更傾向于壓縮代碼的大小,減小內(nèi)存的使用,這方面的優(yōu)化,說到底,是為了讓低端的單片機(jī)運行原本高端單片機(jī)才能運行的功能。比如,用STC15W102(128字節(jié)內(nèi)存 + 2K的flash) + HC595 x 4 驅(qū)動16x16點陣屏 搞個 蛇身長度 最長可以達(dá)到250個點陣的貪吃蛇游戲出來。查了各種站點,各種信息,大多數(shù)人第一步,內(nèi)存這關(guān)就過不了,目前為止,貌似只有我一個人搞出來了……

哎呀,扯遠(yuǎn)了,總之……, 既然串口傳輸?shù)膬?nèi)容是 字符串, 說明,對效率其實沒有要求,而波特率就算是57600,或者115200, 也不會說處理速度跟不上傳輸速度, 如果說問題出現(xiàn)在接受完整的指令再處理指令,會占用太多的內(nèi)存影響整個系統(tǒng)的運行,那么,需要改變的是,一邊接收,一邊處理指令。而不是說琢磨如何優(yōu)化對指令的判斷的效率優(yōu)化,只要對指令的判斷,不要垃圾的太離譜(比如在串口中斷里 while 之類的),都不會影響串口接收,所以才說,沒必要考慮效率問題,并且對于字符串的判斷,如果樓主不會匯編,累死都無法提高太多效率。投入和收獲極端不等。
回復(fù)

使用道具 舉報

22#
ID:47286 發(fā)表于 2022-4-26 17:53 來自觸屏版 | 只看該作者
188610329 發(fā)表于 2022-4-26 11:57
既然,你開了頭,我現(xiàn)在又閑的快啥啥啥的, 就陪你瞎聊天一下.

雖然,我也喜歡追求效率,但是不太喜歡做 ...

出個題

把光立方用2812 然后不斷混色變 串口助手不斷發(fā)指令 串口不斷回復(fù)當(dāng)前三色值
回復(fù)

使用道具 舉報

23#
ID:47286 發(fā)表于 2022-4-26 18:50 來自觸屏版 | 只看該作者
188610329 發(fā)表于 2022-4-26 16:47
額…… 51系列單片機(jī),只要時鐘頻率支持35MHz以上的,如STC89, STC12, STC15等等, 當(dāng)有且只有一個硬件串 ...

你說一邊接受一邊處理 能舉例么 數(shù)據(jù)流都沒完怎么處理 不理解啊
回復(fù)

使用道具 舉報

24#
ID:401564 發(fā)表于 2022-4-26 19:15 | 只看該作者
dzbj 發(fā)表于 2022-4-26 15:58
有時鐘模塊 為所有其它模塊提供時鐘服務(wù) 從系統(tǒng)角度講 時鐘模塊不斷電而其它所有模塊都可以斷電 那么 在 ...

總覺得通訊可靠性不降低的情況下 速率高些還是有益處吧
就單個產(chǎn)品而言,自然是有好處的
但就開發(fā)而已,如果不是大容量傳輸?shù)脑?沒有多大必要
很多上位機(jī)或者模塊都是以字符的形式發(fā)送的,有的還是固定的"幀頭,數(shù)據(jù)部分,幀尾"一大堆的,這就說明這個時候在速度上是沒有特別高的要求的,可靠性反正更重要了
單片機(jī)的串口一般就是發(fā)送一些指令,小容量數(shù)據(jù)之類,在速度上要求不高
而且有很多的模塊,上位機(jī)都不是自己的,別人做出來都是默認(rèn)9600速率的
很多人感覺串口影響到主函數(shù)了,那是因為很多人在中斷中使用while等待發(fā)送完成了,或者是發(fā)送的時候是先發(fā)送數(shù)據(jù),然后就是while等待發(fā)送完成了,這就給人一種串口速率低影響到了主程序的錯覺了
回復(fù)

使用道具 舉報

25#
ID:624769 發(fā)表于 2022-4-26 19:53 | 只看該作者
dzbj 發(fā)表于 2022-4-26 18:50
你說一邊接受一邊處理 能舉例么 數(shù)據(jù)流都沒完怎么處理 不理解啊

要說詳細(xì)的話, A4紙能寫4頁。就簡單說一下大概的宗旨吧,

串口接受按57600波特率,大約200us能接受一個字節(jié),串口中斷 把數(shù)據(jù)從SBUF 里取出來,放入緩沖池,再給接收計數(shù),就能退出中斷也就幾u(yù)s,有大把的時間,回歸到主程序進(jìn)行別的操作,主程序里面判斷,接收了的長度。
下面打比方,接收滿5個(主程序里面判斷 if(Rev_Cnt >=5){執(zhí)行字頭判斷}) 來區(qū)分是 GET, WRITE, SET, 還是RESET,等等,  這個字符判斷,也許比較費時,需要耗費上百us,( 其實也就串口接受一個字節(jié)的時間) 先做掉,然后做一個記號, Order_Type = ??; 這個就可以作為后續(xù)指令解讀來用了,節(jié)約了后面處理的時間(算是優(yōu)化的一種吧)。有必要的話,還要整理一下緩沖池,把已經(jīng)分析完的字頭部分的內(nèi)存釋放。
繼續(xù)打比方,接受還在繼續(xù), 在主程序里面 if((Rev_Cnt>=15)&&(Order_Type= 0x01)){開始處理第二步驟工作}  當(dāng)然,這部分也可以用 switch 看你喜歡吧。
依次類推,緩慢推進(jìn),等到上位機(jī)發(fā)送的數(shù)據(jù)全部完成后,單片機(jī)這里,工作其實已經(jīng)處理的7788,就剩一個尾巴了,這個是不是也是一種變相的提高效率呢?
但是,這個提升吧,其實遠(yuǎn)不如波特率翻一個倍有效�?茨阆矚g與否了。
回復(fù)

使用道具 舉報

26#
ID:47286 發(fā)表于 2022-4-26 20:22 | 只看該作者
Y_G_G 發(fā)表于 2022-4-26 19:15
總覺得通訊可靠性不降低的情況下 速率高些還是有益處吧
就單個產(chǎn)品而言,自然是有好處的
但就開發(fā)而已, ...

感謝耐心回復(fù) 你的意思記下了 目前搞的東西還不多 以后做得多了也許就明白了
回復(fù)

使用道具 舉報

27#
ID:47286 發(fā)表于 2022-4-26 20:25 | 只看該作者
188610329 發(fā)表于 2022-4-26 19:53
要說詳細(xì)的話, A4紙能寫4頁。就簡單說一下大概的宗旨吧,

串口接受按57600波特率,大約200us能接受一 ...

收到

剛才回復(fù)完也想了一下可能性 大概也是類似你說的意思 把相同的內(nèi)容歸類處理 但這也中斷內(nèi)的時間開銷會增加很多吧

我自己那個協(xié)議就有類似的情況 多槽就遇到內(nèi)存占用大的問題 PC上可以用多少內(nèi)存申請多少 用完釋放 C51里只能按最大開內(nèi)存 即便不用也得占著 看過一些動態(tài)內(nèi)存的范例 感覺好麻煩
回復(fù)

使用道具 舉報

28#
ID:624769 發(fā)表于 2022-4-26 20:37 | 只看該作者
dzbj 發(fā)表于 2022-4-26 20:25
收到

剛才回復(fù)完也想了一下可能性 大概也是類似你說的意思 把相同的內(nèi)容歸類處理 但這也中斷內(nèi)的時間 ...

中斷內(nèi)的開銷 也就增加一個 Rev_Cnt++; 但是,同時可以節(jié)約掉一個 if(SBUF == 0x00) Rev_End = 1;  嚴(yán)格來講,節(jié)約了一個if判斷,中斷內(nèi)時間的開銷反而更少。
差別是,主程序的指令判斷, 從原來的 if(Rev_End==1)  分解成若干個 if(Rev_Cnt >= ??) 來分段處理。
回復(fù)

使用道具 舉報

29#
ID:47286 發(fā)表于 2022-4-26 21:09 | 只看該作者
188610329 發(fā)表于 2022-4-26 20:37
中斷內(nèi)的開銷 也就增加一個 Rev_Cnt++; 但是,同時可以節(jié)約掉一個 if(SBUF == 0x00) Rev_End = 1;  嚴(yán)格 ...

收到 回頭我按這思路試試 看能寫出個啥來

"用STC15W102(128字節(jié)內(nèi)存 + 2K的flash) + HC595 x 4 驅(qū)動16x16點陣屏 搞個 蛇身長度 最長可以達(dá)到250個點陣的貪吃蛇游戲出來。"

這種事?lián)Q我干 呵呵 只能堆料 現(xiàn)在隨便寫個啥8k都感覺緊張 呃。。。。。。。。
回復(fù)

使用道具 舉報

您需要登錄后才可以回帖 登錄 | 立即注冊

本版積分規(guī)則

小黑屋|51黑電子論壇 |51黑電子論壇6群 QQ 管理員QQ:125739409;技術(shù)交流QQ群281945664

Powered by 單片機(jī)教程網(wǎng)

快速回復(fù) 返回頂部 返回列表