標(biāo)題: 關(guān)于單片機紅外對射和超聲波對射程序編寫的疑問 [打印本頁]
作者: firm 時間: 2021-7-25 15:56
標(biāo)題: 關(guān)于單片機紅外對射和超聲波對射程序編寫的疑問
大家好，第一次發(fā)帖求助，因為這個問題不知道該怎么問，所以會寫很長一段描述，請見諒…
目標(biāo)：
簡單來說就是做成紅外對射，超聲波對射，距離顯示誤差可以在±10mm之間。發(fā)射端發(fā)射紅外，接收端接收到紅外后，兩者差不多同時發(fā)射超聲波，接收端能接收到發(fā)射端發(fā)射的超聲波。
材料：
接收端：12MHz的stc89C52單片機開發(fā)板一個，VS838一個，SR-04一個，LCD1602一個
發(fā)射端：11.0592MHz的stc89C52RC開發(fā)板一個，紅外發(fā)射模塊（無晶振）一個，SR-04一個
前提：
1.SR-04在Trig端提供10us左右高電平后，自動開啟模塊內(nèi)部定時器，在接收完超聲波后，內(nèi)部定時器結(jié)束計時并通過Echo端發(fā)送內(nèi)部定時器所獲取時間的高電平，高電平持續(xù)時間即為超聲波來回一次的時間。
2.因為暫時缺設(shè)備，無法確定硬件是否有問題。所以只能先假設(shè)硬件都沒問題…
為了找到能差不多同步發(fā)送超聲波的時間點，發(fā)射端用keil4測從紅外程序到超聲波發(fā)射前所用時間。接收端則用計時器多次統(tǒng)計這段時間后取平均值。然后根據(jù)兩者時間差求得補償值。
使用C語言寫的，補償已經(jīng)考慮到晶振、進(jìn)入外部中斷前的語句時間、函數(shù)調(diào)用和退出。
之前把接收端的程序稍微修改下變成發(fā)射端程序后，我也是這么計算補償?shù)模Y(jié)果大致符合要求。但是發(fā)射端單獨寫就出現(xiàn)這個問題了。
發(fā)射端：約68620us
接收端：約68654us
5(進(jìn)程序)+12(堆棧)+ 68571(取測得最大值)+1(TR1=0)+12(退棧)+5(再進(jìn)程序)+12(再堆棧)+12(再退棧)+7(irflag判斷前幾句)+1(irflage=0)+13(timer_init)+3(distance=0)
（既然測得的最大值的補償都無法滿足，那平均值的補償就更沒有意義了）
在發(fā)射端添加補償+34us后，接收端顯示的距離還是小。
| 實際距離,mm | LCD顯示,mm |
| 100 | 20,34 |
| 150 | 88,94 |
| 200 | 156,162 |
| 250 | 196,204 |
| 300 | 244,250 |
如果根據(jù)數(shù)據(jù)顯示的，直接再多補償+50mm，差不多額外+148us那顯示可以正常。
問題：
1.是因為對超聲波模塊的理解有問題嗎？
2.是因為程序哪里沒有考慮到才引起的這個額外補償嗎？
發(fā)射和接收程序見附件:
help.rar
(84.29 KB, 下載次數(shù): 10)
2021-7-25 15:53 上傳
點擊文件名下載附件
作者: yzwzfyz 時間: 2021-7-26 09:55
1、看了，還不知道你問題的是什么問題？
2、【兩者差不多同時發(fā)射超聲波】收發(fā)雙方都發(fā)超波嗎？
3、你的【目標(biāo)】不是已實現(xiàn)了嗎？該發(fā)的發(fā)了，該收的收了。
【發(fā)射端發(fā)射紅外，接收端接收到紅外后，兩者差不多同時發(fā)射超聲波，接收端能接收到發(fā)射端發(fā)射的超聲波。】
4、你提供的表中，我算了一下，用本次值 - 上次值，
分別是：68.600，67.222，40.042，48.046
同樣相差50mm，但顯示之差卻不同。
建議：先不要補償，單獨驗證：同樣相差50mm，結(jié)果差值是否一樣？如果不一樣就必須有一個規(guī)律，否則就不用再做了，永遠(yuǎn)做不準(zhǔn)。
作者: firm 時間: 2021-7-28 22:45
首先感謝您的回復(fù)。
其次表示抱歉，我還以為沒人回復(fù)才沒收到消息或者提醒。
先回答您第二個問題：
我超聲波的對射是通過接收端是把SR-04的發(fā)射口擋住，發(fā)送端把另個一個SR-04接收口擋住實現(xiàn)的。但這個模塊要從Echo得到高電平的前提是自身Trig高電平維持10us左右。所以才會有發(fā)射端和接收端同時寫了Sonar_Send()。發(fā)射端是真正的發(fā)射超聲波，接收端只是為了讓接收端能觸發(fā)Echo，使它可以輸出高電平。
表中的LCD顯示這一列可能讓您誤解了。那是兩個值，22和34，測得的大多數(shù)情況下是在這兩個值跳。
一開始，我并沒有加任何補償直接運行，于是得到了表中LCD顯示值。
那我想可能是發(fā)射端（從紅外發(fā)射到Sonar_Send()之前）和接收端（從紅外接收到Sonar_Send()之前）時間差太多，使得無法同步Sonar_Send()，才導(dǎo)致距離顯示小的問題。
于是根據(jù)上面計算的時間得到補償，并加在發(fā)射端中，結(jié)果和沒有補償值得到的顯示距離一樣。如果根據(jù)顯示的值，在原本補償?shù)幕A(chǔ)上再加+50mm的補償，那確實可以得到。
所以，我的問題就是，為什么會有這額外的補償？先假設(shè)硬件本身沒問題，是我程序哪里沒有考慮到？
作者: glinfei 時間: 2021-7-29 11:05
是挺有意思的，一開始還以為是溫度造成的呢。總之，我覺得，如果發(fā)射端補償，必須在接受端發(fā)出信號后，而發(fā)射端發(fā)出紅外后，發(fā)出超生前補償，才會有效。我感興趣的是148us的構(gòu)成？ 不過你這么玩，系統(tǒng)延時都超過了實際計時時間，可能很難找到延時原因。
作者: firm 時間: 2021-7-30 23:24
感謝您的回復(fù)，看到您的第一句，確實可以改進(jìn)程序中一些問題了。
先說結(jié)論：額外補償?shù)恼`差在重新調(diào)整后減少了大約10us，變?yōu)轭~外補償132us。
1.當(dāng)初寫的時候為了減少代碼和內(nèi)存，(340m/s-->0.34mm/us)時間轉(zhuǎn)為距離的函數(shù)拆成多段乘除法處理了。
這就導(dǎo)致了第一層誤差。現(xiàn)在直接用 time * 34 /100寫了。
2.聲速溫度的問題沒有考慮到，當(dāng)默認(rèn)340考慮了。
這就導(dǎo)致第二層誤差。現(xiàn)在以30度，聲速350m/s處理。
總的可以減少大約10us。不過還是和之前測試一樣得額外補償+50mm(即+132us)
總之，我覺得，如果發(fā)射端補償，必須在接受端發(fā)出信號后
您這句話我不太明白...接收端發(fā)出哪個信號后？接收端的Sonar_Send?還是Sonar_Receive?
我來解釋一下我怎么寫的吧。接收端在沒有紅外前，在main里循環(huán)。發(fā)射端在按鍵按下后發(fā)送紅外，此時接收端中斷開啟，開始接受紅外數(shù)據(jù)，等全部接收完之后返回主程序，并初始化超聲波用計時器，然后運行Sonar_Send。而接收端在紅外發(fā)送完畢之后延時，等待接收端運行到Sonar_Send前，然后幾乎同時啟動Sonar_Send。
:
50mm--[0.34mm/us]-->148us
| 歡迎光臨 (http://m.raoushi.com/bbs/) |
Powered by Discuz! X3.1 |