推 WolfLord:也可以用Base64或Code128來編碼(internet mime) 08/15 23:07
推 gg1122:哪些封包都有包好 只是原始的資料進來哪邊不清楚 08/15 23:09
→ gg1122:51做了什麼 把判斷0x0D弄掉 資料整段大於某個長度 再去拆 08/15 23:10
→ gg1122:可是我看51哪邊就一直進不去拆封包的 程式段 覺得很怪 08/15 23:11
推 WolfLord:如果你的資料是ascii，你也可以判斷比32比127大直接忽略 08/15 23:14
→ WolfLord: 比32小 08/15 23:15
→ WolfLord:不存入緩衝 08/15 23:15
→ gg1122:我的資料0~0xFF都會出現 應該不可行 08/15 23:17
這樣很高的機率是程式問題，你的解封包怎樣做的？如果是用狀態
機去做，要檢查狀態機遷移的條件。整個解封包如果大雜燴的寫在
一起就比較難debug.如果是用指標函式去跑，可以"比較"容易透過
指標函式的遷移去檢查狀態機的狀態處發是否正確？
※ 編輯: MasterChang 來自: 118.232.21.114 (08/15 23:34)
推 gg1122:if(UART_Buffer[0]=head1 && UART_Buffer[1]==head2) 08/15 23:40
→ gg1122:這樣一層一層if掛下去 08/15 23:42
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)
推 gg1122:哪我筆誤 == 才對 其實主要是進不來這行 08/15 23:46
→ gg1122:奇怪 判斷RX LEN多長在進來 怎會不行 搞不懂51動作 08/15 23:49
→ gg1122:明天我改一個一個BYTE去處理 不過還是想不透必須補結尾字元 08/15 23:55
→ gg1122:整個資料才會收進來 ... 08/15 23:56
是不是PC端程式必須收到CR字元才開始發送？PC端程式確認一下...
※ 編輯: MasterChang 來自: 118.232.21.114 (08/15 23:58)
→ gg1122:上端丟的 我用VC寫GUI去丟到51的 所以資料格式都是我控制的 08/15 23:59
如果是呼叫win api，確認一下結構的設定，那部分我沒碰、不
熟，我都是用BCB + Victor元件。
※ 編輯: MasterChang 來自: 118.232.21.114 (08/16 00:03)
→ gg1122:明天再查不出來 我就改成一個一個BYTE去判斷了 08/16 00:00
→ gg1122:謝謝! 08/16 00:01
推 WolfLord:PC端如果你open stream piple的話，只有兩種狀況會真實 08/16 16:44
→ WolfLord:真實傳送：buffer full跟收到\r\n 08/16 16:45
→ WolfLord:解覺得方法有兩種:open raw 或把 file io buffer改成1 08/16 16:46
推 gg1122:用成FSM就好了! 08/18 11:49
推 timestoprun:GOOGLE一下FIFO的UART寫法!!應該可以解決唷!!! 10/22 21:12