简单介绍Java的串口通信（下）-java串口通信

串行接口是一种可以将接受来自CPU的并行数据字符转换为连续的串行数据流发送出去，同时可将接受的串行数据流转换为并行的数据字符供给CPU的器件。简单介绍Java的串口通信。接上一篇>>

3.1 事件监听模型

现在我们来看看事件监听模型是如何运作的：

首先需要在你的端口控制类(例如SManager)加上“implements SerialPortEventListener”

在初始化时加入如下代码：

try {  
SerialPort sPort.addEventListener(SManager);  
} catch (TooManyListenersException e) {  
sPort.close();  
throw new SerialConnectionException("too many listeners added");  
}  
sPort.notifyOnDataAvailable(true);

覆写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()中所有处理代码都注掉，只剩下打印代码所得的结果。数据丢失的如此严重是我所不能忍受的，于是我决定采用其他方法。

3.2 串口读数据的线程模型

这个模型顾名思义，就是将接收数据的操作写成一个线程的形式:

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分半钟了，这个时间远远大于节点运行周期。这一延迟对于一个实时的显示系统来说简直是灾难!

后来我想，是不是由于两个线程之间的同步和通信导致了数据接收缓慢呢?于是我在接收线程的代码中去掉了所有处理代码，仅保留打印收到数据的语句，结果依然如故。看来并不是线程间的通信阻碍了数据的接收速度，而是用线程模型导致了对于发送端数据发送速率过快的情况下的数据接收延迟。这里申明一点，就是对于数据发送速率不是如此快的情况下前面者两种模型应该还是好用的，只是特殊情况还是应该特殊处理。

3.3 第三种方法

痛苦了许久(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就不要理它，继续接收，直到收到真正的数据为止。

4 结束语

本文介绍了串口通信的基本知识，以及常用的几种模式。通过实践，提出了一些问题，并在最后加以解决。值得注意的是对于第一种方法，我曾将传感器发送的时间由128毫秒增加到512毫秒，仍然有很严重的数据丢失现象发生，所以如果你的应用程序需要很精密的结果，传输数据的速率又很快的话，就最好不要用第一种方法。

对于第二种方法，由于是线程导致的问题，所以对于不同的机器应该会有不同的表现，对于那些处理多线程比较好的机器来说，应该会好一些。但是我的机器是Inter 奔四3.0双核CPU+512DDR内存，这样都延迟这么厉害，还得多强的CPU才行啊?

所以对于数据量比较大的传输来说，还是用第三种方法吧。不过这个世界问题是很多的，而且未知的问题比已知的问题多的多，说不定还有什么其他问题存在，欢迎你通过下面的联系方式和我一起研究。