標題: STC15單片機串口通信,時序太亂,怎么改程序? [打印本頁]
作者: gaima    時間: 2022-10-12 15:28
標題: STC15單片機串口通信,時序太亂,怎么改程序?


這是485的報文，黑色是主機發(fā)的，按01 01，01 04 ，01 03 ，01 02 逐條發(fā)，藍色是從機回答。



主機的框架




作者: yzwzfyz    時間: 2022-10-12 17:06
先構思一下，如何將數(shù)據整理成：你所認為的不亂，而后再按你整理的次序進行收發(fā)。
作者: Y_G_G    時間: 2022-10-12 17:59
感覺這就是Modbus,沒什么亂不亂的
按照協(xié)議寫就行
作者: xuyaqi    時間: 2022-10-12 18:18
把讀空調機狀態(tài)，讀空調傳感器命令格式及回答格式搞清楚，就不會覺得亂。
作者: gaima    時間: 2022-10-12 19:04
感謝各位大佬回復。我是按照0101，延時等待回復；0104，延時等待回復；0103，延時等待回復，0102，延時等待。收到回復判斷驗證下，再發(fā)去5A A5。現(xiàn)在第一條，0104的指令發(fā)出，后才收到0101的回答指令。順序亂了，影響我準確性。我加長延時也沒用。還有0104、0103、0102的指令還有幾率發(fā)不出被吞。
485單獨測試從機，幾乎不會漏發(fā)，響應時間也就30ms左右。
作者: Y_G_G    時間: 2022-10-12 19:30
gaima 發(fā)表于 2022-10-12 19:04
感謝各位大佬回復。我是按照0101，延時等待回復；0104，延時等待回復；0103，延時等待回復，0102，延時等待 ...

你先去看一下,是不是Modbus
如果是,就不是你這種時序了
應該是接收和發(fā)送同時進行的
每接收一個字節(jié)的數(shù)據就保存一次,30mS沒有接收到下一個字節(jié),就認為是數(shù)據結束了
接收是要開啟中斷進行接收的,你不知道什么時候來數(shù)據的
單片機發(fā)送是另外一個程序,跟接收不一樣的,你只管發(fā)送就行
作者: xuyaqi    時間: 2022-10-12 19:36
gaima 發(fā)表于 2022-10-12 19:04
感謝各位大佬回復。我是按照0101，延時等待回復；0104，延時等待回復；0103，延時等待回復，0102，延時等待 ...

明顯0101收到，在你的等待時間沒有回復你，所以你得要求對方收到馬上回復你，你收到0101回復后再通知下一位，這樣才不會亂。
作者: gaima    時間: 2022-10-12 20:07
xuyaqi 發(fā)表于 2022-10-12 19:36
明顯0101收到，在你的等待時間沒有回復你，所以你得要求對方收到馬上回復你，你收到0101回復后再通知下一 ...

對，就這個意思，我該怎么寫，收到這個回復？光是加長delay，沒效果。
作者: 人中狼    時間: 2022-10-12 21:32
這是協(xié)議設計的問題，你現(xiàn)在的通訊協(xié)議不合適，或者可以說不算是通訊協(xié)議
作者: gaima    時間: 2022-10-12 22:50
人中狼 發(fā)表于 2022-10-12 21:32
這是協(xié)議設計的問題，你現(xiàn)在的通訊協(xié)議不合適，或者可以說不算是通訊協(xié)議

因為從機也是我瞎編的，都還沒加入crc檢驗，協(xié)議按自己想的簡單的來。我希望先架好框架，通訊正常順暢，采集到的數(shù)據直接轉到串口屏上去。
作者: 人中狼    時間: 2022-10-12 23:16
協(xié)議不是這樣定義的，可以借用MODBUS協(xié)議
作者: gaima    時間: 2022-10-13 08:47
用的是串口中斷，我用485轉usb試驗，延時200，8字節(jié)數(shù)據才能完整的收到。懷疑是延時200里，已經接收到數(shù)據了。用max485，發(fā)送轉接收，這主機接收完全沒反應。用自動收發(fā)的485芯片，才看到我要的接收反饋5A A5。我只想做到基本的一問一答，主機和從機都是我寫的，還扯不到rtu協(xié)議吧。
作者: xuyaqi    時間: 2022-10-13 09:50
gaima 發(fā)表于 2022-10-12 20:07
對，就這個意思，我該怎么寫，收到這個回復？光是加長delay，沒效果。

在規(guī)定時間沒有收到回復，說明這一路有故障放棄，然后通知下一路，同樣過程。
作者: 人人學會單片機    時間: 2022-10-13 12:19
參考這個  http://www.torrancerestoration.com/bbs/dpj-214747-1.html
作者: Y_G_G    時間: 2022-10-13 13:18
gaima 發(fā)表于 2022-10-12 22:50
因為從機也是我瞎編的，都還沒加入crc檢驗，協(xié)議按自己想的簡單的來。我希望先架好框架，通訊正常順暢， ...

如果你用串口屏,那就應該用跟串口屏一樣的協(xié)議,這樣一來,串口屏和空調控制就可以用相同的函數(shù)了
不用再自己搞一個什么協(xié)議
一般串口屏都有協(xié)議的
作者: gaima    時間: 2022-10-14 09:08
人人學會單片機 發(fā)表于 2022-10-13 12:19
參考這個  http://www.torrancerestoration.com/bbs/dpj-214747-1.html

感謝，有樣例，我學習最快了。
作者: gaima    時間: 2022-10-14 09:15
Y_G_G 發(fā)表于 2022-10-13 13:18
如果你用串口屏,那就應該用跟串口屏一樣的協(xié)議,這樣一來,串口屏和空調控制就可以用相同的函數(shù)了
不用再 ...

欣瑞達或者迪文串口屏，它就是8字節(jié)指令，所以發(fā)送函數(shù)用的同一個。但是接收函數(shù)就不行了，空調機一個指令就有43個字節(jié)。我給定義了一個接收長度。懷疑發(fā)送delay時，接收中斷已經啟動，但是接收長度還使用的上一個長度。
作者: coody_sz    時間: 2022-10-14 10:19
串口時序都是固定的，怎么會亂？亂的是你的波特率或數(shù)據格式不對，導致亂碼。
作者: Y_G_G    時間: 2022-10-14 16:32
gaima 發(fā)表于 2022-10-14 09:15
欣瑞達或者迪文串口屏，它就是8字節(jié)指令，所以發(fā)送函數(shù)用的同一個。但是接收函數(shù)就不行了，空調機一個指 ...

不管是發(fā)送還是接收,正常來說,都不會用Delay(200)這種函數(shù)的
不管是發(fā)送/接收的數(shù)據是多少個字節(jié)的,都是同時進行的
中斷中要檢測是發(fā)送還是接收中斷,只在中斷中緩存數(shù)據
所有的數(shù)據又不是同步的,有時候你還沒發(fā)送完,就接收到一個數(shù)據了
作者: gaima    時間: 2022-10-18 22:50
Y_G_G 發(fā)表于 2022-10-14 16:32
不管是發(fā)送還是接收,正常來說,都不會用Delay(200)這種函數(shù)的
不管是發(fā)送/接收的數(shù)據是多少個字節(jié)的,都是 ...

感謝大佬回復，是考慮到指令發(fā)出，處理，再接收，中間這段時間不可控。主機用while（count），那萬一沒收到信號，就要無限死機了，再加定時器的話，不是跟Delay（200）的延時一樣的嘛。這問題困擾我好久了。
作者: Y_G_G    時間: 2022-10-19 14:01
gaima 發(fā)表于 2022-10-18 22:50
感謝大佬回復，是考慮到指令發(fā)出，處理，再接收，中間這段時間不可控。主機用while（count），那萬一沒收 ...

增加一個全局變量 T0_1ms_uart

這個變量在定時器中斷中++
//定時器中斷
{
if(T0_1ms_uart<250)T0_1ms_uart++;//串口時間++}

這個變量在串口中斷中,每次接收到一個字節(jié)數(shù)據就清除
//串口中斷
{

T0_1ms_uart=0//接收完一個字節(jié)數(shù)據,重新計時

}

你就可以在while中增加一個   T0_1ms_uart>某個時間   這樣的判斷
只要T0_1ms_uart的值大于你設定的值,比如200mS,就說明:在串口接收完一個字節(jié)的數(shù)據之后,超過200mS就再沒有接收到新的數(shù)據了
作者: gaima    時間: 2022-10-22 16:51
Y_G_G 發(fā)表于 2022-10-19 14:01
增加一個全局變量 T0_1ms_uart

這個變量在定時器中斷中++

感謝各位大佬回復。終于搞清楚了，是從機模塊，接收發(fā)送切換太快，主機的接收漏收了。從機加了延時好了。



歡迎光臨 (http://www.torrancerestoration.com/bbs/) Powered by Discuz! X3.1