Arduino以太网字节大小问题

发布于 2024-10-10 23:14:04 字数 741 浏览 6 评论 0原文

我使用带有官方以太网扩展板的 Arduino (duemilanove) 将数据发送到控制器以控制 LED 矩阵。我试图通过获取桌面上 32 位值中的 4 个字节并将其作为 4 个连续字节发送到 arduino 来将一些原始 32 位无符号 int 值(unix 时间戳)发送到控制器。但是,每当字节值大于 127 时,以太网客户端库返回的值为 63。

以下是我在 arduino 方面所做的基本示例。为了整洁起见,有些东西已被删除。

byte buffer[32];
memset(buffer, 0, 32);

int data;
int i=0;

data = client.read();
while(data != -1 && i < 32)
{
  buffer[i++] = (byte)data;
  data = client.read();
}

因此,每当输入字节大于 127 时,变量“data”最终将被设置为 63!起初我认为问题出在更远的地方(缓冲区过去是字符而不是字节),但是当我在读取后立即打印出“数据”时,它仍然是 63。

有什么想法可能导致此问题吗?我知道 client.read() 应该输出 int 并在内部从套接字读取数据作为 uint8_t 这是一个完整的字节且无符号,所以我应该至少能够转到 255...

编辑: 你说得对,汉斯。没有意识到 Encoding.ASCII.GetBytes 仅支持前 7 位,而不支持全部 8 位。

I'm using an Arduino (duemilanove) with the official Ethernet shield to send data to the controller for controlling an LED matrix. I am trying to send some raw 32-bit unsigned int values (unix timestamps) to the controller by taking the 4 bytes in the 32-bit value on the desktop and sending it to the arduino as 4 consecutive bytes. However, whenever a byte value is larger than 127, the returned value by the ethernet client library is 63.

The following is a basic example of what I'm doing on the arduino side of things. Some things have been removed for neatness.

byte buffer[32];
memset(buffer, 0, 32);

int data;
int i=0;

data = client.read();
while(data != -1 && i < 32)
{
  buffer[i++] = (byte)data;
  data = client.read();
}

So, whenever the input byte is bigger than 127 the variable "data" will end up getting set to 63! At first I thought the problem was further down the line (buffer used to be char instead of byte) but when I print out "data" right after the read, it's still 63.

Any ideas what could be causing this? I know client.read() is supposed to output int and internally reads data from the socket as uint8_t which is a full byte and unsigned, so I should be able to at least go to 255...

EDIT: Right you are, Hans. Didn't realize that Encoding.ASCII.GetBytes only supported the first 7 bits and not all 8.

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

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

发布评论

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

评论(3

口干舌燥 2024-10-17 23:14:04

我更倾向于怀疑发射端。您确定发送端工作正常吗?您是否使用wireshark捕获或类似工具进行了验证?

I'm more inclined to suspect the transmit side. Are you positive the transmit side is working correctly? Have you verified with a wireshark capture or some such?

北恋 2024-10-17 23:14:04

63 是 ? 的 ASCII 代码。与这些值有一些相关性,ASCII 没有超过 127 的值的字符代码。ASCII 编码器通常用问号替换这样的无效代码。例如,.NET Encoding.ASCII 编码器的默认行为。

目前还不清楚这种情况可能发生在哪里。绝对不在你的片段中。可能在电线的另一端。写入字节,而不是字符。

63 is the ASCII code for ?. There's some relevance to the values, ASCII doesn't have character codes for values over 127. An ASCII encoder commonly replaces invalid codes like this with a question mark. Default behavior for the .NET Encoding.ASCII encoder for example.

It isn't exactly clear where that might happen. Definitely not in your snippet. Probably on the other end of the wire. Write bytes, not characters.

回眸一笑 2024-10-17 23:14:04

汉斯·帕桑特和卡尔·比勒费尔特+1。

可以不编码直接发送数据吗?数据是如何发送的? TCP/UDP/IP/Ethernet绝对支持无限制地发送二进制数据。如果这是不可能的,也许将数据转换为十六进制可以解决问题。 Base64 也可以工作(更好),但工作量要大得多。对于少量数据,十六进制可能是最简单、最快的解决方案。

再次感谢 Karl 和 Ben 提到wireshark。对于调试此类网络问题非常有用。

+1 for Hans Passant and Karl Bielefeldt.

Can you just send the data without encoding? How is the data being sent? TCP/UDP/IP/Ethernet definitely support sending binary data without restriction. If this isn't possible, perhaps converting the data to hex will solve the problem. Base64 will also work (better) but is considerably more work. For small amounts of data, hex is probably the easiest and fastest solution.

+1 again to Karl and Ben for mentioning wireshark. Invaluable for debugging network problems like this.

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