STC15單片機(jī)串口通信,時(shí)序太亂,怎么改程序?

ID:1046624 · 發(fā)表于 2022-10-12 15:28

這是485的報(bào)文，黑色是主機(jī)發(fā)的，按01 01，01 04 ，01 03 ，01 02 逐條發(fā)，藍(lán)色是從機(jī)回答。

主機(jī)的框架

ID:123289 · 發(fā)表于 2022-10-12 17:06

先構(gòu)思一下，如何將數(shù)據(jù)整理成：你所認(rèn)為的不亂，而后再按你整理的次序進(jìn)行收發(fā)。

ID:401564 · 發(fā)表于 2022-10-12 17:59

感覺這就是Modbus,沒什么亂不亂的
按照協(xié)議寫就行

ID:94031 · 發(fā)表于 2022-10-12 18:18

把讀空調(diào)機(jī)狀態(tài)，讀空調(diào)傳感器命令格式及回答格式搞清楚，就不會(huì)覺得亂。

ID:1046624 · 發(fā)表于 2022-10-12 19:04

感謝各位大佬回復(fù)。我是按照0101，延時(shí)等待回復(fù)；0104，延時(shí)等待回復(fù)；0103，延時(shí)等待回復(fù)，0102，延時(shí)等待。收到回復(fù)判斷驗(yàn)證下，再發(fā)去5A A5。現(xiàn)在第一條，0104的指令發(fā)出，后才收到0101的回答指令。順序亂了，影響我準(zhǔn)確性。我加長延時(shí)也沒用。還有0104、0103、0102的指令還有幾率發(fā)不出被吞。
485單獨(dú)測試從機(jī)，幾乎不會(huì)漏發(fā)，響應(yīng)時(shí)間也就30ms左右。

ID:401564 · 發(fā)表于 2022-10-12 19:30

gaima 發(fā)表于 2022-10-12 19:04
感謝各位大佬回復(fù)。我是按照0101，延時(shí)等待回復(fù)；0104，延時(shí)等待回復(fù)；0103，延時(shí)等待回復(fù)，0102，延時(shí)等待 ...

你先去看一下,是不是Modbus
如果是,就不是你這種時(shí)序了
應(yīng)該是接收和發(fā)送同時(shí)進(jìn)行的
每接收一個(gè)字節(jié)的數(shù)據(jù)就保存一次,30mS沒有接收到下一個(gè)字節(jié),就認(rèn)為是數(shù)據(jù)結(jié)束了
接收是要開啟中斷進(jìn)行接收的,你不知道什么時(shí)候來數(shù)據(jù)的
單片機(jī)發(fā)送是另外一個(gè)程序,跟接收不一樣的,你只管發(fā)送就行

ID:94031 · 發(fā)表于 2022-10-12 19:36

gaima 發(fā)表于 2022-10-12 19:04
感謝各位大佬回復(fù)。我是按照0101，延時(shí)等待回復(fù)；0104，延時(shí)等待回復(fù)；0103，延時(shí)等待回復(fù)，0102，延時(shí)等待 ...

明顯0101收到，在你的等待時(shí)間沒有回復(fù)你，所以你得要求對(duì)方收到馬上回復(fù)你，你收到0101回復(fù)后再通知下一位，這樣才不會(huì)亂。

ID:1046624 · 發(fā)表于 2022-10-12 20:07

xuyaqi 發(fā)表于 2022-10-12 19:36
明顯0101收到，在你的等待時(shí)間沒有回復(fù)你，所以你得要求對(duì)方收到馬上回復(fù)你，你收到0101回復(fù)后再通知下一 ...

對(duì)，就這個(gè)意思，我該怎么寫，收到這個(gè)回復(fù)？光是加長delay，沒效果。

ID:384109 · 發(fā)表于 2022-10-12 21:32

這是協(xié)議設(shè)計(jì)的問題，你現(xiàn)在的通訊協(xié)議不合適，或者可以說不算是通訊協(xié)議

ID:1046624 · 發(fā)表于 2022-10-12 22:50

人中狼發(fā)表于 2022-10-12 21:32
這是協(xié)議設(shè)計(jì)的問題，你現(xiàn)在的通訊協(xié)議不合適，或者可以說不算是通訊協(xié)議

因?yàn)閺臋C(jī)也是我瞎編的，都還沒加入crc檢驗(yàn)，協(xié)議按自己想的簡單的來。我希望先架好框架，通訊正常順暢，采集到的數(shù)據(jù)直接轉(zhuǎn)到串口屏上去。

ID:384109 · 發(fā)表于 2022-10-12 23:16

協(xié)議不是這樣定義的，可以借用MODBUS協(xié)議

ID:1046624 · 發(fā)表于 2022-10-13 08:47

用的是串口中斷，我用485轉(zhuǎn)usb試驗(yàn)，延時(shí)200，8字節(jié)數(shù)據(jù)才能完整的收到。懷疑是延時(shí)200里，已經(jīng)接收到數(shù)據(jù)了。用max485，發(fā)送轉(zhuǎn)接收，這主機(jī)接收完全沒反應(yīng)。用自動(dòng)收發(fā)的485芯片，才看到我要的接收反饋5A A5。我只想做到基本的一問一答，主機(jī)和從機(jī)都是我寫的，還扯不到rtu協(xié)議吧。

ID:94031 · 發(fā)表于 2022-10-13 09:50

gaima 發(fā)表于 2022-10-12 20:07
對(duì)，就這個(gè)意思，我該怎么寫，收到這個(gè)回復(fù)？光是加長delay，沒效果。

在規(guī)定時(shí)間沒有收到回復(fù)，說明這一路有故障放棄，然后通知下一路，同樣過程。

ID:390416 · 發(fā)表于 2022-10-13 12:19

參考這個(gè) http://www.zg4o1577.cn/bbs/dpj-214747-1.html

ID:401564 · 發(fā)表于 2022-10-13 13:18

gaima 發(fā)表于 2022-10-12 22:50
因?yàn)閺臋C(jī)也是我瞎編的，都還沒加入crc檢驗(yàn)，協(xié)議按自己想的簡單的來。我希望先架好框架，通訊正常順暢， ...

如果你用串口屏,那就應(yīng)該用跟串口屏一樣的協(xié)議,這樣一來,串口屏和空調(diào)控制就可以用相同的函數(shù)了
不用再自己搞一個(gè)什么協(xié)議
一般串口屏都有協(xié)議的

ID:1046624 · 發(fā)表于 2022-10-14 09:08

人人學(xué)會(huì)單片機(jī) 發(fā)表于 2022-10-13 12:19
參考這個(gè) http://www.zg4o1577.cn/bbs/dpj-214747-1.html

感謝，有樣例，我學(xué)習(xí)最快了。

ID:1046624 · 發(fā)表于 2022-10-14 09:15

Y_G_G 發(fā)表于 2022-10-13 13:18
如果你用串口屏,那就應(yīng)該用跟串口屏一樣的協(xié)議,這樣一來,串口屏和空調(diào)控制就可以用相同的函數(shù)了
不用再 ...

欣瑞達(dá)或者迪文串口屏，它就是8字節(jié)指令，所以發(fā)送函數(shù)用的同一個(gè)。但是接收函數(shù)就不行了，空調(diào)機(jī)一個(gè)指令就有43個(gè)字節(jié)。我給定義了一個(gè)接收長度。懷疑發(fā)送delay時(shí)，接收中斷已經(jīng)啟動(dòng)，但是接收長度還使用的上一個(gè)長度。

ID:1034262 · 發(fā)表于 2022-10-14 10:19

串口時(shí)序都是固定的，怎么會(huì)亂？亂的是你的波特率或數(shù)據(jù)格式不對(duì)，導(dǎo)致亂碼。

ID:401564 · 發(fā)表于 2022-10-14 16:32

gaima 發(fā)表于 2022-10-14 09:15
欣瑞達(dá)或者迪文串口屏，它就是8字節(jié)指令，所以發(fā)送函數(shù)用的同一個(gè)。但是接收函數(shù)就不行了，空調(diào)機(jī)一個(gè)指 ...

不管是發(fā)送還是接收,正常來說,都不會(huì)用Delay(200)這種函數(shù)的
不管是發(fā)送/接收的數(shù)據(jù)是多少個(gè)字節(jié)的,都是同時(shí)進(jìn)行的
中斷中要檢測是發(fā)送還是接收中斷,只在中斷中緩存數(shù)據(jù)
所有的數(shù)據(jù)又不是同步的,有時(shí)候你還沒發(fā)送完,就接收到一個(gè)數(shù)據(jù)了

ID:1046624 · 發(fā)表于 2022-10-18 22:50

Y_G_G 發(fā)表于 2022-10-14 16:32
不管是發(fā)送還是接收,正常來說,都不會(huì)用Delay(200)這種函數(shù)的
不管是發(fā)送/接收的數(shù)據(jù)是多少個(gè)字節(jié)的,都是 ...

感謝大佬回復(fù)，是考慮到指令發(fā)出，處理，再接收，中間這段時(shí)間不可控。主機(jī)用while（count），那萬一沒收到信號(hào)，就要無限死機(jī)了，再加定時(shí)器的話，不是跟Delay（200）的延時(shí)一樣的嘛。這問題困擾我好久了。

ID:401564 · 發(fā)表于 2022-10-19 14:01

gaima 發(fā)表于 2022-10-18 22:50
感謝大佬回復(fù)，是考慮到指令發(fā)出，處理，再接收，中間這段時(shí)間不可控。主機(jī)用while（count），那萬一沒收 ...

增加一個(gè)全局變量 T0_1ms_uart

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

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

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

}

你就可以在while中增加一個(gè) T0_1ms_uart>某個(gè)時(shí)間這樣的判斷
只要T0_1ms_uart的值大于你設(shè)定的值,比如200mS,就說明:在串口接收完一個(gè)字節(jié)的數(shù)據(jù)之后,超過200mS就再?zèng)]有接收到新的數(shù)據(jù)了

ID:1046624 · 發(fā)表于 2022-10-22 16:51

Y_G_G 發(fā)表于 2022-10-19 14:01
增加一個(gè)全局變量 T0_1ms_uart

這個(gè)變量在定時(shí)器中斷中++

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

帳號(hào)		自動(dòng)登錄	找回密碼
密碼			立即注冊(cè)

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

STC15單片機(jī)串口通信,時(shí)序太亂,怎么改程序?