序言
说到开源，恐怕非常少有人不挑大指称赞。学生通过开源码学到了知识，程序猿通过开源类库获得了别人的成功经验及可以按时完毕手头的project，商家通过开源软件赚到了钱……，总之是皆大欢喜。然而开源软件或类库的首要缺点就是大多缺乏具体的说明文档和使用的样例，或者就是软件代码随便你用，就是文档，样例和后期服务收钱。这也难怪，毕竟就像某个著名NBA球员说的那样：“我还要养家，所以千万美元下面的合同别找我谈，否则我宁可待业”。是啊，支持开源的人也要养家，收点钱也只是分。要想既不花钱又学到知识就仅仅能借助网络和了，我仅仅是想抛砖引玉，为开源事业做出点微薄共献，能为你的project解决哪怕一个小问题，也就足够了。
尽管我的这个系列介绍的东西不是什么Web框架，也不是什么开源server，可是我相信，作为一个程序猿，什么样的问题都会遇到。有时候越是简单的问题反而越棘手；越是小的地方就越是找不到称手的家伙。仅仅要你不是整天仅仅与“架构”、“构件”、“框架”打交道的话，相信我所说的东西你一定会用到。
2.2 javax.comm.CommPortIdentifier3
嵌入式系统或传感器网络的非常多应用和測试都须要通过PC机与嵌入式设备或传感器节点进行通信。当中，最经常使用的接口就是RS-232串口和并口（鉴于USB接口的复杂性以及不须要非常大的传输数据量，USB接口用在这里还是显得过于奢侈，况且眼下除了SUN有一个支持USB的包之外，我还没有看到其它直接支持USB的Java类库）。SUN的CommAPI分别提供了对经常使用的RS232串行port和IEEE1284并行port通讯的支持。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对应文件夹下，所以应用程序将会提示找不到串口。解决问题的方法非常easy，我们仅仅须将上面提到的文件放到JRE对应的文件夹下就能够了。
值得注意的是，在网络应用程序中使用串口API的时候，还会遇到其它更复杂问题。有兴趣的话，你能够查看CSDN社区中“关于网页上Applet用javacomm20读取client串口的问题”的帖子。
2 串口API概览
这是用于描写叙述一个被底层系统支持的port的抽象类。它包括一些高层的IO控制方法，这些方法对于全部不同的通讯port来说是通用的。SerialPort 和ParallelPort都是它的子类，前者用于控制串行port而后者用于控这并口，二者对于各自底层的物理port都有不同的控制方法。这里我们仅仅关心SerialPort。
2.2 javax.comm.CommPortIdentifier
这个类主要用于对串口进行管理和设置，是对串口进行訪问控制的核心类。主要包含下面方法
l 确定是否有可用的通信port
l 为IO操作打开通信port
l 决定port的全部权
l 处理port全部权的争用
l 管理port全部权变化引发的事件（Event）
这个类用于描写叙述一个RS-232串行通信port的底层接口，它定义了串口通信所需的最小功能集。通过它，用户能够直接对串口进行读、写及设置工作。
大段的文字怎么也不如一个小样例来的清晰，以下我们就一起看一下串口包自带的样例---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) {//假设port被占用就抛出这个异常
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，这是非常严重的问题，应该注意避免。
最终唠叨完我最讨厌的基础知识了，以下開始我们本次的重点--串口应用的研究。因为向串口写数据非常easy，所以这里我们仅仅关注于从串口读数据的情况。通常，串口通信应用程序有两种模式，一种是实现SerialPortEventListener接口，监听各种串口事件并作对应处理；还有一种就是建立一个独立的接收线程专门负责数据的接收。因为这两种方法在某些情况下存在非常严重的问题（至于什么问题这里先卖个关子J），所以我的实现是採用第三种方法来解决问题。
如今我们来看看事件监听模型是怎样运作的
：
l 首先须要在你的port控制类（比如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代码部分，參考了它的处理方法。解决这个问题的方法说穿了事实上非常easy，就是从根源入手。根源不就是接收线程导致的吗，那好，我就干脆取消接收线程和作为中介的共享缓存，而直接在处理线程中调用串口读数据的方法来解决这个问题（什么，为什么不把处理线程也一并取消？----都取消应用程序界面不就锁死了吗？所以必须保留）于是程序变成了这样：
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就不要理它，继续接收，直到收到真正的数据为止。
本文介绍了串口通信的基本知识，以及经常使用的几种模式。通过实践，提出了一些问题，并在最后加以解决。值得注意的是对于第一种方法，我曾将传感器发送的时间由128毫秒添加?到512毫秒，仍然有非常严重的数据丢失现象发生，所以假设你的应用程序须要非常精密的结果，数据传输的速率又非常快的话，就最好不要用第一种方法。对于另外一种方法，因为是线程导致的问题，所以对于不同的机器应该会有不同的表现，对于那些处理多线程比較好的机器来说，应该会好一些。可是我的机器是Inter 奔四3.0双核CPU+512DDR内存，这样都延迟这么厉害，还得多强的CPU才行啊？所以对于数据量比較大的传输来说，还是用第三种方法吧。只是这个世界问题是非常多的，并且未知的问题比已知的问题多的多，说不定还有什么其它问题存在，欢迎你通过以下的联系方式和我一起研究。