|
嵌入式系統或傳感器網絡的很多應用和測試都需要通過PC機與嵌入式設備或傳感器節點進行通信。其中，最常用的接口就是RS-232串口和并口（鑒于USB接口的復雜性以及不需要很大的數據傳輸量，USB接口用在這里還是顯得過于奢侈，況且目前除了SUN有一個支持USB的包之外，我還沒有看到其他直接支持USB的Java類庫）。SUN的CommAPI分別提供了對常用的RS232串行端口和IEEE1284并行端口通訊的支持。RS-232-C(又稱EIA RS-232-C，以下簡稱RS232)是在1970年由美國電子工業協會(EIA)聯合貝爾系統、調制解調器廠家及計算機終端生產廠家共同制定的用于串行通訊的標準。RS232是一個全雙工的通訊協議，它可以同時進行數據接收和發送的工作。
1.1
常見的Java
串口包
目前，常見的Java串口包有SUN在1998年發布的串口通信API：comm2.0.jar（Windows下）、comm3.0.jar（Linux/Solaris）；IBM的串口通信API以及一個開源的實現。鑒于在Windows下SUN的API比較常用以及IBM的實現和SUN的在API層面都是一樣的，那個開源的實現又不像兩家大廠的產品那樣讓人放心，這里就只介紹SUN的串口通信API在Windows平臺下的使用。
到SUN的網站下載
javacomm20-win32.zip
，包含的東西如下所示：
按照其使用說明（Readme.html）的說法，要想使用串口包進行串口通信，除了設置好環境變量之外，還要將win32com.dll復制到<JDK>/bin目錄下；將comm.jar復制到<JDK>/lib；把javax.comm.properties也同樣拷貝到<JDK>/lib目錄下。然而在真正運行使用串口包的時候，僅作這些是不夠的。因為通常當運行“java MyApp”的時候，是由JRE下的虛擬機啟動MyApp的。而我們只復制上述文件到JDK相應目錄下，所以應用程序將會提示找不到串口。解決這個問題的方法很簡單，我們只須將上面提到的文件放到JRE相應的目錄下就可以了。
值得注意的是，在網絡應用程序中使用串口API的時候，還會遇到其他更復雜問題。有興趣的話，你可以查看CSDN社區中“
關于網頁上
Applet
用
javacomm20
讀取客戶端串口的問題
”的帖子。
2
串口API
概覽
這是用于描述一個被底層系統支持的端口的抽象類。它包含一些高層的IO控制方法，這些方法對于所有不同的通訊端口來說是通用的。SerialPort 和ParallelPort都是它的子類，前者用于控制串行端口而后者用于控這并口，二者對于各自底層的物理端口都有不同的控制方法。這里我們只關心SerialPort。
這個類主要用于對串口進行管理和設置，是對串口進行訪問控制的核心類。主要包括以下方法
l
確定是否有可用的通信端口
l
為IO操作打開通信端口
l
決定端口的所有權
l
處理端口所有權的爭用
l
管理端口所有權變化引發的事件（Event）
這個類用于描述一個RS-232串行通信端口的底層接口，它定義了串口通信所需的最小功能集。通過它，用戶可以直接對串口進行讀、寫及設置工作。
2.4
串口API
實例
大段的文字怎么也不如一個小例子來的清晰，下面我們就一起看一下串口包自帶的例子---SerialDemo中的一小段代碼來加深對串口API核心類的使用方法的認識。
void listPortChoices() {
CommPortIdentifier portId;
Enumeration en = CommPortIdentifier.getPortIdentifiers();
// iterate through the ports.
while (en.hasMoreElements()) {
portId = (CommPortIdentifier) en.nextElement();
if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
System.out.println(portId.getName());
}
}
portChoice.select(parameters.getPortName());
}
以上代碼可以列舉出當前系統所有可用的串口名稱，我的機器上輸出的結果是COM1和COM3。
串口一般有如下參數可以在該串口打開以前配置進行配置：
包括波特率，輸入/輸出流控制，數據位數，停止位和齊偶校驗。
SerialPort sPort;
try {
sPort.setSerialPortParams(BaudRate,Databits,Stopbits,Parity);
//
設置輸入/輸出控制流
sPort.setFlowControlMode(FlowControlIn | FlowControlOut);
} catch (UnsupportedCommOperationException e) {}
對串口讀寫之前需要先打開一個串口：
CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(
PortName);
try {
SerialPort sPort = (SerialPort) portId.open("
串口所有者名稱", 超時等待時間);
} catch (PortInUseException e) {//
如果端口被占用就拋出這個異常
throw new SerialConnectionException(e.getMessage());
}
//用于對串口寫數據
OutputStream os = new BufferedOutputStream(sPort.getOutputStream());
os.write(int data);
//用于從串口讀數據
InputStream is = new BufferedInputStream(sPort.getInputStream());
int receivedData = is.read();
讀出來的是int型，你可以把它轉換成需要的其他類型。
這里要注意的是，由于Java語言沒有無符號類型，即所有的類型都是帶符號的，在由byte到int的時候應該尤其注意。因為如果byte的最高位是1，則轉成int類型時將用1來占位。這樣，原本是10000000的byte類型的數變成int型就成了1111111110000000，這是很嚴重的問題，應該注意避免。
終于嘮叨完我最討厭的基礎知識了，下面開始我們本次的重點--串口應用的研究。由于向串口寫數據很簡單，所以這里我們只關注于從串口讀數據的情況。通常，串口通信應用程序有兩種模式，一種是實現SerialPortEventListener接口，監聽各種串口事件并作相應處理；另一種就是建立一個獨立的接收線程專門負責數據的接收。由于這兩種方法在某些情況下存在很嚴重的問題（至于什么問題這里先賣個關子
J
），所以我的實現是采用第三種方法來解決這個問題。
現在我們來看看事件監聽模型是如何運作的
：
l
首先需要在你的端口控制類（例如SManager）加上“implements SerialPortEventListener”
l
在初始化時加入如下代碼：
try {
SerialPort sPort.addEventListener(SManager);
} catch (TooManyListenersException e) {
sPort.close();
throw new SerialConnectionException("too many listeners added");
}
sPort.notifyOnDataAvailable(true);
l
覆寫public void serialEvent(SerialPortEvent e)方法，在其中對如下事件進行判斷：
BI -通訊中斷.
CD -載波檢測.
CTS -清除發送.
DATA_AVAILABLE -有數據到達.
DSR -數據設備準備好.
FE -幀錯誤.
OE -溢位錯誤.
OUTPUT_BUFFER_EMPTY -輸出緩沖區已清空.
PE -奇偶校驗錯.
RI - 振鈴指示.
一般最常用的就是DATA_AVAILABLE--串口有數據到達事件。也就是說當串口有數據到達時，你可以在serialEvent中接收并處理所收到的數據。然而在我的實踐中，遇到了一個十分嚴重的問題。
首先描述一下我的實驗：我的應用程序需要接收傳感器節點從串口發回的查詢數據，并將結果以圖標的形式顯示出來。串口設定的波特率是115200，川口每隔128毫秒返回一組數據（大約是30字節左右），周期（即持續時間）為31秒。實測的時候在一個周期內應該返回4900多個字節，而用事件監聽模型我最多只能收到不到1500字節，不知道這些字節都跑哪里去了，也不清楚到底丟失的是那部分數據。值得注意的是，這是我將serialEvent()中所有處理代碼都注掉，只剩下打印代碼所得的結果。數據丟失的如此嚴重是我所不能忍受的，于是我決定采用其他方法。
這個模型顧名思義，就是將接收數據的操作寫成一個線程的形式:
public void startReadingDataThread() {
Thread readDataProcess = new Thread(new Runnable() {
public void run() {
while (newData != -1) {
try {
newData = is.read();
System.out.println(newData);
//
其他的處理過程
……….
} catch (IOException ex) {
System.err.println(ex);
return;
}
}
readDataProcess.start();
}
在我的應用程序中，我將收到的數據打包放到一個緩存中，然后啟動另一個線程從緩存中獲取并處理數據。兩個線程以生產者—消費者模式協同工作，數據的流向如下圖所示：
這樣，我就圓滿解決了丟數據問題。然而，沒高興多久我就又發現了一個同樣嚴重的問題：雖然這回不再丟數據了，可是原本一個周期（31秒）之后，傳感器節電已經停止傳送數據了，但我的串口線程依然在努力的執行讀串口操作，在控制臺也可以看見收到的數據仍在不斷的打印。原來，由于傳感器節點發送的數據過快，而我的接收線程處理不過來，所以InputStream就先把已到達卻還沒處理的字節緩存起來，于是就導致了明明傳感器節點已經不再發數據了，而控制臺卻還能看見數據不斷打印這一奇怪的現象。唯一值得慶幸的是最后收到數據確實是4900左右字節，沒出現丟失現象。然而當處理完最后一個數據的時候已經快1分半鐘了，這個時間遠遠大于節點運行周期。這一延遲對于一個實時的顯示系統來說簡直是災難！
后來我想，是不是由于兩個線程之間的同步和通信導致了數據接收緩慢呢？于是我在接收線程的代碼中去掉了所有處理代碼，僅保留打印收到數據的語句，結果依然如故。看來并不是線程間的通信阻礙了數據的接收速度，而是用線程模型導致了對于發送端數據發送速率過快的情況下的數據接收延遲。這里申明一點，就是對于數據發送速率不是如此快的情況下前面者兩種模型應該還是好用的，只是特殊情況還是應該特殊處理。
痛苦了許久（Boss天天催我
L
）之后，偶然的機會，我聽說TinyOS中（又是開源的）有一部分是和我的應用程序類似的串口通信部分，于是我下載了它的1.x版的Java代碼部分，參考了它的處理方法。解決問題的方法說穿了其實很簡單，就是從根源入手。根源不就是接收線程導致的嗎，那好，我就干脆取消接收線程和作為中介的共享緩存，而直接在處理線程中調用串口讀數據的方法來解決問題（什么，為什么不把處理線程也一并取消？----都取消應用程序界面不就鎖死了嗎？所以必須保留）于是程序變成了這樣：
public byte[] getPack(){
while (true) {
// PacketLength
為數據包長度
byte[] msgPack = new byte[PacketLength];
for(int i = 0; i < PacketLength; i++){
if( (newData = is.read()) != -1){
msgPack[i] = (byte) newData;
System.out.println(msgPack[i]);
}
}
return msgPack;
}
}
在處理線程中調用這個方法返回所需要的數據序列并處理之，這樣不但沒有丟失數據的現象行出現，也沒有數據接收延遲了。這里唯一需要注意的就是當串口停止發送數據或沒有數據的時候is.read()一直都返回-1，如果一旦在開始接收數據的時候發現-1就不要理它，繼續接收，直到收到真正的數據為止。
|
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
