linux - 通过串行端口发送一些无符号整数时出错(teensy -> raspi)

Question

我在尝试通过 USB 在 teensy 和 Raspberry Pi3 之间进行通信时遇到了一些问题。

当我发送 unsigned int 时，我收到所有包含字节值 13 的数字的错误数字，该字节已更改为值 10

例如:

13 becomes 10;
269 becomes 266;
525 becomes 522;
781 becomes 778;
1037 1034;
1293 1290; 
1549 1546; 
1805 1802; 
etc...

但对其他人不是...

无论我在 pi 上使用我的程序还是通过 /dev/ttyACMO 发送 cat 命令。但是，当我在另一台计算机上执行相同操作时，一切正常。

我在另一台计算机上遇到了同样的问题，所以我认为问题出在我安装的错误库上。

你有什么想法吗？

PS: teensy 上的代码很简单:

    unsigned int i = 0;
    while(true){
        Serial.write((char*) &i, 4);
        ++i;
        delay(500);
    }

Answer 1

ASCII 十进制 10 是换行符 ( <LF> )。 ASCII 十进制 13 是回车符 ( <LF> )。

你很可能是隐式的胜利<CR><LF> ⇄ <LF>转换; Wikipedia explains it in detail但总而言之，它 Root 于技术历史:

• 当计算机第一次获得文本输入/输出功能时，这不是通过显示器完成的，而是通过电传打字机完成的。电传打字机本质上是一台机械打字机，其中每个“键”也可以通过电信号敲击。

• 打字机和电传打字机区分将纸张前进一行(换行)和返回车架(打字头)回到起点一行。

• ASCII 编码的创建本质上是打字机功能与二进制模式的 1:1 映射。

最终结果是，为了在电传打字机上开始新的一行，您必须发送一个换行符 ( <LF> ) 以及一个回车符 ( <CR> )，两者的顺序并不重要，物理效果几乎相同。

然而，不同的操作系统采用不同的默认约定来存储和传输换行符:

• MS-DOS 和继承 Windows 选择显式存储 <CR>和 <LF>按照这个顺序。

• Unix 选择存储 <LF> only 并将其翻译成 <CR><LF>发送到电传打字机时的顺序，接收时反之亦然。 Linux 采用了这个 Unix 约定。

当涉及到通过串行链路传输时，默认值始终是，对于换行符 (<CR>,<LF>)应该传输对，期望另一端是电传打字机。 这就是这里可能发生的事情!通过线路传输的实际数据是 <CR><LF>但是继承了 Unix 方式的接收操作系统默默地将它转换为普通的 <LF> . 对于任何大于 255 的数字，这种转换将发生在其低 8 字节，同时丢弃整个字节。

当然这个默认行为可以重新配置，即通过termios/ioctl_tty在打开的串行端口上，特别是输出和输入选项标志(即标志 OPOST 、 ONLCR 、 ONLCR 、 OCRNL 、 ONLRET 、 INLCR 、 IGNCR 、 ICRNL )。

但是我强烈建议您不要摆弄这些标志，而是将以下两个教训牢记在心:

• 纯文本是通用的交换格式! (即如果可以避免，不要通过网络提交原始二进制文件，而是将其发送为 – 也是人类可读的– 文本)

• 自由阅读您收到的内容；对发送的内容要保守! (即以某种方式编写程序，读取数据不依赖于严格的数据顺序和格式，即可以容忍任何类型的换行序列或数量空白分隔字段；但也以严格的常规方式发送数据，这样不那么自由的接收者就不会被它阻塞)