嵌入式系統或感測器網路的很多應用和測試都需要通過PC機與嵌入式設備或感測器節點進行通信 其中 最常用的介面就是RS 串口和並口(鑒於USB介面的復雜性以及不需要很大的數據傳輸量 USB介面用在這里還是顯得過於奢侈 況且目前除了SUN有一個支持USB的包之外 我還沒有看到其他直接支持USB的Java類庫) SUN的CommAPI分別提供了對常用的RS 串列埠和IEEE 並行埠通訊的支持 RS C(又稱EIA RS C 以下簡稱RS )是在 年由美國電子工業協會(EIA)聯合貝爾系統 數據機廠家及計算機終端生產廠家共同制定的用於串列通訊的標准 RS 是一個全雙工的通訊協議 它可以同時進行數據接收和發送的工作
常見的Java串口包
目前 常見的Java串口包有SUN在 年發布的串口通信API m jar(Windows下) m jar(linux/Solaris);IBM的串口通信API以及一個開源的實現 鑒於在Windows下SUN的API比較常用以及IBM的實現和SUN的在API層面都是一樣的 那個開源的實現又不像兩家大廠的產品那樣讓人放心 這里就只介紹SUN的串口通信API在Windows平台下的使用
串口包的安裝(Windows下)
到SUN的網站下載javam win zip 包含的東西如下所示
按照其使用說明(l)的說法 要想使用串口包進行串口通信 除了設置好環境變數之外 還要將win dll復制到 in目錄下;將m jar復制到 lib;把m properties也同樣拷貝到 lib目錄下 然而在真正運行使用串口包的時候 僅作這些是不夠的 因為通常當運行 java MyApp 的時候 是由JRE下的虛擬機啟動MyApp的 而我們只復制上述文件到JDK相應目錄下 所以應用程序將會提示找不到串口 解決這個問題的方法很簡單 我們只須將上面提到的文件放到JRE相應的目錄下就可以了
值得注意的是 在網路應用程序中使用串口API的時候 還會遇到其他更復雜問題 有興趣的話 你可以查看CSDN社區中 關於網頁上Applet用javam 讀取客戶端串口的問題 的帖子
串口API概覽
m CommPort
這是用於描述一個被底層系統支持的埠的抽象類 它包含一些高層的IO控制方法 這些方法對於所有不同的通訊埠來說是通用的 SerialPort 和ParallelPort都是它的子類 前者用於控制串列埠而後者用於控這並口 二者對於各自底層的物理埠都有不同的控制方法 這里我們只關心SerialPort
m CommPortIdentifier
這個類主要用於對串口進行管理和設置 是對串口進行訪問控制的核心類 主要包括以下方法
l 確定是否有可用的通信埠
l 為IO操作打開通信埠
l 決定埠的所有權
l 處理埠所有權的爭用
l 管理埠所有權變化引發的事件(Event)
m SerialPort
這個類用於描述一個RS 串列通信埠的底層介面 它定義了串口通信所需的最小功能集 通過它 用戶可以直接對串口進行讀 寫及設置工作
串口API實例
大段的文字怎麼也不如一個小例子來的清晰 下面我們就一起看一下串口包自帶的例子 SerialDemo中的一小段代碼來加深對串口API核心類的使用方法的認識
列舉出本機所有可用串口
voidlistPortChoices(){ CommPortIdentifierportId; Enumerationen=CommPortIdentifier getPortIdentifiers(); //iteratethroughtheports while(en hasMoreElements()){ portId=(CommPortIdentifier)en nextElement(); if(portId getPortType()==CommPortIdentifier PORT_SERIAL){ System out println(portId getName()); } } portChoice select(parameters getPortName()); }
以上代碼可以列舉出當前系統所有可用的串口名稱 我的機器上輸出的結果是 和
串口參數的配置
串口一般有如下參數可以在該串口打開以前配置進行配置
包括波特率 輸入/輸出流控制 數據位數 停止位和齊偶校驗
SerialPortsPort; try{ sPort setSerialPortParams(BaudRate Databits Stopbits Parity); //設置輸入/輸出控制流 sPort setFlowControlMode(FlowControlIn|FlowControlOut); }catch(){}
串口的讀寫
對串口讀寫之前需要先打開一個串口
CommPortIdentifierportId=CommPortIdentifier getPortIdentifier(PortName); try{ SerialPortsPort=(SerialPort)portId open( 串口所有者名稱 超時等待時間); }catch(PortInUseExceptione){//如果埠被佔用就拋出這個異常 (e getMessage()); } //用於對串口寫數據 OutputStreamos=newBufferedOutputStream(sPort getOutputStream()); os write(intdata); //用於從串口讀數據 InputStreamis=newBufferedInputStream(sPort getInputStream()); intreceivedData=is read();
讀出來的是int型 你可以把它轉換成需要的其他類型
這里要注意的是 由於Java語言沒有無符號類型 即所有的類型都是帶符號的 在由byte到int的時候應該尤其注意 因為如果byte的最高位是 則轉成int類型時將用 來佔位 這樣 原本是 的byte類型的數變成int型就成了 這是很嚴重的問題 應該注意避免
串口通信的通用模式及其問題
終於嘮叨完我最討厭的基礎知識了 下面開始我們本次的重點 串口應用的研究 由於向串口寫數據很簡單 所以這里我們只關注於從串口讀數據的情況 通常 串口通信應用程序有兩種模式 一種是實現SerialPortEventListener介面 監聽各種串口事件並作相應處理;另一種就是建立一個獨立的接收線程專門負責數據的接收 由於這兩種方法在某些情況下存在很嚴重的問題(至於什麼問題這里先賣個關子J) 所以我的實現是採用第三種方法來解決這個問題
事件監聽模型
現在我們來看看事件監聽模型是如何運作的
l 首先需要在你的埠控制類(例如SManager)加上 implements SerialPortEventListener
l 在初始化時加入如下代碼
try{ SerialPortsPort addEventListener(SManager); }catch(TooManyListenersExceptione){ sPort close(); ( toomanylistenersadded ); } 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中接收並處理所收到的數據 然而在我的實踐中 遇到了一個十分嚴重的問題
首先描述一下我的實驗 我的應用程序需要接收感測器節點從串口發回的查詢數據 並將結果以圖標的形式顯示出來 串口設定的波特率是 川口每隔 毫秒返回一組數據(大約是 位元組左右) 周期(即持續時間)為 秒 實測的時候在一個周期內應該返回 多個位元組 而用事件監聽模型我最多隻能收到不到 位元組 不知道這些位元組都跑哪裡去了 也不清楚到底丟失的是那部分數據 值得注意的是 這是我將serialEvent()中所有處理代碼都注掉 只剩下列印代碼所得的結果 數據丟失的如此嚴重是我所不能忍受的 於是我決定採用其他方法
串口讀數據的線程模型
這個模型顧名思義 就是將接收數據的操作寫成一個線程的形式:
(){ ThreadreadDataProcess=newThread(newRunnable(){ publicvoidrun(){ while(newData!= ){ try{ newData=is read(); System out println(newData); //其他的處理過程 ……… }catch(IOExceptionex){ System err println(ex); return; } } readDataProcess start(); }
在我的應用程序中 我將收到的數據打包放到一個緩存中 然後啟動另一個線程從緩存中獲取並處理數據 兩個線程以生產者—消費者模式協同工作 數據的流向如下圖所示
這樣 我就圓滿解決了丟數據問題 然而 沒高興多久我就又發現了一個同樣嚴重的問題 雖然這回不再丟數據了 可是原本一個周期( 秒)之後 感測器節電已經停止傳送數據了 但我的串口線程依然在努力的執行讀串口操作 在控制台也可以看見收到的數據仍在不斷的列印 原來 由於感測器節點發送的數據過快 而我的接收線程處理不過來 所以InputStream就先把已到達卻還沒處理的位元組緩存起來 於是就導致了明明感測器節點已經不再發數據了 而控制台卻還能看見數據不斷列印這一奇怪的現象 唯一值得慶幸的是最後收到數據確實是 左右位元組 沒出現丟失現象 然而當處理完最後一個數據的時候已經快 分半鍾了 這個時間遠遠大於節點運行周期 這一延遲對於一個實時的顯示系統來說簡直是災難!
後來我想 是不是由於兩個線程之間的同步和通信導致了數據接收緩慢呢?於是我在接收線程的代碼中去掉了所有處理代碼 僅保留列印收到數據的語句 結果依然如故 看來並不是線程間的通信阻礙了數據的接收速度 而是用線程模型導致了對於發送端數據發送速率過快的情況下的數據接收延遲 這里申明一點 就是對於數據發送速率不是如此快的情況下前面者兩種模型應該還是好用的 只是特殊情況還是應該特殊處理
第三種方法
痛苦了許久(Boss天天催我L)之後 偶然的機會 我聽說TinyOS中(又是開源的)有一部分是和我的應用程序類似的串口通信部分 於是我下載了它的 x版的Java代碼部分 參考了它的處理方法 解決問題的方法說穿了其實很簡單 就是從根源入手 根源不就是接收線程導致的嗎 那好 我就乾脆取消接收線程和作為中介的共享緩存 而直接在處理線程中調用串口讀數據的方法來解決問題(什麼 為什麼不把處理線程也一並取消? 都取消應用程序界面不就鎖死了嗎?所以必須保留)於是程序變成了這樣
publicbyte[]getPack(){ while(true){ //PacketLength為數據包長度 byte[]msgPack=newbyte[PacketLength]; for(inti= ;i<PacketLength;i++){ if((newData=is read())!= ){ msgPack[i]=(byte)newData; System out println(msgPack[i]); } } returnmsgPack; } }
在處理線程中調用這個方法返回所需要的數據序列並處理之 這樣不但沒有丟失數據的現象行出現 也沒有數據接收延遲了 這里唯一需要注意的就是當串口停止發送數據或沒有數據的時候is read()一直都返回 如果一旦在開始接收數據的時候發現 就不要理它 繼續接收 直到收到真正的數據為止
結束語
lishixin/Article/program/Java/hx/201311/26605
❷ golang 有什麼比較好得分布式任務隊列，類似Python的celery
https://github.com/bitly/nsq
NSQ is a realtime distributed messaging platform designed to operate at scale, handling
billions of messages per day.
It promotes distributed and decentralized topologies without single points of failure,
enabling fault tolerance and high availability coupled with a reliable message delivery
guarantee. See features & guarantees.
Operationally, NSQ is easy to configure and deploy (all parameters are specified on the command
line and compiled binaries have no runtime dependencies). For maximum flexibility, it is agnostic to
data format (messages can be JSON, MsgPack, Protocol Buffers, or anything else). Official Go and
Python libraries are available out of the box (as well as many other client
libraries) and, if you're interested in building your own, there's a protocol
spec.
We publish binary releases for linux and darwin.
NOTE: master is our development branch and may not be stable at all times.