我的小組定的協議幀格式，幀頭是0xFF0xFE，但是沒有看到有資料內包含與幀頭一樣的資料時如何轉譯的說明，所以我就有疑問，
我就問：
有串口通信的需求嗎？ 有的話，“協議頭” 在串口通信時是不是應該說明轉譯規則(資料中含有和協議頭一樣的資料），或者明確兩幀之間的發送時隙的要求。不然會不會出現粘包或多幀合并發送時沒法拆包？
對方回答：
我們實際上會在快取解包，分包與拆包，不會出現大量粘包現象的。
問題來了，我不太理解他說的：“在快取解包，分包與拆包” 是什么意思？ 是如何識別幀頭幀尾，分包拆包的？
uj5u.com熱心網友回復：
1、一般只有在TCP網路上通信時才會出現分包與折包，單片機串口通信時，只要兩幀報文之間發送的時間間隔大于一定值（例如：100毫秒），就不會出現分包和折包。什么是分包與拆包呢？
假設客戶端分別發送了兩個資料包D1和D2給服務端，由于服務端一次讀取到的位元組數是不確定的，故可能存在以下4種情況。
（1）服務端分兩次讀取到了兩個獨立的資料包，分別是D1和D2，沒有粘包和拆包；
（2）服務端一次接收到了兩個資料包，D1和D2粘合在一起，被稱為TCP粘包；
（3）服務端分兩次讀取到了兩個資料包，第一次讀取到了完整的D1包和D2包的部分內容，第二次讀取到了D2包的剩余內容，這被稱為TCP拆包；
（4）服務端分兩次讀取到了兩個資料包，第一次讀取到了D1包的部分內容D1_1，第二次讀取到了D1包的剩余內容D1_2和D2包的整包。
粘包和拆包原因
（1）要發送的資料小于TCP發送緩沖區的大小，TCP將多次寫入緩沖區的資料一次發送出去，將會發生粘包；
（2）接收資料端的應用層沒有及時讀取接識訓沖區中的資料，將發生粘包；
（3）要發送的資料大于TCP發送緩沖區剩余空間大小，將會發生拆包；
（4）待發送資料大于MSS（最大報文長度），TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。
uj5u.com熱心網友回復：
2、如何識別幀頭幀尾在單片機上有2種方式。
方式1：利用2幀資料報文間隔時間來確定一幀資料包。
著名的有MODBUS-RTU標準協議。
MODBUS-RTU協議規定，如果接收到某一個位元組以后，如果在其后連續3.5位元組時間內都沒有收到一個位元組，則認為之前收到的
報文，就是一條完整的報文。假定收到該報文長度為10，則接識訓沖區陣列[0]=幀頭，接識訓沖區陣列[9]=幀尾。
方式2：利用特殊字串1作為幀頭，特殊字串2作為幀尾。
而且特殊字串1不允許出現在報文中，只能作為幀頭
特殊字串2不允許出現在報文中，只能作為幀尾
著名的有GPS通信報文。
例如：GPS通信報文中的GPGGA報文，以$GPGGA作為幀頭，以回車+換行符（0x0D0x0A）作為幀尾。
其中：$GPGGA不可能出現在正常報文中，只能用于幀頭。
回車+換行符不可能出現在正常報文中，只能用于幀尾。
兄弟：你用0xFF0xFE作幀頭很危險呀！如果報文中有個資料就是0xFF0xFE，你該怎么辦呀！
uj5u.com熱心網友回復：
轉譯呀，所以我才對我的同事提出那樣的疑問，然后給我的回復是那樣的，所以我很疑惑：”我們實際上會在快取解包，分包與拆包，不會出現大量粘包現象的。 “ 指的是什么？ 怎么實作不轉譯而實作正確的分包拆包uj5u.com熱心網友回復：
我不太理解他說的：“在快取解包，分包與拆包” 是什么意思？uj5u.com熱心網友回復：
1、快取解包單片機上普通采用環形緩沖區來解決快取解包問題。
所謂快取解包就是建立一個大的環形緩沖區，環形緩沖區的長度至少是【最長報文】的n倍。環形緩沖區有獨立的寫指標和讀指標，因此就算出現粘包，也不會影響決議報文作業。
2、拆包
假設客戶端分別發送了兩個資料包D1和D2給服務端，由于服務端一次讀取到的位元組數是不確定的，故可能存在以下4種情況。
（1）服務端分兩次讀取到了兩個獨立的資料包，分別是D1和D2，【報文是完整的】，沒有粘包和拆包；
（2）服務端一次接收到了兩個資料包，D1和D2粘合在一起，被稱為TCP粘包；
（3）服務端分兩次讀取到了兩個資料包，第一次讀取到了完整的D1包和D2包的部分內容，第二次讀取到了D2包的剩余內容，這被稱為TCP拆包；
（4）服務端分兩次讀取到了兩個資料包，第一次讀取到了D1包的部分內容D1_1，第二次讀取到了D1包的剩余內容D1_2和D2包的整包
上述（2）、（3）、（4）種情況，就是拆包。上述（1）情況不需要拆包，因為D1和D2分別都是獨自完整的包。
3、分包
說白了，就是要確保每種型別的報文有唯一的幀頭和幀尾，在決議報文時才好順利識別出它是何種型別的報文。即在發送報文時，
人為的添加幀頭和幀尾用于區分報文。
一般有如下方法：
（1）、一個是采用分隔符的方式，即我們在封裝要傳輸的資料包的時候，采用固定的符號作為結尾符（資料中不能含結尾符），這樣我們接收到資料后，如果出現結尾標識，即人為的將粘包分開，如果一個包中沒有出現結尾符，認為出現了分包，則等待下個包中出現后 組合成一個完整的資料包，這種方式適合于文本傳輸的資料，如采用/r/n之類的分隔符；
（2）、 另一種是采用在資料包中添加長度的方式，即在資料包中的固定位置封裝資料包的長度資訊（或可計算資料包總長度的資訊），服務器接收到資料后，先是決議包長度，然后根據包長度截取資料包（此種方式常出現于自定義協議中），但是有個小問題就是如果客戶端第一個資料包資料長度封裝的有錯誤，那么很可能就會導致后面接收到的所有資料包都決議出錯（由于TCP建立連接后流式傳輸機制），只有客戶端關閉連接后重新打開才可以消除此問題，我在處理這個問題的時候對資料長度做了校驗，會適時的對接收到的有問題的包進行人為的丟棄處理（客戶端有自動重發機制，故而在應用層不會導致資料的不完整性）；
4、我們實際上會在快取解包，分包與拆包，不會出現大量粘包現象的
快取、分包與拆包和粘包沒有必然的聯系。
5、粘包
（1）、當連續發送資料時，由于tcp協議的nagle演算法，會將較小的內容拼接成大的內容，一次性發送到服務器端，因此造成粘包。
（2）、當發送內容較大時，由于服務器端的recv（buffer_size）方法中的buffer_size較小，不能一次性完全接收全部內容，因此在下一次請求到達時，接收的內容依然是上一次沒有完全接收完的內容，因此造成粘包現象。
6、怎么實作不轉譯而實作正確的分包拆包
添加幀頭和幀尾。網上有這方面的方法，總之，用0xFF0xFE作幀頭是不可取的，另外，你怎么區分每幀報文的長度還是個問題呀！
你只定義的幀頭，而沒有定義幀尾，當出現粘包時，你怎么把2條粘在一起的報文分離出來呀！
uj5u.com熱心網友回復：
參考 5 樓 ba_wang_mao 的回復:
太感謝你了，你回答得非常好，很認真！！！
有幾個問題：
1、“環形緩沖區有獨立的寫指標和讀指標，因此就算出現粘包，也不會影響決議報文作業。",有獨立的寫指標和讀指標 怎么可以避免粘包不影響決議？ 如果讀取及時還好，只要讀指標=寫指標，就可以完整讀出一個幀，要是寫入的快，那么寫指標和讀指標之間的差值就有可能大于一個幀的長度呀。 我這里不太明白。
2、”怎么實作不轉譯而實作正確的分包拆包：添加幀頭和幀尾。” 我的協議就是添加了幀頭的，然后幀頭后面跟著的是幀的長度。我這樣的操作和你 有幀尾有什么不同？ 你添加幀頭幀尾 一樣會遇上資料中可能包含和幀頭一樣的資料，不經過轉譯怎么分清哪個是幀頭？有寫困惑
以上是我不理解的地方，希望能得到你的回復，非常感謝您
uj5u.com熱心網友回復：
2、”怎么實作不轉譯而實作正確的分包拆包：添加幀頭和幀尾。” 我的協議就是添加了幀頭的，然后幀頭后面跟著的是幀的長度。我這樣的操作和你 有幀尾有什么不同？你添加幀頭后面跟著的是幀的長度也是一種正確的解決方法。
3、你添加幀頭幀尾 一樣會遇上資料中可能包含和幀頭一樣的資料，不經過轉譯怎么分清哪個是幀頭？有寫困惑
你添加幀頭后面跟著的是幀的長度后，就不需要幀尾啦！
4、環形緩沖區請在網上搜索
1、當讀指標=寫指標時，環形緩沖區為空
2、當讀指標+1=寫指標，環形緩沖區為滿。
環形緩沖區演算法參見http://www.360doc.com/content/17/0219/08/478627_630209821.shtml
https://blog.csdn.net/maowentao0416/article/details/81984269
https://blog.csdn.net/qq_39736982/article/details/82915115
uj5u.com熱心網友回復：
顧名思義，把一個向量想像成環形，讀指標追寫指標。當讀指標+1=寫指標時，環形緩沖區滿；當讀指標=寫指標時，環形緩沖區為空。uj5u.com熱心網友回復：
因此一個向量會犧牲一個位元組的空間，該犧牲了一個位元組的空間就是用于判斷環形緩沖區是否已滿。uj5u.com熱心網友回復：
1、“3、你添加幀頭幀尾 一樣會遇上資料中可能包含和幀頭一樣的資料，不經過轉譯怎么分清哪個是幀頭？有寫困惑
你添加幀頭后面跟著的是幀的長度后，就不需要幀尾啦！”
“幀頭+幀的長度”/“幀頭+幀尾”不經過轉譯怎么分清哪個是幀頭？ 你的意思是，從資料緩沖中讀取到“幀頭”然后再根據后面的長度讀取資料，然后根據校驗碼校驗，如果校驗失敗（說明當前幀是一個殘幀，幀資料中剛好有和幀頭一樣的資料），就丟掉這個幀頭繼續往后面找？
（會不會有這樣的情況，每一幀的資料里面都有和幀頭一樣的資料<比如某個設備的ID>,然后第一幀的幀頭丟失接收不全，這樣的話，會不會導致后面的所有幀都取的不正確校驗不通過，都丟棄？）
2、關于環形緩沖
我還是不明白，環形緩沖如解決快取解包問題。 需要幀帶有幀長度欄位吧，這樣的話 讀指標指向的下2個位元組是幀頭，再向前是 長度，然后按長度讀取出來就是一幀，再校驗通過就是有效幀。然后接下來重復這樣的操作取出 第二，第三幀…… 是這樣的嗎？
如果 每一幀資料中都有和 幀頭一樣的資料，然后前面有一幀 缺少了 幀頭，這樣的話會不會導致后面的幀全部取出來是錯誤的
uj5u.com熱心網友回復：
1、“幀頭+幀的長度”/“幀頭+幀尾”不經過轉譯怎么分清哪個是幀頭？ 你的意思是，從資料緩沖中讀取到“幀頭”然后再根據后面的長度讀取資料，然后根據校驗碼校驗，如果校驗失敗（說明當前幀是一個殘幀，幀資料中剛好有和幀頭一樣的資料），就丟掉這個幀頭繼續往后面找？是的。
“幀頭”+ “幀長度”+ XXXXXXXXXXX + 校驗碼
校驗失敗就丟棄，從校驗碼后面一個位元組開始重新查找。
2、會不會有這樣的情況，每一幀的資料里面都有和幀頭一樣的資料<比如某個設備的ID>,然后第一幀的幀頭丟失接收不全，這樣的話，會不會導致后面的所有幀都取的不正確校驗不通過，都丟棄？
這屬于分包的設計啦。
分包設計時增加的“幀頭”你一定要設計成不可能在報文中出現的字符呀！這樣不就解決了嗎？
例如：
幀頭設計為“$GPGGA"
幀長度為16位，占用2個位元組
幀報文內容為 0x11 0x12 0x13 0x14
校驗碼為 0X89 0X90
send_buffer[0] = '$' --------------------> 幀頭="GPGGA"
send_buffer[1] = 'G'
send_buffer[2] = 'P'
send_buffer[3] = 'G'
send_buffer[4] = 'G'
send_buffer[5] = 'A'
send_buffer[6] = 0
send_buffer[7] = 14;--------------------->幀長度=14
send_buffer[8] = 0x11;
send_buffer[9] = 0x12;
send_buffer[10] = 0x13;
send_buffer[11] = 0x14;
send_buffer[12] = 0x89;
send_buffer[13] = 0x90;
uj5u.com熱心網友回復：
1、“幀頭+幀的長度”/“幀頭+幀尾”不經過轉譯怎么分清哪個是幀頭？ 你的意思是，從資料緩沖中讀取到“幀頭”然后再根據后面的長度讀取資料，然后根據校驗碼校驗，如果校驗失敗（說明當前幀是一個殘幀，幀資料中剛好有和幀頭一樣的資料），就丟掉這個幀頭繼續往后面找？是的。
“幀頭”+ “幀長度”+ XXXXXXXXXXX + 校驗碼
校驗失敗就丟棄，從校驗碼后面一個位元組開始重新查找。
2、會不會有這樣的情況，每一幀的資料里面都有和幀頭一樣的資料<比如某個設備的ID>,然后第一幀的幀頭丟失接收不全，這樣的話，會不會導致后面的所有幀都取的不正確校驗不通過，都丟棄？
這屬于分包的設計啦。
分包設計時增加的“幀頭”你一定要設計成不可能在報文中出現的字符呀！這樣不就解決了嗎？
例如：
幀頭設計為“$GPGGA"
幀長度為16位，占用2個位元組
幀報文內容為 0x11 0x12 0x13 0x14
校驗碼為 0X89 0X90
send_buffer[0] = '$' --------------------> 幀頭="$GPGGA"
send_buffer[1] = 'G'
send_buffer[2] = 'P'
send_buffer[3] = 'G'
send_buffer[4] = 'G'
send_buffer[5] = 'A'
send_buffer[6] = 0 --------------------->幀長度
send_buffer[7] = 14;--------------------->幀長度=0014
send_buffer[8] = 0x11;
send_buffer[9] = 0x12;
send_buffer[10] = 0x13;
send_buffer[11] = 0x14;
send_buffer[12] = 0x89;
send_buffer[13] = 0x90;
uj5u.com熱心網友回復：
我一般采用如下方式處理1、串口中斷服務程式讀取位元組到環形緩沖區
2、主程式一個位元組一個位元組的從環形緩沖區讀到決議緩沖區
注：決議緩沖區為字符緩沖區，這樣方便使用字串查找功能，查找“幀頭”
3、決議緩沖區中找到一幀完整的報文并檢驗OK后，
再將決議緩沖區中的內容去掉幀頭和幀長度 ，然后轉換存放到uint8_t 的緩沖區中，供程式使用。
uj5u.com熱心網友回復：
太棒了，和你討論學到了很多，你寫的的回答真詳細呀，大贊！！！！！
1、”分包設計時增加的“幀頭”你一定要設計成不可能在報文中出現的字符呀！這樣不就解決了嗎？“
這個很難耶，因為我們的協議是 二進制資料的，你很難知道 幀資料中會出現什么樣的資料，比如你這個幀頭"$GPGGA"，如果對方要傳一張圖片，那么誰又能保證圖片中沒有包含"$GPGGA"這樣的資料呢？ 無解吧？
增加幀頭的位元組數可以大大降低這種可能性，所以我覺得你這個"$GPGGA" 提議還是很贊的，只是好像不能徹底解決問題，對嗎？
uj5u.com熱心網友回復：
你的同事說法是不對的，答非所問。你的問題需要分情況。如果你的幀是協議層的，如udp，則不需要轉譯，因為ip鏈路層已替你解決好幀的分割了。如何是裸協議或UART這種，又要分情況。如何CPU裸奔，沒有作業系統，只要有幀間時隙夠大，通過位元組接收時間判決，進行幀分隔，也不需要轉碼。還有協議上加幀長和校驗欄位，一開始的幀可能錯誤，遇到幀頭就丟棄前面的，幾幀過后就同步了。uj5u.com熱心網友回復：
非常感謝你的回答呀。
1、不過我同時也不是答非所問，他的意思確實是在快取中解包，用的是ba_wang_mao回答的那些方法（你可以回去看看我和ba_wang_mao的討論記錄）
2、“一開始的幀可能錯誤，遇到幀頭就丟棄前面的，幾幀過后就同步了。”這個我們前面也討論到了，是可以這樣的。但是這種方法有一種非常特殊的情況會造成 不管多少幀之后都無法同步，這種情況是這樣的：
協議是 二進制資料的，你很難知道 幀資料中會出現什么樣的資料，比如幀頭是"$GP"，如果對方每一幀都要傳一張小圖片，誰也無法保證圖片中沒有包含"$GP"這樣的資料呢，這樣的話如果首幀的幀頭丟失，就會出現不管丟多少幀都無法同步的現象。
當然增加幀頭的位元組數可以大大降低這種可能性，比如"$GPGGA" ，只是不能徹底解決這個問題，你有什么好的方法嗎
uj5u.com熱心網友回復：
參考pppoe吧。這個解決的很好了。uj5u.com熱心網友回復：
一種是類似pppoe，用位元組7e分割，中間資料里7d轉義，用7d5d代表7d，用7d5e代表7e。加不加校驗自己選擇。第二種，固定頭加長度加校驗，比如參考ip。
第三種，使用ASN.1資料規范，是3G里面廣泛使用的，可靈活啦。
uj5u.com熱心網友回復：
第一種：轉譯的方法我們知道的，需要發送和接收都需要轉譯，對性能影回應該不小，估計我同事就是因為這個放棄這個方法
第二種，固定頭加長度加校驗，比如參考ip。（這個方法，我就是還有一個疑惑不能解決：
這種方法就是 遇到幀頭就安裝后面的幀長度讀出幀資料然后校驗，校驗錯誤就丟棄，從后面的資料繼續找幀頭……丟幾幀后就會同步，不過有一種非常特殊的情況會造成 不管多少幀之后都無法同步，這種情況是這樣的：
協議是 二進制資料的，你很難知道 幀資料中會出現什么樣的資料，比如幀頭是"$GP"，如果對方每一幀都要傳一張小圖片，誰也無法保證圖片中沒有包含"$GP"這樣的資料呢，這樣的話如果首幀的幀頭丟失，就會出現不管丟多少幀都無法驗證通過無法同步的現象。
第三種，使用ASN.1資料規范，是3G里面廣泛使用的，可靈活啦----這個能大概說說和前兩種有什么不同嗎
uj5u.com熱心網友回復：
第二種，因為有二進制總計校驗，所以如果校驗不對，就不是貞頭，接著等待。二進制總計校驗很節約時間。第三個，適合封非常復雜的指令，可以用各種標志位，決定后面有哪些塊。比如是不是有電機資料，溫度資料。這個東西用語言描述結構，而后有工具asn4c asn4j直接把asn語言編譯成c或者java
uj5u.com熱心網友回復：
等待的時候，是每個位元組推過去。如果影像里有假頭，校驗不通過，還是逐個位元組后推。直到校驗通過了，才是直接取長度uj5u.com熱心網友回復：
仔細看了樓上，已經很清楚了，環形快取和頭校驗。只要沒有頻繁的記憶體動態分配，性能都差不多。pppoe，ip，asn，都是用于嵌入式的成熟協議，可以看看一些開源代碼里是怎么折騰的。uj5u.com熱心網友回復：
哇！原來是版主大人！！版主出馬 又讓我學了不少東西。請問什么是“二進制總計校驗”？
也就是說 二進制總計校驗不通過的時候，不丟棄假頭后面假“幀長度”的資料，而是從假頭繼續往后推進去找幀頭然后按后面的“幀長度”取資料校驗，通過了才把資料從環形快取里面取出來對嗎？
uj5u.com熱心網友回復：
我不是版主，不知為什么會顯示版主，額，真的很奇怪。我也管理不了別人的帖子。沒有人聯系過我，估計是bug
對的，就是如果不通過校驗，就要逐個位元組去挪動。校驗可以自己定演算法，比如把頭部位元組按照uint16算數想加，或者異或都可以。
uj5u.com熱心網友回復：
我還是不大明白你的意思，“比如把頭部位元組按照uint16算數想加，或者異或都可以”你說的”頭部位元組“是指幀頭嗎？校驗是指校驗出幀頭？ 我的疑問是如何 區分出真的幀頭 和 假的幀頭。
我的想法是這樣的，比如下面這個快取資料，第一幀的幀頭不完整，且幀資料內有和幀頭一樣的資料。 在檢出幀頭的操作中，檢到8，9，10 位元組時，懷疑是”幀頭“，然后再從該”幀頭“的后面一個位元組得到”長度“ send_buffer[12] = 0x89; ，然后再按照這個長度 獲取出0x89長度位元組的資料， 最后對獲取出來的 幀頭+長度+資料 進行CRC校驗，再與 幀資料里面帶的CRC對比，如果錯誤，說明 send_buffer[9] = '$';
send_buffer[10] = 'G';
send_buffer[11] = 'P';
不是幀頭。
繼續從send_buffer[11]往后挪 找下一個幀頭，而不是從send_buffer[11]+幀長度+0x89 之后的挪，也就是當前幀頭錯的話，就是從當前假幀頭之后的位元組繼續往前找幀頭。（這樣的話，就要再給環形緩沖加一個 指標專門找幀頭的指標，而是不用讀指標邊讀邊找幀頭）我的想法對嗎？ 你的想法是什么樣的？
快取資料：
//send_buffer[0] = '$' --------------------> 幀頭="$GP" --->去掉$ 制造一個不完成幀
send_buffer[1] = 'G'
send_buffer[2] = 'P'
send_buffer[6] = 0 --------------------->幀長度
send_buffer[7] = 14;--------------------->幀長度=0014
send_buffer[8] = 0x11;
send_buffer[9] = '$';
send_buffer[10] = 'G';
send_buffer[11] = 'P';
send_buffer[12] = 0x89;
send_buffer[13] = 0x90;
send_buffer[14] = '$' --------------------> 幀頭="$GP"
send_buffer[15] = 'G'
send_buffer[16] = 'P'
send_buffer[17] = 0 --------------------->幀長度
send_buffer[18] = 14;--------------------->幀長度=0014
send_buffer[19] = 0x11;
send_buffer[20] = 0x12;
send_buffer[21] = 0x13;
send_buffer[22] = 0x14;
send_buffer[23] = 0x89;
send_buffer[24] = 0x90;
uj5u.com熱心網友回復：
單片機上如果上位機每次只發送一幀獨立的報文（上位機如果不是將幾個報文打包一起發的話），完全沒有必須考慮粘包問題、分包問題，也就是說：（1）、如果上位機發送的2條報文之間的時間間隔大于10毫秒，就沒有必須考慮粘包問題，粘包只會出現在TCP網路環境中。
（2）、如果上位機發送的每條報文都是一條獨立的報文，則沒有必須使用環形緩沖區。
只需要在串口接收中斷中啟動一個3.5位元組接收時間的定時器即可，當定時器溢位，就表示一幀報文接收完畢。
假如定時器溢位時，接收總長度=20
接識訓沖區 【0】 = 報文第1個位元組
接識訓沖區 【19】 = 報文最后個位元組
打個比方：當上位機發送的報文分別是【報文1】、【報文2】、【報文3】時
上位機發送時，只會發送【報文1】
只會發送【報文2】
只會發送【報文3】
不會出現【報文1】+【報文2】
不會出現【報文1】+【報文3】
不會出現【報文2】+【報文3】
不會出現【報文1】+【報文2】+【報文3】
就沒有必要搞個環形緩沖區。
（3）、如果上位機發送的每條報文，有時候是一個單獨的報文，有時候是幾個報文疊加在一起發，則需要使用環形緩沖區識別出具體的每一個報文。
打個比方：當GPS設備發送報文時，不是每次只單獨分別發送GPGGA報文、GPTRA報文、GPRMC報文，
而是有時候發送 GPGGA報文+GPTRA報文
有時候發送GPGGA報文+GMRMC報文
有時候發送GPGGA報文+GPTRA報文+GPRMC報文
這個時候就要用到環形緩沖區決議報文。
總之，單片機中最簡單的判斷接收完一個報文的方法如下：
第一步：定義一個3.5位元組接收時間的定時器
第二步：串口接收中斷中只要收到一個位元組，就清空定時器的計數
第三步：當定時器溢位，就表示一幀報文接收完畢。
uj5u.com熱心網友回復：
// 定時器中斷
void TIM1_UP_IRQHandler(void)
{
if (TIM_GetITStatus(TIM1,TIM_IT_Update) != RESET)
{
TIM_ClearITPendingBit(TIM1,TIM_IT_Update);
TIM_Cmd(TIM1, DISABLE);
MB_USART1.Outtime_mark = TRUE; //定時器溢位表示接收完一幀完整的報文，置接收完成標識
}
}
//串口中斷方式
void USART1_IRQHandler(void)
{
uint8_t ch;
if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)
{
USART_ClearITPendingBit(USART1, USART_IT_RXNE);
ch = USART_ReceiveData(USART1);
if (MB_USART1.receCount < MSCOMM_BUFFER_LENGTH)
MB_USART1.mscomm_buffer[MB_USART1.receCount++] = ch;
else
MB_USART1.receCount = 0;
TIM_Cmd(TIM1, DISABLE);
TIM_SetCounter(TIM1, 0x00); // 清定時器的計數
TIM_Cmd(TIM1, ENABLE);
}
if (USART_GetITStatus(USART1, USART_IT_TC) != RESET)
{
USART_ClearFlag(USART1,USART_FLAG_TC);
if (MB_USART1.sendPosi < MB_USART1.sendCount)
USART_SendData(USART1, MB_USART1.send_buffer[MB_USART1.sendPosi++]);
else
{
USART1_RS485_RECIVE_enable();
USART_ITConfig(USART1, USART_IT_TC, DISABLE);
}
}
}
uj5u.com熱心網友回復：
感謝！非常好，回答得很詳細，認真~~uj5u.com熱心網友回復：
你這里說的單片機不考慮粘包，指的的串口通信吧？ 是不是TCP和單片機有什么關系呢？ 單片機也有支持TCP通信的呀。
我想你的意思應該是 串口通信，因為串口占用，所以只有一對一的通信，只要上位機每次只發一幀，所以不用考慮粘包問題。
而TCP 因為可以一對多，所以多個上位機來的資料可能都放到一個緩沖中，導致粘包
是這個意思嗎
uj5u.com熱心網友回復：
1、單片機的串口通信沒有必須考慮粘包問題、分包問題。2、如果你使用以太網轉串口芯片通過單片機上的串口和上位機通信，也沒有必須考慮粘包問題、分包問題。
3、如果你使用單片機上的以太網直接和上位機通信，必須考慮粘包問題、分包問題。
4、而TCP 因為可以一對多，所以多個上位機來的資料可能都放到一個緩沖中，導致粘包。
你上面的這句話理解有問題。
粘包和分包對于TCP來說是建立在一個TCP連接上的，而不是什么幾臺電腦這種概念。
（1）、如果1臺電腦和你的單片機通過以太網建立了1個連接，
那么電腦通過連接1發送給單片機的報文就需要考慮粘包問題。
（2）、如果1臺電腦和你的單片機通過以太網建立了2個連接
那么電腦通過連接1發送給單片機的報文就需要考慮粘包問題。
那么電腦通過連接2發送給單片機的報文就需要考慮粘包問題。
但是不會出現連接1的報文和連接2的報文混在一起這種情況滴！
可以把以太網中的【TCP連接】想像成RS232通信電纜一樣：
第一個TCP連接，就相當于通過一根電纜連接到單片機的USART1串口，
第二個TCP連接，就相當于通過另外一根電纜連接到單片機的USART2串口，
第三個TCP連接，就相當于通過另外一根電纜連接到單片機的USART3串口，
以此類推，所以TCP上的報文不可能出現不同的連接的報文混在一起滴。
uj5u.com熱心網友回復：
所謂粘包，是指某一個連接內傳輸報文時出現粘包，而不是指某1個連接和其它連接之間的報文粘在一起。uj5u.com熱心網友回復：
串口通信不需要考慮粘包，而TCP 需要考慮粘包，是因為“TCP有發送緩沖區，TCP將多次寫入緩沖區的資料一次發送出去，將會發生粘包；” 而串口通信是沒有發送緩沖區，呼叫發送介面就直接發出去？
uj5u.com熱心網友回復：
1、有的單片機的串口通信也有【硬體發送緩沖區】和【硬體接識訓沖區】，只是緩沖區非常少，最大也就16位元組（即最多可以快取16個位元組）。2、單片機不粘包的原因是：它是串行通信的，硬體收到一個新的位元組，就立即觸發接收中斷，程式員就可以在接收中斷中讀取，如果程式員不讀取它，過一會又來了一個位元組，就會把之前的位元組覆寫掉。
3、而TCP粘包的原因是TCP協議演算法的原因。
你要求程式發送一條報文，該報文長度很小，根據TCP協議，它認為這條報文還不到發送時間，它就把該報文暫存在系統中，當你又發送了一條報文，它認為達到發送條件了，它就把剛剛快取的報文和現在的報文發送出去，所以就出現了粘包。
單片機串口通信就沒有這樣的機制，它不管三七二十一，當你往【硬體發送暫存器】裝資料時，它就通過內部機制立即發送出去，不會像TCP通信那樣由TCP協議來決定這條報文是否立即發送出去。
uj5u.com熱心網友回復：
所以說單片機串口通信時，只需要前一幀報文和后一幀報文的間隔時間滿足以下條件即可：單片機有充足的時間完成前一幀報文的接收和決議作業就OK啦！uj5u.com熱心網友回復：
原來如此！你太厲害了，非常感謝！！ 回答得很認真詳細~~~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/51815.html
標籤：單片機/工控
上一篇：關于中斷（補充中）
下一篇：Python自學感想