使用MSCOMM32控件編寫串口程序
在此基礎上,我們看一個例子:
下面兩張圖 是一個 利用MsCom進行串口通訊(中斷方式)的程序框圖和回調VI的程序框圖
使用RTThrsehold屬性設置觸發接收中斷事件的觸發條件,本程序設置為1,當緩沖器接收到一個字符時,就會發生中斷事件——oncomm事件中斷,很多條件都可以產生oncomm事件,區分產生中斷的原因有Comevent的屬性值來確定,當conevent為2時,表示是由于接收到字符產生的中斷,由此進入接受中斷處理程序。
而中斷處理程序,接收到的數據是變體數據,轉換為數組型數據,發送數組中,最后送到返回變量中,供顯示和繪制實時圖使用。
commevent的參數 對比表!
根據應用程序的用途和功能,在連接到其它設備過程中,以及接收或發送數據過程中,可能需要監視并響應一些事件和錯誤。 | ||
常數 | 值 | 描述 |
ComEvSend | 1 | 發送緩沖區中的字符數少于SThreshold。 |
ComEvReceive | 2 | 接收到Rthreshold個字符。在使用Input屬性移去接收緩沖區中的數據之前,該事件將持續產生。 |
ComEvCTS | 3 | CTS信號發生變化。 |
ComEvDSR | 4 | DSR信號發生變化。該事件僅在DSR由1變為0時觸發。 |
ComEvCD | 5 | CD信號發生變化。 |
ComEvRing | 6 | 檢測到電話振鈴。某些UART(通用異步收發器)可能不支持本事件。 |
ComEvEOF | 7 | 收到文件結束符(ASCII字符26)。 |
下列錯誤同樣會觸發OnComm事件,并且在CommEvent屬性中寫入相應的值。 | ||
| ||
設置值 | 值 | 描述 |
ComEventBreak | 1001 | 收到Break信號。 |
ComEventFrame | 1004 | 幀錯誤。硬件檢測到幀錯誤。 |
ComEventOverrun | 1006 | 端口超限。在下一個字符到達端口之前,前一字符還沒有從硬件中讀走,因而丟失。 |
ComEventRxOver | 1008 | 接收緩沖區溢出。接收緩沖區已沒有空間。 |
ComEventRxParity | 1009 | 奇偶校驗錯誤。硬件檢測到奇偶校驗錯誤。 |
comEventTxFull | 1010 | 發送緩沖區滿。在試圖將字符傳入發送緩沖區時,該緩沖區已滿。 |
ComEventDCB | 1011 | 在為端口獲取設備控制塊(DCB)時,發生不可預料的錯誤。 |
另外: 需要注意的是
如下圖所示:
U8類型數值的數組。
————————————————————————————————————————————————
關于RTThrsehold
例如 接收到的數據遠遠小于發送的數據了,接收到的數據出現亂碼了,等等。
經過反復的實驗
我發現 如果將inputlen設置的過小(如1),同時呢,發送的波特率過高,就會出現接受到的數據小于實際發送出的數據。
因為將RTHrsehold設置為1的時候,每收到一個字符就會產生一次中斷,這次中斷會提取 inputlen個數的字符。
如果波特率過高,就會導致,中斷不能夠及時發生(每次中斷只讀取一個字符,而產生的中斷數目小于實際發送的字符數),很多數據到最后積累在緩沖區內。
(這是我通過程序最后讀取緩沖區的數據大小進行的判斷)
因此必要時,可以將RTHrsehold和inputlen的值都設大一些,才能夠正常。(使得中斷處理函數的時間遠遠小于產生中斷的時間即可)
評論