專案delay的原因竟然是不會用UART驅動1-Wire
麥叔是搞嵌入式的,最近專案delay,他和我說用UART驅動1-Wire裝置總是出現問題,故寫此文來拯救他。
作者之前UART寫過(點我),1-Wire(點我)也寫過,本文介紹如何用主機的UART驅動1-Wire從機裝置,建議先看看以上兩篇文章,再閱讀本文,效果更佳。
硬體電路
1-Wire結構簡單,一根線就可以通訊,常見的18B20用的就是1-Wire結構。微控制器的串列埠UART(多是TTL電平),如何用微控制器控制通用的1-Wire裝置呢?如果MCU和從裝置的電平不一致如何解決?軟體協議又是如何控制的呢?本文主要解決這兩個問題。
主機或從機將資料線拉低到GND表示資料0,將資料線釋放為高表示資料1,高電平由上拉電阻(一般是4.7K)提供。
- 當MCU傳送邏輯1時,經過反相器,匯流排呈現邏輯0,邏輯0經過1-WIRE器件的反相器,即會收到邏輯1;
- 當MCU傳送邏輯0時,經過反向器,匯流排呈現邏輯1,邏輯1經過1-WIRE器件的反相器,即會收到邏輯0;
- 當1-WIRE器件傳送邏輯1時,Tx處的NMOS導通,匯流排呈現邏輯0,經過MCU Rx處的反相器,MCU會收到邏輯1;
- 當1-WIRE器件傳送邏輯0時,Tx處的NMOS截止,匯流排呈現邏輯1,經過MCU Rx處的反相器,MCU會收到邏輯0;
主機端(BUS MASTER)多為MCU,因為MCU的TXD不是漏極開路,因此通常需要一個外部漏極開路緩衝電路,該電路可以由分立元件構成。
原理也和簡單,兩個NMOS管2N7002:
- TXD輸出高電平時,左邊的2N7002導通,右邊的截止,DQ被4.7K電阻上拉至Vpullup高電平;
- TXD輸出低電平時,左邊的2N7002截止,右邊的導通,DQ被拉低至低電平0;
也可以用整合晶片NC7WZ07,如下圖所示,TXD輸出高,DQ=Vpullup,TXD輸出低,DQ=0;
軟體協議
解決了硬體電路問題,我們再來看軟體協議部分,1-Wire的協議可以分為復位/應答、寫0/寫1時隙、讀0/讀1時隙。
復位應答
如下圖,上面部分是1-Wire的復位/應答時序,下面是UART的時序。
原理:
主機以9600的波特率傳送資料0XF0,因為LSB在前,0XF0=00001111,加上最前面的Start Bit和最後面的Stop Bit,完整的資料為:0000011111,代表主機先發了5位的0,然後發了5位的1;9600波特率,一位傳輸時間是1/9600=104.2us,所以低電平持續時間為104.2*5=521us,滿足480~960us復位匯流排的時序要求。
那主機收到什麼資料代表從機應答呢?
首先主機如果傳送F0後收到還是F0,說明從機沒有應答,可以簡單的判斷收到的資料為非F0即代表從機應答。
根據1-Wire的時序波形,也可以進行推算,從上圖看,Data0-Data3均為0,因為1-Wire時序是有一定時間範圍,並不是固定的脈寬,如TPDH為15-60us,TPDL為60-240us,所以Data4~Data7是有一定的組合,返回0X10(00001000) to 0X90(00001001)都代表從機應答。
寫0/寫1時隙
主機寫0就是0X00,也可以加入回讀,回讀值即為寫的值。
寫1就是0XFF,回讀值即為寫的值。
讀0/讀1時隙
關於讀時隙,可以先看主機讀1時,主機先拉低匯流排,一般時間1us左右,UART的Start Bit會佔1/115200=8.7us的脈寬(大於1us),所以從Data0開始,後面的資料都為1,即讀到的資料為11111111(0XFF)代表讀到的是1。
那讀0也就很簡單,讀到的資料不為0XFF即為0。
小結一下
實際程式碼裡面的判斷,可以簡單處理,復位/應答:傳送F0,返回不為F0,即代表從機應答;讀0/讀1時隙:主機讀到0XFF即為1,讀到非0XFF即為0;簡單又可靠,麥叔還不會。
今天的文章到這裡就結束了,希望對你有幫助,我們下一期見。
相關文章
- 不會用專案管理軟體,做不成專案經理專案管理
- NV驅動重灌不會影響CUDA
- 基於Linux的tty架構及UART驅動詳解Linux架構
- 不會玩魔獸的專案經理不是好專案經理
- 初學Vue.js,用 vue ui 建立專案會不會被鄙視Vue.jsUI
- 教你優雅解決專案Delay和交付質量差的問題
- 不應使用Excel進行專案資源規劃的 7 個原因Excel
- 測試驅動專案設計需求迭代
- 修改hosts檔案不生效原因
- 不會 Web 開發,也能讓資料“動”起來的開源專案!Web
- 測試驅動開發在專案中的實踐
- 簡單分析synchronized不會鎖洩漏的原因synchronized
- 你熟知的開源專案,幕後推手竟然是他們?
- Spring IO 2019大會上Axon+Spring的事件驅動微服務和CQRS原始碼專案Spring事件微服務原始碼
- B站、小紅書崩,原因竟然是...它
- extcon驅動及其在USB驅動中的應用
- 【RAC】Oracle19.13之後的grid,節點重啟後不會自動驅動Oracle
- 以OKR驅動企業專案化管理變革OKR
- input delay和output delay講解
- 千萬不要“教”孩子畫畫,原因竟然是這樣
- 遠端升級頻頻失敗?原因竟然是…
- 能源驅動的 AI 將會被用來解決能源問題AI
- 一個SaaS專案失敗的原因 從個人角度覆盤專案失敗的5個重要原因
- 導致專案需求蔓延的原因 應對專案蔓延的資訊化手段
- 華為權威報告新鮮出爐,拉低應用質量的原因竟然是它!
- vue2 專案執行npm run serve 啟動專案卡在24%一直不動VueNPM
- 大量小檔案不適合儲存於HDFS的原因
- postgresql VACUUM 不會從表中刪除死行的三個原因SQL
- 其實專家也有不少不會的
- 異常重啟怎麼破?多方排查後,原因竟然是。。。
- 常見的7種專案衝突的主要原因
- 專案成本超支的主要原因以及解決方法
- 專案管理計劃必不可少的五個原因專案管理
- 專案控制管理:如何避免專案不達標?
- UART
- 系統崩了,竟然是不規範列印日誌的鍋?
- MySQL不建議用UUID做innodb主鍵的幾條原因MySqlUI
- 盤點敏捷專案失敗的6個主要原因敏捷