PTT數位生活區 / ASM (組合語言)

Re: [問題] UART RX Buffer設計

看板ASM (組合語言)作者 (我愛ASM)時間12年前 (2012/08/15 22:37), 編輯推噓8(8推 0噓 14→)
留言22則, 3人參與, 最新討論串2/2 (看更多)
※ 引述《gg1122 (99通未接來電)》之銘言： : 因為目前UART Receive的部份都必須判斷收到CR : 或某個End of char 才能辦法收到完整資料 : 程式目前寫成如下 Buffer一直收到 爆掉 就直接overflow 重新Reset index : 目前遇到一個問題 我的真實資料前面會遇到0x0D 也就是CR : 搞不太懂要怎處理 因為本來想說判斷 資料沒到多少長度就繼續收 : 大於門檻值長度就整條直接做處理 今天測試是不行 不太懂什麼原因? : 難道要End of Char 要變連續二個BYTE 某個值 做判斷才能閃這個問題? : 還請各位先進 能夠幫忙 給意見 謝謝 定義好你的資料封包，沒有說結尾一定要是CR(0x0D) 比如0xAA是封包開始，0xFE是封包結尾，問題是如果資料 有0xFE怎麼辦，可以用控制字元填充，比如0xFD，只要資 料是0xAA、0xFE、0xFD，前方就填充0xFD，接收data時如 果收到0xFD，表示下一個byte是資料，不是封包控制字元 。 <0xAA><data 1>...<data n><0xFE> 或是偷懶，封包加入長度資料訊息，封包結尾用checksum檢查 <0xAA><data length n><data 1><data 2>...<data n><checksum> -- 不要問我從哪來，我只是一個浪跡天涯的工程師.... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.232.21.114
推
08/15 23:07, , 1F
也可以用Base64或Code128來編碼(internet mime)
08/15 23:07, 1F
推
08/15 23:09, , 2F
哪些封包都有包好 只是原始的資料進來哪邊不清楚
08/15 23:09, 2F
→
08/15 23:10, , 3F
51做了什麼 把判斷0x0D弄掉 資料整段大於某個長度 再去拆
08/15 23:10, 3F
→
08/15 23:11, , 4F
可是我看51哪邊就一直進不去拆封包的 程式段 覺得很怪
08/15 23:11, 4F
推
08/15 23:14, , 5F
如果你的資料是ascii，你也可以判斷比32比127大直接忽略
08/15 23:14, 5F
→
08/15 23:15, , 6F
比32小
08/15 23:15, 6F
→
08/15 23:15, , 7F
不存入緩衝
08/15 23:15, 7F
→
08/15 23:17, , 8F
我的資料0~0xFF都會出現 應該不可行
08/15 23:17, 8F
這樣很高的機率是程式問題，你的解封包怎樣做的？如果是用狀態 機去做，要檢查狀態機遷移的條件。整個解封包如果大雜燴的寫在 一起就比較難debug.如果是用指標函式去跑，可以"比較"容易透過 指標函式的遷移去檢查狀態機的狀態處發是否正確？ ※ 編輯: MasterChang 來自: 118.232.21.114 (08/15 23:34)
推
08/15 23:40, , 9F
if(UART_Buffer[0]=head1 && UART_Buffer[1]==head2)
08/15 23:40, 9F
→
08/15 23:42, , 10F
這樣一層一層if掛下去
08/15 23:42, 10F
if(UART_Buffer[0]==head1 && UART_Buffer[1]==head2) 看得出來哪裡不一樣嗎？ 而且這邏輯有問題，應該先檢查第一個接收資料是否為head1。 若為真才做檢查head2的動作。若為否則回到檢查接收資料是否 為head1。 因為資料開頭的head1有可能在UART_Buffer[1]裡....XD 簡單的說類似這樣的處理 ch = SURF; switch(msgstate) { case 0: if(ch == head1){msgstate++;} else{msgstate = 0;} break; case 1: if(ch == head2){msgstate++;} else{msgstate = 0;} break; case 3: ... default: } ※ 編輯: MasterChang 來自: 118.232.21.114 (08/15 23:48)
推
08/15 23:46, , 11F
哪我筆誤 == 才對 其實主要是進不來這行
08/15 23:46, 11F
→
08/15 23:49, , 12F
奇怪 判斷RX LEN多長在進來 怎會不行 搞不懂51動作
08/15 23:49, 12F
→
08/15 23:55, , 13F
明天我改一個一個BYTE去處理 不過還是想不透必須補結尾字元
08/15 23:55, 13F
→
08/15 23:56, , 14F
整個資料才會收進來 ...
08/15 23:56, 14F
是不是PC端程式必須收到CR字元才開始發送？PC端程式確認一下... ※ 編輯: MasterChang 來自: 118.232.21.114 (08/15 23:58)
→
08/15 23:59, , 15F
上端丟的 我用VC寫GUI去丟到51的 所以資料格式都是我控制的
08/15 23:59, 15F
如果是呼叫win api，確認一下結構的設定，那部分我沒碰、不 熟，我都是用BCB + Victor元件。 ※ 編輯: MasterChang 來自: 118.232.21.114 (08/16 00:03)
→
08/16 00:00, , 16F
明天再查不出來 我就改成一個一個BYTE去判斷了
08/16 00:00, 16F
→
08/16 00:01, , 17F
謝謝!
08/16 00:01, 17F
推
08/16 16:44, , 18F
PC端如果你open stream piple的話，只有兩種狀況會真實
08/16 16:44, 18F
→
08/16 16:45, , 19F
真實傳送：buffer full跟收到\r\n
08/16 16:45, 19F
→
08/16 16:46, , 20F
解覺得方法有兩種:open raw 或把 file io buffer改成1
08/16 16:46, 20F
推
08/18 11:49, , 21F
用成FSM就好了!
08/18 11:49, 21F
推
10/22 21:12, , 22F
GOOGLE一下FIFO的UART寫法!!應該可以解決唷!!!
10/22 21:12, 22F
‣ 更多 MasterChang 的文章
文章代碼(AID): #1GAxGadN (ASM)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共2篇)
ASM 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 MasterChang 的文章
文章代碼(AID): #1GAxGadN (ASM)