不，它没有。使用 250000 是有充分理由的，因为它的误码率比 230400 低得多。在 16Mhz Arduinos 上。

根据需要，您可以在构建固件时以任何方式配置固件，因此您可以自己配置波特率。或者使用 Marlin 生成器：http ://daid.mine.nu/~daid/marlin_build/

真正应该做的是修复 PySerial，使其使用“termios2”和 TCSETS2，这是设置自定义波特率的新内核接口，并使 250000 在 linux 下工作。此外，250000 是否有效取决于你的发行版，因为在 Fedora 中它似乎工作正常，而 Ubuntu 无法使用 250000。

（可以在波特率设置处加个注释，默认250000在linux下有些问题）

它之所以具有较低的误码率和较少的抖动，纯粹是因为它的速度更快。有标准是有原因的。250,000 波特不是标准的。在任何文档的任何地方都没有人提到 230400 和 250000。但是，230400 适用于当前未更改的软件，而 250000 则不能。

之所以有较低的错误率是因为Arduino使用的AVR的UART分频器可以无误地创建250000，而230400有3.5%的时钟误差。

那么如何为您提供文档数据表呢？

ATMega2560 数据表第 231 页。表 21-12：fosc = 16.0000 MHz
波特率 – 错误
230.4K：-3.5%
250.0K：0.0%
（这是假设 Arduino 软件足够智能，可以使用 U2X 位，否则错误会增加到8.5%)

此外，Ultimaker 上的实验表明 250000 给出的错误更少。

我认为 Linux 系统正在使这个 TBH 变得不必要的困难，我认为这是一个错误。自 2006 年左右以来，内核似乎已经支持非标准波特率，但 libc 正在阻碍。

我已经在此处针对我使用的发行版 Debian 提交了一个错误：
bugs.debian.org/683826
实际上，我认为在修复底层之前，很难在不是用 C/C++ 编写的重新编译主机软件中修复此问题.

所以与此同时，我建议 Linux 用户使用标准波特率。

不确定您是打算回复 github 还是直接回复我。但是你
回复了我。

很高兴看到您在 debian 上提交了错误。我实在是太忙了，没时间
自己去关注这个 bug。如果你确实想尝试以
所有可能的方式解决这个错误，我有一些 C 代码可以
在自定义波特率上为不同的内核版本配置串行端口。我可以分享这段
代码。

（注意事项，如果 Ultimaker 在 Linux 下运行，我的 Cura 软件包会在其上安装默认波特率固件，以避免此问题）

2012 年 8 月 4 日星期六下午 3:55，Ian Jackson <
reply@reply.github.com

写道：

我认为 Linux 系统正在使这个 TBH 变得不必要的困难，我
认为这是一个错误。自 2006 年左右以来，内核似乎已经支持非标准波特率
，但 libc 正在阻碍。

我已经在此处针对我使用的发行版 Debian 提交了一个错误：
bugs.debian.org/683826
实际上，我认为在修复
底层之前，很难在不是用 C/C++ 编写的重新编译主机软件中修复此问题.

所以与此同时，我建议 Linux 用户使用标准波特率
。

---

直接回复此邮件或在 GitHub 上查看：
https ://github.com/ErikZalm/Marlin/issues/205#issuecomment-7501930

快速思考这个问题。人们不使用 1Mb/1.25Mb 而不是 115k/250k 的任何原因？我的atmega1284p支持，ft232支持。。。

ArduinoMega2560 不使用 TFDI 芯片，而是使用 ATMega8U，它很可能也支持它。然而，比特率越高，一些随机 EMI 干扰的可能性就越大。而且您会遇到与 250k 相同的软件支持问题，并且很可能会遇到低速 USB 限制。

@daid嗯，不是真的。自从我发布（一个月前）以来，我一直很高兴地使用 1Mb 序列，并且一切正常。AVR 支持它，我的 FTDI 芯片也支持它。它是 USB 全速，所以它是 12Mb。即使是低速，也将是 1.5Mb。没有更慢的 USB。
关于 EMI 等——1Mb 并不快。我认为它很慢。没有 EMI 等问题。芯片是 UART 到 USB 收发器，它为您完成所有过滤魔法。它只是工作。
我也不确定为什么人们在 Linux 上遇到“非标准”波特率的问题。它在 Ubuntu 和 Windows 上对我来说工作正常。我认为这是一个驱动程序问题而不是内核错误。但我在这一点上可能是错的。

@thantik标准存在是有原因的。原因很简单——甚至是时钟分频。通过让两个设备都使用定义的速度，您可以始终保证通信。
但是，如果您将 AVR 上的 UART 设置为 1Mb，并将收发器设置为 1Mb，它会很好地工作。如果您将两侧都设置为 219kbit，它也可以很好地工作。FTDI 芯片完成所有转换，因为无论您的 UART 速度如何，USB 都将始终以 12Mbps 的速度运行。

马尔钦

@nothinman：ArduinoMega2560 R2 或 R3 没有 FTDI 芯片，但有一个 ATMega8U 做 USB 串口。
此外，USB 在执行 USB-Serial 时有相当大的开销，因此您不能将 USB 速度直接转换为串行速度。
1MBit 对于不是为它设计的电路板和电缆来说很快。尤其是在带有 RepRap 步进器的嘈杂环境中。

人们在 Linux 上遇到非标准波特率问题的原因是因为内核开发人员创建了 2 个不同的接口来设置非标准波特率并且并非所有驱动程序/内核版本都支持两者，并且并非所有串行库都支持两者。在这种情况下，PySerial 不支持 Termios2。

@daid: 我知道有些人不使用 FTDI 收发器。对于那些它可能确实不起作用。
没有电缆。AVR 的 RXD 和 TXD在 PCB上连接到 FTDI 芯片。唯一的电缆是 USB 电缆。
开销在这里毫无意义，因为 USB 比 AVR/FTDI 支持的串行速度快得多……

感谢有关内核的评论。没有意识到这一点。可以编写基于定时器中断的基于软件的串行驱动程序，因此可以使用任何波特率。
嗯，我很高兴我的作品。我建议人们获得 FTDI 芯片

我不确定我是否会担心 <4% 的错误——除非 UART 状态机设计不当，否则它应该能够通过对齐停止/开始位转换来处理帧漂移。

请记住，UART 设计用于漂移。不同机器上的振荡器很容易相差几百 ppm，并且由于机器不是时钟同步的，如果该框架逻辑不合适，您最终会出现错位。

阅读 8250 上 1980 年代或之前的一个非常古老的数据表，描述状态机以及它如何对输入进行过采样以将链接与帧漂移对齐可能非常有启发性。IIRC，我认为这是 8 倍或 16 倍的过采样。所以我预计高达 6% 的利率差异无关紧要。我希望其他 UART 设计具有可比性。

事实上，快速浏览一下 StackOverflow 或多或少可以证实我刚才所说的：http ://electronics.stackexchange.com/questions/7610/what-is-the-maximum-acceptable-baud-rate-error-for -rs-232-串口通讯

@toybuilder你的理论没问题。但是对于 250000，我没有收到任何通信错误。使用 115200 我得到错误。打印不会停止。但是您可以在打印的对象中看到一些伪影。

这些错误是否显示为帧错误？或者是由于没有足够快地向控制器提供额外的 Gcode 数据而导致的问题？如果速率不匹配导致实际行损坏，您会期望打印出来明显错误，因为大片的 gcode 会被破坏。

很抱歉，我没有深入研究源代码以了解等式的 Arduino 端的幕后情况。

230.4K 似乎是一种广泛支持的“标准”比特率，接近 250K，因此人们预计在该速度下运行问题较少。我想更大的问题是 USB-> 串行转换器对速度选择的支持程度如何。

如果有一种方法可以通过某种手动开关选择通信速度，那将会很有帮助——我知道，跳线是上个世纪的事，但这可能是解决这个问题的一个简单方法。

似乎自动发现应该是可能的。如果固件和主机同意首先尝试以某个非常常见的比特率（比如 9600）连接，发送他们可接受的波特率列表，然后断开连接并以两个列表中的最高速率重新连接，会怎样？

为了使转换更容易，您可以向 Marlin 添加一个 M 代码，该代码将列出可接受的波特率，另一个 M 代码将导致它断开连接并以指定的波特率重新启动其串行，然后主机支持将是可选的。由于 115200 似乎得到了普遍支持（它是 Arduino IDE 中串行终端允许的最高速率，以及除 pronterface 下拉列表中列出的 250000 之外的最高速率），这可能是默认值，但是添加这些 M 代码将允许主机在 115200 连接后重新协商波特率。

我已经在 Cura 发现波特率超过半年了。甚至不需要固件的合作。但是设置波特率的命令在任何情况下都是有用的。

这很好，但如果问题是主机系统与固件中设置的波特率不兼容，那也无济于事。一方确实必须能够获得另一方可接受的波特率列表，并选择与自己的列表匹配的最高波特率，然后让另一方更改波特率。

仔细想想，还真的只用一个M代码就可以搞定。在没有参数的情况下，代码会导致固件回显其可用波特率列表，并且 S250000 后面的相同代码将触发切换到该波特率。

The firmware doesn’t care much for which baudrate you use, it can set the baudrate to any value you want, but some will be more accurate then others. The whole baudrate issue is 2 fold. First, not every hardware design handles noise pretty well, and thus some baudrates cause issues on a hardware level. Secondly, Linux. The kernel developers added a nice interface for setting custom baudrates (with TCSET2), however, for some reason this is hardly anywhere exposed by the kernel-header packages in common distributions, so pyserial also didn’t pick up on it. This interface is nothing new, and was introduced a few years ago.