RXTX虚拟串口读取问题

发布于 2024-09-09 06:24:39 字数 763 浏览 3 评论 0原文

背景:Windows Server 2003 R2,使用RealPort软件创建的Wire Service虚拟串口, 串口配置为 COM5,9600 波特率,8 个数据位,无奇偶校验位,1 个停止位,无流量控制, 使用 RXTX 2.1-7。

找到端口 COM5,使用 portId.open 方法创建串行端口,并设置端口参数和流量控制以匹配上面的设备驱动程序设置。 我获取了串行端口 IntupStream 并将其包装在 InputStreamReader 中,以便我可以控制输入编码。 默认编码当然是Cp1252 我读到,如果您使用 8 个数据位,则编码应该是 ISO-8859-1 又名 Latin1。 并使用 InputStreamReader 方法: int c = isr.read(); 在 SerialPort.Event.DATA_AVAILABLE 的情况下,在 while 循环中 打印出整数 c 并将其转换为字符 ((char)c); 问题是数字和结果字符移动得太高(范围是 135 - 250) 这些消息均以“保留所有权利。)”结尾,并且每条消息中的最后一个字符都是相同的。 然而,角色之间的转变并不一致。 尝试过其他编码: UTF8/UTF-8 使数字变得更高。 ascii/us-ascii 也是如此。 cp1252 将数字移至 130 - 350 范围,但 3 个字符除外(移至 65533、8222 和 8240)。 注意:使用InputStreamReader.getEncoding() UTF8和UTF-8是UTF8,ascii和us-ascii是ASCII。

我还应该尝试其他编码吗?还有其他人见过这种事情吗?

Background: Windows Server 2003 R2,Wire Service virtual serial port created with RealPort software,
Serial Port configured as COM5, 9600 baud,8 data bits, no parity bits, 1 stop bit, no flow control,
Using RXTX 2.1-7.

The port COM5 is found, the serial port is created using the portId.open method and port parameters and flow control are set to match the device driver settings above.
I get the serialPort IntupStream and wrap it in an InputStreamReader so I can control the input encoding.
The default encoding is of course Cp1252
I've read that if you are using 8 data bits the encoding should be ISO-8859-1 aka Latin1.
and am using the InputStreamReader method:
int c = isr.read();
in a while loop in the case SerialPort.Event.DATA_AVAILABLE
Printing out the integer c and it's cast to a character ((char)c);
The problem is that the numbers and resulting characters are shifted too high (range is 135 - 250)
The messages all end with "All Rights Reserved.)" and the last characters in each message are the same.
However, the shift is not consistent from character to character.
Have tried other encodings:
UTF8/UTF-8 shift the numbers even higher. as does ascii/us-ascii.
Cp1252 shifts the numbers to the 130 - 350 range except for 3 characters which are shifted to 65533, 8222 and 8240.
Note: using the InputStreamReader.getEncoding() UTF8 and UTF-8 are UTF8 and ascii and us-ascii are ASCII.

Are there other encodings I should try? Anyone else seen this sort of thing?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

夏雨凉 2024-09-16 06:24:39

我正在做几乎完全相同的事情。 9600 波特率、8N1(8 个数据位、无奇偶校验、1 个停止位)并且字符移位没有问题。我们甚至没有在任何地方设置编码。

我们的输入流只是 InputStream 类型,并使用serialPort.getInputStream()设置;

尝试从 InputStreamReader 退一步,只使用普通的“InputStream”。编码应该自行处理。

希望能有所帮助,

--gMale

I'm doing almost the exact same thing. 9600 baud, 8N1 (8 data bits, no parity, 1 stop bit) and we have no issues with character shifting. We don't even set the encoding, anywhere.

Our input stream is simply of type InputStream and it's set with serialPort.getInputStream();

Try stepping back from InputStreamReader and just using a plain "InputStream." The encoding should take care of itself.

Hope that helps in some way,

--gMale

永不分离 2024-09-16 06:24:39

有两个有线服务端口。我发布的一篇文章被证明是 TCP 到串行设备(称为 Digi)中的硬件配置之间的冲突。通过将 COM5 串行设置更改为 9600,7,1,0,0,我能够解决该端口上的问题。值的移动是由于使用 8 个数据位与 7 个数据位造成的。这当然意味着我必须更改代码中的端口参数以匹配。您的正确之处在于,阅读器是不必要的,但是它确实帮助我通过观察编码的移位变化来找到解决方案,直到我意识到更少的数据位也会产生相同的效果。

现在我正在寻找第二个端口的魔力。

第二个端口设置为 1200,8,1,0,0,使用 9600 导致流大部分为 0,其中有一些 128。

Have two of the wire service ports. I one I posted about turned out to be a conflict between the hardware configuration in the TCP to Serial device called a Digi. I was able to remedy the problem on that port by changing the COM5 serial settings to 9600,7,1,0,0. The shifting of values was due to using 8 data bits vs 7. This of course meant that I had to change the port params in the code to match. Your correct in that the Reader was unnecessary, however it did help me arrive at the solution by watching the shift change with encoding, till it dawned on me that fewer data bits would also have the same effect.

Now I'm looking for the magic on the second port.

The second port settings were 1200,8,1,0,0 using 9600 caused the stream to be mostly 0s with some 128s.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文