一個關于單片機串口通信協議的問題

ID:404263 · 發表于 2022-4-25 16:37

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

ID:390416 · 發表于 2022-4-25 18:24

參考MODBUS 協議，以時間間隔作為一串數據的結束和下一次數據的開始

ID:624769 · 發表于 2022-4-25 19:10

沒必要糾結這個效率，當你定義指令以字符串方式來收發時，表示你已經不在意這個效率了，能識別即可，

ID:401564 · 發表于 2022-4-25 20:25

上位機和下位機之間串口通訊基本都是這種樣子的呀,有的還是固定長度的呢,長度不夠的話,還得加上0x00或者0xff補齊再發送,有的后面還會跟上一堆結束符,比如說3個0xff或者是3個0x00之類的
就連數據,有的上位機都是要求發送ASCII字符串的,比如255就不會發送0xff,而是分開發送"2" "5" "5"
效率和程序代碼大小并不是任何時候都要做到極致的
比如STC8A,它有64K程序空間,那省下來的幾百個字節的內存,一點意義都沒有
STM有的代碼空間有512K,那就更不用說了
只有你的程序有實際運行,的確是因為效率或者代碼真的太大了,才會開始考慮優化算法

ID:320097 · 發表于 2022-4-25 21:58

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

ID:47286 · 發表于 2022-4-26 00:20

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

ID:47286 · 發表于 2022-4-26 00:29

188610329 發表于 2022-4-25 19:10
沒必要糾結這個效率，當你定義指令以字符串方式來收發時，表示你已經不在意這個效率了，能識別即可，

純瞎聊天

雖然大家都認為這個效率是無需考慮的但我個人還是偏執的認為能節省一點還是好一點

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

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

ID:1013784 · 發表于 2022-4-26 03:56

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

ID:404263 · 發表于 2022-4-26 08:06

dzbj 發表于 2022-4-26 00:20
你自己編個協議不就行了所謂協議就是呼叫和應答雙方能明白的約定和硬件鏈路無關你認為分別用不同前綴導 ...

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

ID:401564 · 發表于 2022-4-26 10:22

dzbj 發表于 2022-4-26 00:29
純瞎聊天

雖然大家都認為這個效率是無需考慮的但我個人還是偏執的認為能節省一點還是好一點

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

ID:47286 · 發表于 2022-4-26 10:29

Y_G_G 發表于 2022-4-26 10:22
串口通訊本身就不是追求非常的速度和一直在接收的狀態,除非是大容量的存儲
更多的時候就是接收一數據而 ...

明白你說的是所以會有網關這種東西專心處理通訊問題的模塊

ID:213173 · 發表于 2022-4-26 10:43

cokesu 發表于 2022-4-26 08:06
主要是很多模塊協議是固定的，如果是我自己把兩個程序都寫了肯定是怎么簡單怎么來，但是實際項目中如果需 ...

如果所采用的模塊其通信協議是供方固定的，那只能按模塊供方的通信協議編程。如果采用多種不同模塊(不可能太多)，是會給編程帶來麻煩，也沒有一招天下通吃的處理方法。只能根據具體應用來規劃適合的方式。串口函數本身只要能準確收發字節數據即可，幀字節長度不同也不是問題。至于數據的含義則是由解析函數來完成。總之任何合規的通信協議都有其特征，以此辨識解析也不是什么難事。

ID:624769 · 發表于 2022-4-26 11:57

dzbj 發表于 2022-4-26 00:29
純瞎聊天

雖然大家都認為這個效率是無需考慮的但我個人還是偏執的認為能節省一點還是好一點

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

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

ID:624769 · 發表于 2022-4-26 12:24

Y_G_G 發表于 2022-4-26 10:22
串口通訊本身就不是追求非常的速度和一直在接收的狀態,除非是大容量的存儲
更多的時候就是接收一數據而 ...

沒別的意思，實在太無聊了，上海現在這情況，你應該也能理解，就當我找你嘮嗑吧。

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

我只想說，模擬串口115200都能游刃有余，在不停的接收數據的同時，處理各種其他工作。硬件串口57600的話，真沒啥可以讓系統干不了活得情況，我覺得，按現在單片機效率，57600應該屬于比較標準的速率了，沒必要再去9600了。

ID:401564 · 發表于 2022-4-26 13:40

188610329 發表于 2022-4-26 12:24
沒別的意思，實在太無聊了，上海現在這情況，你應該也能理解，就當我找你嘮嗑吧。

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

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

ID:123289 · 發表于 2022-4-26 15:02

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

ID:47286 · 發表于 2022-4-26 15:43

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

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

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

還是閑聊

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

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

ID:47286 · 發表于 2022-4-26 15:48

188610329 發表于 2022-4-26 12:24
沒別的意思，實在太無聊了，上海現在這情況，你應該也能理解，就當我找你嘮嗑吧。

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

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

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

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

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

ID:47286 · 發表于 2022-4-26 15:58

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

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

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

ID:47286 · 發表于 2022-4-26 16:04

cokesu 發表于 2022-4-26 08:06
主要是很多模塊協議是固定的，如果是我自己把兩個程序都寫了肯定是怎么簡單怎么來，但是實際項目中如果需 ...

如果這樣基本就是沒啥優化空間了人家就那么發你不那么收就沒法解析

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

ID:624769 · 發表于 2022-4-26 16:47

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

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

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

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

ID:47286 · 發表于 2022-4-26 17:53

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

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

出個題

把光立方用2812 然后不斷混色變串口助手不斷發指令串口不斷回復當前三色值

ID:47286 · 發表于 2022-4-26 18:50

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

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

ID:401564 · 發表于 2022-4-26 19:15

dzbj 發表于 2022-4-26 15:58
有時鐘模塊為所有其它模塊提供時鐘服務從系統角度講時鐘模塊不斷電而其它所有模塊都可以斷電那么在 ...

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

ID:624769 · 發表于 2022-4-26 19:53

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

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

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

ID:47286 · 發表于 2022-4-26 20:22

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

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

ID:47286 · 發表于 2022-4-26 20:25

188610329 發表于 2022-4-26 19:53
要說詳細的話, A4紙能寫4頁。就簡單說一下大概的宗旨吧，

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

收到

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

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

ID:624769 · 發表于 2022-4-26 20:37

dzbj 發表于 2022-4-26 20:25
收到

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

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

ID:47286 · 發表于 2022-4-26 21:09

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

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

"用STC15W102（128字節內存 + 2K的flash） + HC595 x 4 驅動16x16點陣屏搞個蛇身長度最長可以達到250個點陣的貪吃蛇游戲出來。"

這種事換我干呵呵只能堆料現在隨便寫個啥8k都感覺緊張呃。。。。。。。。

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

久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

一個關于單片機串口通信協議的問題