是否有通过串行端口传递部件号的约定？
我有一些设备可以读取 RFID 标签并通过串行端口传递标签的序列号。
在我看来，对序列号的每个数字使用两个字节“更好”，特别是因为某些设备正在发送终止 0x0D 0xA (CR/LF)。
现在我发现一个设备每个数字使用一个字节，因此要发送“12”，它不会发送 0x31、0x32，而是发送 0x12。这意味着我无法区分 CR/LF 和真正的 0xA 和 0xD。我问了一些关于它的胡言乱语，因为字符串是固定长度的，所以为什么要为 CR LF 烦恼呢？而且，为了保持一致，它们每个使用两个字节来表示 CR/LF。
正如您可能已经了解到的那样，我对这个项目相当陌生，并且对不同制造商的设备之间的不一致感到有些困惑。
该产品的制造商很乐意更改其固件以适应我的需求。我应该要求他们为每个数字使用两个字节吗？
I have some devices which read an RFID tage and pass the serial number of the tag over the serial port.
It seems to me that it is "better" to use two bytes for each digit of the serial number, especially since some devices are sending a terminating 0x0D 0xA (CR/LF).
Now I find one device which is using one byte per digit, so to send "12" it does not send 0x31, 0x32, but rather 0x12. Which means that I can't distinguish between CR/LF and a real 0xA and 0xD. I ask and get some waffle about it not mattering as the strings are fixed length - so why bother with CR LF? And, just to be (in)consistent, they use two bytes each for CR/LF.
As you may have gathered, I am fairly new to this project and somewhat confused by the inconsistencies between different manufacturers' devices.
The manufacturer of this one is happy to change their firmware to accommodate me. Should I ask them to use two bytes for each digit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
串行似乎从未成为标准。它的传输方式是一个标准，但发送的内容始终取决于硬件/软件的开发人员。大多数设备都有某种信息包。通常是这样的 STARTBYTE、DATA、CHECKSUM 和 sumtimes ~CHECKSUM（校验和的倒数），也许还有 STOPBYTE。校验和可帮助您确保数据有效，但仅发送几个字节，因此很难进行校验和。
来回答你的问题。确保尽可能准确的数据是一个绝妙的主意。这意味着您甚至不希望将 CR/LF 与您的标签 ID 混淆。您可以以编程方式确保它不是同时 CR 和 LF - 那么它是一个有效的 ID，或者请求他们更改固件。似乎大多数公司都喜欢以纯文本形式发送串行数据。我不喜欢这样做，因为它体积庞大，而且坦率地说浪费性能（如果您需要流程速度）。对我来说，读取数据包的每个字节并进行相应的解释会更容易。你甚至可以要求他们做这样的事情。 0xFF 0x00 数据0 数据1 0xFF。这使用 2 个起始字节和一个停止字节。它会发送更多的数据，但有助于确保您获得有效的数据。在您的代码中，您可以在末尾检查 0xFF 0x00 和 0xFF。如果您没有收到该信息，则说明您的数据包无效。
如果你不想使用数据包，你总是可以一起检查 CR/LF，我希望构建 RFID 标签的公司不会使用 CR/LF 作为他们的 ID。
如果您觉得想要更清晰并且不想更改任何内容，我建议您与制造商联系并索取一些示例接口代码，或获取有关确保数据准确的最佳方法的建议。他们应该适应，因为您是客户。
如果您需要任何进一步的帮助，请告诉我。
Serial is a thing that never seemed to become standard. The way it transmits is a standard but what is sent is always up to the developers of the hardware/software. Most devices have some sort of packet of information. Usually goes something like this STARTBYTE, DATA, CHECKSUM and sumtimes ~CHECKSUM (the inverse of the checksum) and maybe a STOPBYTE. A checksum helps you ensure your data is valid, but with only a couple of bytes being sent its hard to do a checksum.
To answer your question. It is a fantastic idea to ensure the most accurate data possible. This means you don't want to even be able to confuse CR/LF with your tag id. You can either make sure its not both CR and LF programmatically - then its a valid id, or request they change the firmware. It seems that most companies like to send serial data as plain text. I do not prefer this as it is bulky and frankly a waste of performance (if you need speed in your process). For me it is easier to read each byte of the packet and interpret accordingly. You might even ask them to do something like this. 0xFF 0x00 DATA0 DATA1 0xFF . this uses 2 start bytes and a stop byte. It sends a little more data, but helps to ensure you are getting valid data. In your code you could check for 0xFF 0x00 and 0xFF at the end. If you do not get that, you are not on a valid packet.
If you don't want to use packets, you could always just check for the CR/LF together, I am hoping the companies that build the RFID tags would not use CR/LF as their id on one.
If you feel you want more clarity and don't want to change anything, I recommend talking to the manufacturer and asking for some example interface code, or advice on the best way to ensure accurate data. They should accommodate as you are the customer.
If you need any further assistance please let me know.
始终包含一个字节来指示消息的长度 - 要么是整个消息，要么只是数据区域。它只花费一个字节（假设消息长度小于 256 字节），并且使解析消息变得更加容易。
Always include a byte that indicates how long the message is - either the entire message, or just the data area. It only costs one byte (assuming messages < 256 bytes long), and makes parsing the message much easier.