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

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

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

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

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

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

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

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)化算法

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

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

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ū)別這就是約定和英語用縮寫是一個意思

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í)吧總希望盡量少感覺可能也許會好一點只是感覺實際使用里好象也沒什么影響哈哈

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

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

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é)議只能按著他們的來

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è)置是最常用的

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)這種東西專心處理通訊問題的模塊

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é)議都有其特征，以此辨識解析也不是什么難事。

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店的雨刮器一樣。要么不弄，要么弄到極致。

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了。

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ā)送字符串,那你程序就得這樣接收

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

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

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可以單獨買刮片自己換那個用著還行

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í)慣在低頻折騰了

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á)一下意思總覺得通訊可靠性不降低的情況下速率高些還是有益處吧

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)貴一點其它費用可能下來好多也不一定

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 之類的），都不會影響串口接收，所以才說，沒必要考慮效率問題，并且對于字符串的判斷，如果樓主不會匯編，累死都無法提高太多效率。投入和收獲極端不等。

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

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

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

出個題

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

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ù)流都沒完怎么處理不理解啊

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ā)送完成了,這就給人一種串口速率低影響到了主程序的錯覺了

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與否了。

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

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

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

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)存的范例感覺好麻煩

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 >= ??) 來分段處理。

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都感覺緊張呃。。。。。。。。

帳號		自動登錄	找回密碼
密碼			立即注冊