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

ID:404263 · 發(fā)表于 2022-4-25 16:37

如果說單片機(jī)串口的通信協(xié)議是以字符串的形式來通信的話，大佬們有沒有好的處理方式，比如這個(gè)協(xié)議的字符長(zhǎng)短是不固定的，模塊會(huì)給我單片機(jī)下發(fā)GETxxxxxxx，SETXXXXXX，RESETxxxxxx，之類的一堆字符串，我之前的做法是識(shí)別開頭的字符，結(jié)束就判斷\r\n，但是感覺不同指令用不同的頭碼識(shí)別，這個(gè)好像不太高效，隨著協(xié)議的增加，程序會(huì)變得十分臃腫，希望有大佬能指導(dǎo)一下這種字符串協(xié)議的該怎么寫好

ID:390416 · 發(fā)表于 2022-4-25 18:24

參考MODBUS 協(xié)議，以時(shí)間間隔作為一串?dāng)?shù)據(jù)的結(jié)束和下一次數(shù)據(jù)的開始

ID:624769 · 發(fā)表于 2022-4-25 19:10

沒必要糾結(jié)這個(gè)效率，當(dāng)你定義指令以字符串方式來收發(fā)時(shí)，表示你已經(jīng)不在意這個(gè)效率了，能識(shí)別即可，

ID:401564 · 發(fā)表于 2022-4-25 20:25

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

ID:320097 · 發(fā)表于 2022-4-25 21:58

我覺得只要不產(chǎn)生BUG,程序能正常運(yùn)行,硬件資源也夠的話,不用考慮那么多

ID:47286 · 發(fā)表于 2022-4-26 00:20

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

ID:47286 · 發(fā)表于 2022-4-26 00:29

188610329 發(fā)表于 2022-4-25 19:10
沒必要糾結(jié)這個(gè)效率，當(dāng)你定義指令以字符串方式來收發(fā)時(shí)，表示你已經(jīng)不在意這個(gè)效率了，能識(shí)別即可，

純瞎聊天

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

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

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

ID:1013784 · 發(fā)表于 2022-4-26 03:56

串口的協(xié)議頭都是固定的，可以寫個(gè)數(shù)組來保存這些數(shù)據(jù)，然后判斷解析

ID:404263 · 發(fā)表于 2022-4-26 08:06

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

主要是很多模塊協(xié)議是固定的，如果是我自己把兩個(gè)程序都寫了肯定是怎么簡(jiǎn)單怎么來，但是實(shí)際項(xiàng)目中如果需要用別人的模塊，協(xié)議只能按著他們的來

ID:401564 · 發(fā)表于 2022-4-26 10:22

dzbj 發(fā)表于 2022-4-26 00:29
純瞎聊天

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

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

ID:47286 · 發(fā)表于 2022-4-26 10:29

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

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

ID:213173 · 發(fā)表于 2022-4-26 10:43

cokesu 發(fā)表于 2022-4-26 08:06
主要是很多模塊協(xié)議是固定的，如果是我自己把兩個(gè)程序都寫了肯定是怎么簡(jiǎn)單怎么來，但是實(shí)際項(xiàng)目中如果需 ...

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

ID:624769 · 發(fā)表于 2022-4-26 11:57

dzbj 發(fā)表于 2022-4-26 00:29
純瞎聊天

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

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

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

ID:624769 · 發(fā)表于 2022-4-26 12:24

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

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

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

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

ID:401564 · 發(fā)表于 2022-4-26 13:40

188610329 發(fā)表于 2022-4-26 12:24
沒別的意思，實(shí)在太無聊了，上海現(xiàn)在這情況，你應(yīng)該也能理解，就當(dāng)我找你嘮嗑吧。

前段時(shí)間折騰光立方 ...

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

ID:123289 · 發(fā)表于 2022-4-26 15:02

你對(duì)通訊協(xié)議的目的還未理解。
想想為什么要用協(xié)議呢？

ID:47286 · 發(fā)表于 2022-4-26 15:43

188610329 發(fā)表于 2022-4-26 11:57
既然,你開了頭,我現(xiàn)在又閑的快啥啥啥的, 就陪你瞎聊天一下.

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

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

還是閑聊

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

有一陣子大眾4s可以單獨(dú)買刮片自己換那個(gè)用著還行

ID:47286 · 發(fā)表于 2022-4-26 15:48

188610329 發(fā)表于 2022-4-26 12:24
沒別的意思，實(shí)在太無聊了，上海現(xiàn)在這情況，你應(yīng)該也能理解，就當(dāng)我找你嘮嗑吧。

前段時(shí)間折騰光立方 ...

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

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

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

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

ID:47286 · 發(fā)表于 2022-4-26 15:58

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

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

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

ID:47286 · 發(fā)表于 2022-4-26 16:04

cokesu 發(fā)表于 2022-4-26 08:06
主要是很多模塊協(xié)議是固定的，如果是我自己把兩個(gè)程序都寫了肯定是怎么簡(jiǎn)單怎么來，但是實(shí)際項(xiàng)目中如果需 ...

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

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

ID:624769 · 發(fā)表于 2022-4-26 16:47

dzbj 發(fā)表于 2022-4-26 15:48
“然后降低晶振速度到22118400”

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

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

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

ID:47286 · 發(fā)表于 2022-4-26 17:53

188610329 發(fā)表于 2022-4-26 11:57
既然,你開了頭,我現(xiàn)在又閑的快啥啥啥的, 就陪你瞎聊天一下.

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

出個(gè)題

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

ID:47286 · 發(fā)表于 2022-4-26 18:50

188610329 發(fā)表于 2022-4-26 16:47
額…… 51系列單片機(jī)，只要時(shí)鐘頻率支持35MHz以上的，如STC89, STC12, STC15等等, 當(dāng)有且只有一個(gè)硬件串 ...

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

ID:401564 · 發(fā)表于 2022-4-26 19:15

dzbj 發(fā)表于 2022-4-26 15:58
有時(shí)鐘模塊為所有其它模塊提供時(shí)鐘服務(wù) 從系統(tǒng)角度講時(shí)鐘模塊不斷電而其它所有模塊都可以斷電那么在 ...

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

ID:624769 · 發(fā)表于 2022-4-26 19:53

dzbj 發(fā)表于 2022-4-26 18:50
你說一邊接受一邊處理能舉例么數(shù)據(jù)流都沒完怎么處理不理解啊

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

串口接受按57600波特率，大約200us能接受一個(gè)字節(jié)，串口中斷把數(shù)據(jù)從SBUF 里取出來，放入緩沖池，再給接收計(jì)數(shù)，就能退出中斷也就幾u(yù)s，有大把的時(shí)間，回歸到主程序進(jìn)行別的操作，主程序里面判斷，接收了的長(zhǎng)度。
下面打比方，接收滿5個(gè)（主程序里面判斷 if(Rev_Cnt >=5){執(zhí)行字頭判斷}）來區(qū)分是 GET, WRITE, SET, 還是RESET,等等，這個(gè)字符判斷，也許比較費(fèi)時(shí)，需要耗費(fèi)上百us,（其實(shí)也就串口接受一個(gè)字節(jié)的時(shí)間）先做掉，然后做一個(gè)記號(hào)， Order_Type = ??; 這個(gè)就可以作為后續(xù)指令解讀來用了，節(jié)約了后面處理的時(shí)間（算是優(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ī)這里，工作其實(shí)已經(jīng)處理的7788，就剩一個(gè)尾巴了，這個(gè)是不是也是一種變相的提高效率呢？
但是，這個(gè)提升吧，其實(shí)遠(yuǎn)不如波特率翻一個(gè)倍有效�？茨阆矚g與否了。

ID:47286 · 發(fā)表于 2022-4-26 20:22

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

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

ID:47286 · 發(fā)表于 2022-4-26 20:25

188610329 發(fā)表于 2022-4-26 19:53
要說詳細(xì)的話, A4紙能寫4頁(yè)。就簡(jiǎn)單說一下大概的宗旨吧，

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

收到

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

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

ID:624769 · 發(fā)表于 2022-4-26 20:37

dzbj 發(fā)表于 2022-4-26 20:25
收到

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

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

ID:47286 · 發(fā)表于 2022-4-26 21:09

188610329 發(fā)表于 2022-4-26 20:37
中斷內(nèi)的開銷也就增加一個(gè) Rev_Cnt++；但是，同時(shí)可以節(jié)約掉一個(gè) if(SBUF == 0x00) Rev_End = 1; 嚴(yán)格 ...

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

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

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

帳號(hào)		自動(dòng)登錄	找回密碼
密碼			立即注冊(cè)