使用jssc的串口通信延迟
Delay in serial communication using jssc
我正在使用jssc
与我制作的模拟器进行串口通信。问题是,每当服务器从我的模拟器请求设备时,我都会遇到延迟,因为我的模拟器中的设备会在一段时间后回复,而不是在请求之后回复。为了回复请求数据包,我在串行事件侦听器中使用 jssc
方法 writeBytes()
,即:
SerialPort.writeBytes(packet);
并且数据包小于 20 个字节,而且我正在检查我的串行事件
if(event.isRXCHAR() && event.getEventValue() > 0){}
你们能帮我减少这个延迟,让模拟器设备在请求后立即回复吗?这是一段代码-
public void serialEvent(SerialPortEvent event)
{
if(event.isRXCHAR() && event.getEventValue() > 0)
{
byte Server_PacketByte;
try {
Server_PacketByte = receiver_Port.readBytes(1)[0];
byte[] form_packet = PacketFormation(Server_PacketByte);// for adding bytes to make packet
if(form_packet == null)
{
return;
}
for(Device d : devices)
{
if(form_packet != null)
{
d.processPacket(form_packet);// in the list of devices I have all the information of device and also reply packet
}
}
} catch (Exception e1) {
e1.printStackTrace();
}
}
}
在 processPacket() 内部
if (packet.equals(REQUEST))
{
receiver_Port.writeBytes(device.getReply());
}
因此,我认为您的系统出现的问题是从您的模拟器返回服务器的响应花费的时间太长,或者服务器请求靠得太近以至于无法使用。如果您的模拟器对服务器的响应花费的时间太长,那么它可能会忽略或忽略您服务器的后续请求,并且您的服务器可能会通过忽略响应(因为它是针对它已经放弃的请求)来处理这个问题,或者更糟的是,认为对请求 #1 的响应是对请求 #3 的响应(可能有不同的参数,因此无效)。
对此的解决方案是让服务器在尝试另一个请求之前等待更长的响应时间,或者以某种方式减少模拟器响应服务器请求所需的时间。
如果您只是对设备执行 "is device connected" 或 "get device info" 式请求,或者不需要实时响应的请求,您可以让模拟器在它自己的(通过单独线程上的请求循环或其他东西)并缓存响应,并在服务器请求时将其返回。但是,您必须确保它在实时请求通过时被中止,因此它几乎比必要的更复杂。
编辑:澄清一下,我不认为是您的串行通信出现了不当延迟,因为串行通信很慢.我认为您在设计中没有考虑到这一事实,并且您期望您的潜在大量设备的所有通信都能在特定时间范围内完成。此外,每个设备可能需要不同的时间来通过串行方式返回响应;其中一些甚至可能没有正确实施流量控制,导致偶尔出现延迟,或者在极少数情况下导致交付失败。
您的模拟器中应该有一些其他线程定期从设备请求更新并将它们存储在 table 中。这样,当服务器发出询问所有设备的请求时,它们的信息已经存在,并且可以打包并传送回服务器,而无需串行通信。
我正在使用jssc
与我制作的模拟器进行串口通信。问题是,每当服务器从我的模拟器请求设备时,我都会遇到延迟,因为我的模拟器中的设备会在一段时间后回复,而不是在请求之后回复。为了回复请求数据包,我在串行事件侦听器中使用 jssc
方法 writeBytes()
,即:
SerialPort.writeBytes(packet);
并且数据包小于 20 个字节,而且我正在检查我的串行事件
if(event.isRXCHAR() && event.getEventValue() > 0){}
你们能帮我减少这个延迟,让模拟器设备在请求后立即回复吗?这是一段代码-
public void serialEvent(SerialPortEvent event)
{
if(event.isRXCHAR() && event.getEventValue() > 0)
{
byte Server_PacketByte;
try {
Server_PacketByte = receiver_Port.readBytes(1)[0];
byte[] form_packet = PacketFormation(Server_PacketByte);// for adding bytes to make packet
if(form_packet == null)
{
return;
}
for(Device d : devices)
{
if(form_packet != null)
{
d.processPacket(form_packet);// in the list of devices I have all the information of device and also reply packet
}
}
} catch (Exception e1) {
e1.printStackTrace();
}
}
}
在 processPacket() 内部
if (packet.equals(REQUEST))
{
receiver_Port.writeBytes(device.getReply());
}
因此,我认为您的系统出现的问题是从您的模拟器返回服务器的响应花费的时间太长,或者服务器请求靠得太近以至于无法使用。如果您的模拟器对服务器的响应花费的时间太长,那么它可能会忽略或忽略您服务器的后续请求,并且您的服务器可能会通过忽略响应(因为它是针对它已经放弃的请求)来处理这个问题,或者更糟的是,认为对请求 #1 的响应是对请求 #3 的响应(可能有不同的参数,因此无效)。
对此的解决方案是让服务器在尝试另一个请求之前等待更长的响应时间,或者以某种方式减少模拟器响应服务器请求所需的时间。
如果您只是对设备执行 "is device connected" 或 "get device info" 式请求,或者不需要实时响应的请求,您可以让模拟器在它自己的(通过单独线程上的请求循环或其他东西)并缓存响应,并在服务器请求时将其返回。但是,您必须确保它在实时请求通过时被中止,因此它几乎比必要的更复杂。
编辑:澄清一下,我不认为是您的串行通信出现了不当延迟,因为串行通信很慢.我认为您在设计中没有考虑到这一事实,并且您期望您的潜在大量设备的所有通信都能在特定时间范围内完成。此外,每个设备可能需要不同的时间来通过串行方式返回响应;其中一些甚至可能没有正确实施流量控制,导致偶尔出现延迟,或者在极少数情况下导致交付失败。
您的模拟器中应该有一些其他线程定期从设备请求更新并将它们存储在 table 中。这样,当服务器发出询问所有设备的请求时,它们的信息已经存在,并且可以打包并传送回服务器,而无需串行通信。