如圖2 所示，波特率設置為115 200，奇校驗，數據位8 位，停止位1 位，422 發送數據，發送出來的數據經232 顯示到PC 機串口接收窗口中，如下圖接收框顯示數據。

如圖2 所示，通過串口調試工具，手動發送數據1、2、3、4、5、6、7、8、9、10，經232 轉422 轉換為422 數據形式，再經fpga 處理。則在超級終端上顯示出接收到的422 數據個數以及數據。

2.2.3 驅動程序
驅動相當于用戶與底層FPGA 邏輯的一個接口，里面包含一些初始化函數、發送函數、接收函數，初始化包括配置寄存器，波特率配置，通道選擇，奇偶校驗設置等，最后根據需求直接寫一個測試函數，那么在硬件測試時先通過workbench[5] 進行調試，調試無誤后，通過wftp 下載到cpu 中，然后通過超級終端直接調用測試函數即可，就不需要之前手動單步通過寫、讀操作來進行配置和測試了。

429 與422 通過檢測狀態位來控制發送接收的驅動測試流程如圖3 所示。在上述測試過程中，發送一個數據則接收一個數據，僅僅檢測到了接收與發送功能上的正確性。考慮到在應用過程中，并非發送一個數據接收完再發送一個數據，比如發送若干個數據之后，此時才開始進行接收，那么在這種情況下，接收fifo 緩存中將存在若干個數據，因此引入fifo的data_count 計數，表示此時緩沖中儲存有多少個數據，然后依次把這些數據給讀出來，這種情況下，也存在溢出的可能性，因此引出溢出狀態位。

改進后引入fifo 計數和溢出狀態檢測的驅動測試流程如圖4 所示。

3 調試過程中遇到的關鍵問題及分析

調用驅動對422 進行外回環測試0 通道發0 通道收1 通道發1 通道收，這時出現問題：當發送多個數據接收多個數據，或者多次測試時會出現接收數據錯誤或者未接收到數據的現象，但是通過超級終端單步測試確是是正確的。用chipscope[7] 抓信號，發現接收數據時，會出現接收完數據后，fifo 非空的狀態，正常應是空狀態，這樣就把之前的數據再次接收了一遍，抓到的錯誤如圖5，其中test 是我們為了測試方便加的一個參數用來檢測DAT 變化，因為DAT 是雙向數據無法抓到。

分析原因是由于發送的數據被接收后，再次發送數據前檢測狀態位未來得及告便，導致錯誤，于是在檢測狀態位后面加延遲taskdelay(1)，測試正確，但是與之而來的問題是這樣大大影響了波特率，因為1 代表1/60ms，而波特率是ns 級的，于是用一個讀寄存器操作來代替這個延遲，讀一個寄存器狀態需要的時間大約為us 級，具有一定的延時但性能又優于taskdelay，并且讀寄存器也不會影響其他的正常功能，至此以為問題解決了。但是后來為了完善功能，在邏輯中添加count，修改驅動進行測試，發現打印到超級終端上的fifo 計數不正確，發送一個數計數卻是31，繼續發送一個逐個計數為61，91…. 用chipscope 抓信號發現在tf_push 有效時（tf_push 控制發送fifo 的寫信號），同一數據輸入到fifo 了31 次，根據邏輯tf_push 在寫信號有效以及地址是發送緩沖地址且此時是正常工作狀態時就有效，那么根據chipscope 抓到的，發現在一個地址有效，寫信號有效的周期內，tf_push 持續有效，持續計數就說明此時有效了多個時鐘周期，每個時鐘周期數據寫入到發送fifo 中一次，但是我們期望的是寫信號有效地址有效一個周期內，數據只寫入一次，因此我們修改邏輯，使tf_push 有效的周期縮短為一個時鐘周期，同時根據這個問題，也判斷了之前接收數據總出錯，出現一個數據接收兩次的現象，需要加適當的延時才不會出錯的原因正是如此。 明白這些之后，我們又把驅動中檢測狀態位與接收之間的延時去掉，再次測試，這次果如預期的一樣不再出錯，至此才找到了根本原因。對于這個問題Modelsim 是發現不了的，因為Modelsim 仿真時輸入激勵比如寫信號wr_n 有效設置的就是一個時鐘周期，因此chipscope 能夠發現modelsim 發現不了的
問題，這也就是硬件調試的功效。