RK3568開發筆記（九）：開發板buildroot固件調通RS485口，運行項目中RS485協議調試工具Demo

前言

  上一篇已經將Qt移植過去了，此時我們移植整體應用不是什麼問題了，那麼現在應用對外得接口使用了RS485接口，板載了一個RS485，於是需要調通，兼容這個開發板得RS485。

 

補充

  看起來很簡單，弄起來不懂得就是不懂，懂得雖然懂還得花時間去研究一下開發板特性，與廠家溝通下，改下代碼，得益於之前使用HI3559DV300做過類似得RS485，所以這次弄起來花費了不太麻煩。

 

調通RS485過程

步驟一：RS485調試設備與開發板連線

  先得有個RS485調試轉USB，這樣才能調試，界限，筆者得是綠聯得RS422/485口，如下圖：
  

  開發板485口原理圖：
  

  於是接線，對了，這個口子是2.54mm得4dip得dip接插件，這個做硬件得一般都會備點貨，屬於通用接口，當年各種都備貨了一點：
  

  剪一根的一半，然後按照加插件插入的順序接入，因爲看到1和4引腳是聯通的地，萬用表測了對覆銅層通的（GND），直接1和4接到一起了，然後接A對應T/R+，B對應T/R-，如下圖：
  

  接入發開飯：
  

  另外一頭usb接入PC電腦，用串口打開即可（PS：485的usb模塊對於pc來說就是一路串口）。

步驟二：打開開發板RS485調試工具

  這裏的話，因爲開發板使用的buildroot，去打開RS485這個類似於串口的設備還真沒有，得益於筆者項目研發都會產出階段性調試工具，於是便有了如下工具（PS：官方有個RS485調試Qt的demo，讀者可以使用官方的）：
  

  （對了，這裏還有相關工具的交叉編譯移植，其實跟x86下編譯類似，不贅述了，不懂得可以查看《RK3568開發筆記（八）：開發板燒寫buildroot固件（支持hdmi屏），搭建Qt交叉編譯開發環境，編譯一個Demo，目標板運行Demo測試》得demo編譯過程，其實是一樣的。

步驟三：調試工具輪詢接收測試485口

  因爲調試工具是被動接收485數據的，所以pc端打開485之後，1s發送一次，每一個端口依次打開，測試485口試哪個口。
  
  然後，結果試每個口都不行，這時候就懷疑：

• 是否試AB的正負線接反了，可以直接交換，測一輪，也可以覈對一次。
• Rs485口是否有特殊的，需要自行拉上拉下（這裏得到官方驗證，默認是拉上的，只能發出不接收）
  （PS：通過客服技術支持，得到口爲ttyS7，且需要上下拉，默認是上拉，只發送）

  於是加了一個按鈕，直接發送出去測試一下：
  

  PC端收到了發送過來的消息：
  

  確認了，是需要上下拉，這時候查閱官方文檔，並沒有關於上下拉的描述，只能通過官方提供的RS485的Qtdemo來提取了。

步驟四：提取官方QT調試RS485的demo中的關鍵上下拉邏輯代碼

  

  

  直接摳代碼，一般是通過echo輸入到一個設備文件、file打開設備文件，或者ioctl的方式，這三種方式稍微提一下區別（何種方式看開發板方案上是怎麼提供的）：

• echo方式：cmd的方式，程序中用system，qt中可以用QProcess，這個方式效率相對有點低，不適合頻發發送接收的狀態
• file方式：file方式是文件方式，兼容linux系統和qt開發最合適的方式，當作文件寫入控制，很好的處理了環境問題，效率比echo高，比ioctl低，但是5ms足夠幾百字節的完成切換了（具體要按照實際情況發送調）。
• ioctl方式：ioctl的方式在qt中不是很好，在某些情況下，qt根本不需要接觸到sysroot下面的依賴庫，直接qt交叉編譯自己的庫就可以，本開發板是已經融合好了  （PS：像海思這種，就只能將qt反向弄到sample裏面去，因爲環境都是makefile配置的）
    以上三種各有優缺點，但是其實選擇權不在我們，而在主板方案提供商，所以拿過來用，能用就行了，別死磕。
    提取代碼如下：
    

  

步驟五：改造我們的串口代碼

  添加一個宏定義：
  

  在串口設備管理模塊添加相關代碼.
  在打開的時候，添加代碼：
  

  在發送的時候，添加代碼：
  

  在關閉的時候，添加代碼：
  

  改在完以後，再交叉編譯協議調試工具過去測試。

步驟六：調試解析成功

  在目標板上打開應用，打開對應的串口，然後實現收發成功：
  

 

小結

  RS485調試通了，大項目中的調試工具也通了，那麼剩下的就是移植應用了，移植應用中，遇到了新的問題（做嵌入式，輪上都是沒問題，實際上問題一個又一個，運氣好不麻煩，運氣不好卡個一兩天，麻煩的一兩週都常有的事）