我还在 nano 克隆上运行 grvl，我没有遇到任何问题。你能把你的g代码文件发给我，我可以测试一下吗？您使用的是什么 GUI？

我发现很难充分强调我发现您的问题与波特率错误相关的可能性有多大。完全相同的数据表很好地解释了多数投票的多重采样允许无问题的信号重建高达大约 +/- 4.0% 的最大理论误差，这是 115200 波特产生的 2.1% 的百分之二和/或两倍。连接本身是板本地的，任何其他速率误差源只能源自驱动 ATMega 和 ch340g 的 xtals，但正如数据表本身所指出的那样，xtals 只是没有可能干扰波特率的那种不精确性. 也就是说，显然错误越少越好（除非对于已经超负荷运行的 MCU 意味着每秒中断次数增加一倍），但我认为在这种情况下这并不重要。
编辑：添加粗体说明

别忘了我们处理的是不完美的物理设备，通常是制造废品，最终出现在全球速卖通等类似产品上——所以你不能排除不可靠的 CH340、不合规格的 xtal 或类似产品。制造商也可能在规格中撒谎，或者数据表可能翻译得很糟糕。我听说有人在 3d 打印机的背景下遇到 115200 而不是 250000 的问题。

我在这里特别看到，当使用 Arduino 克隆从 115200 波特切换到 250000 波特时，计时问题得到了解决。@kfoltman与官方板相比，克隆板的制造规格可能不那么准确，这可能是正确的。但是，我想补充一点，这个问题仍然很少见。

FWIW，使用 250000 波特没有问题。事实上，我可能会建议使用超过 115200 的波特率。115200 波特率是 Grbl 标准的唯一原因是它是所有终端程序普遍支持的波特率。

@TadyTheFish – 我正在运行自己正在开发的 GUI。我可以为您将该文件放在我的保管箱中，但正如我所说，这是一个不切实际的代码，除了测试外没有任何其他用途。

@blinkenlight – 你可能会觉得难以置信，但我只需设置 115200 即可重现错误，而我只需设置 250000 即可使其消失。仅此而已。没有其他的。那么向我解释一下 115200 而不是 250000 的错误的可重复性如何不能证明这些错误与波特率相关？如果它与波特率无关，给我一些其他的东西来寻找，因为我发现这试图使从我的 GUI 到 GRBL 的一切都尽可能健壮。如果我的 GUI 有问题，我想找到它，但从我测试的推论角度来看，一切都表明它与波特率有关。

@kfoltman– 这是一个好点。我有另一个 Nano，我可能会刷它并匹配 eeprom 设置并测试那个 Nano 板，看看它是否是这个 Nano 板的侥幸，或者它是否可以在另一个 Nano 板上复制。

@chamnit – 啊哈。由于终端支持，我看到 250000 哪里有问题。我现在意识到即使是 Arduino IDE 也只能达到 115200。

我不想让任何人认为这本身就是一个 GRBL 问题，因为我不认为它与 GRBL 的编码有任何关系。我相信它更多地与硬件有关，如果您在 Arduino 论坛上进行搜索，您会发现有很多关于 ATmega 328 板上 115200 问题的帖子。如果你通读了足够多的内容，你会发现一个相似的主题。当您设置 115200 以外的其他内容时，错误就会消失。当然也有关于其他波特率的串行错误的帖子，但根据我的阅读和推断，115200 在 ATmega 328 上特别麻烦。我不是这方面的专家以任何方式。只是报告我所发现的。

正如我所说，这是一个极其罕见的错误。哎呀，我现在才发现它并且一直在使用 GRBL 并为我的 GUI 编程成百上千个小时而从未见过这个问题。它只有在我决定将一切都推到绝对极限（全急流、短距离移动、30kHz 步进率等）时才会出现。对于“普通”用户，它可能永远不会出现。话虽如此，除非我找到不这样做的理由，否则我将从现在开始使用 250000。

@TadyTheFish我的测试文件位于：
https ://www.dropbox.com/s/sljlq0q486022uz/139K%20file%20all%20rapids.nc?dl=0

此外，在意识到我没有超过 115200 波特的基本串行终端程序后，我制作了一个并将其上传到我的保管箱。如果有人想要它，请访问以下链接。我为 grbl 特定命令添加了一些额外的按钮。
https://www.dropbox.com/s/jw7a42z37h8xxo3/SerailMonitor_1_0_0_1.zip?dl=0

@109JB– 证据…？真的现在。绝对不是。当你改变波特率时，你改变了关于串行活动的时间如何与其他一切相互作用的一切——GRBL 中的代码、ch340 芯片中的硬件、USB 主机和 ch340 之间的时间和/或消息大小、主机 USB 的服务堆栈和驱动程序——你改变了一切。在任何有意义的意义上，这都不能称为波特率错误的“证据”。为了取悦您，更有说服力的证据是断开 Arduino 的 xtal，将其切换到外部时钟并以 16MHz 然后 16MHz+/-2.1% 的频率馈送它，然后看看问题来来去去。它仍然不会完全改变被测试的东西，因此它仍然是一个有缺陷的证明，但它会具有更高的可信度。

无论如何，我从来没有说过这是不可能的，只是说这不太可能——该理论根本无法为发生的故障提供令人满意的解释，并且在已建立的理论充分解释其发生机制之前，不会确定错误。如果 115200 确实是一个广为人知的有问题的速率，那么当然很可能那里发生了一些狡猾的事情，但所有这些告诉我们的是其他一些波特率可能会更可取，除非太不方便 – 别忘了，大多数人不会毕竟似乎有很多问题。

@blinkenlight：我认为这是最简单的解决方案通常是正确的示例。事实上，将波特率从 115200 更改为其他值将成功解决此类问题。鉴于这不是 Grbl 孤立的问题，而是其他固件的问题，我会说与 115200 波特相关的计时错误可能是罪魁祸首。我的猜测是它的外部时钟相关，正如你提到的，克隆的时钟可能不如官方板那么精确。

无论哪种方式，串行 RX/TX 通信都是在 328p 的硬件级别上处理的。只要串行 ISR 在下一个 RX 字节进入之前得到服务，Grbl 就不会丢失任何数据。

@blinkenlight – 你的话看起来很刺耳**，所有粗体尖叫文本。**首先，有证据表明使用 115200 与 250000 存在问题，即使错误的确切机制尚不清楚。它可以在 GRBL 代码中吗？还是ch340g芯片？或者是其他东西？当然可以，但它发生在 115200 而不是 250000 的事实绝对证明波特率设置是可疑的。我看不出你还能怎么反驳。是“波特率错误”吗？我不知道，但这是与波特率设置相关的错误，这是我的意思。其他一切都是语义。不管是什么原因，切换波特率可以解决问题。我只是想揭示一个可能发生的错误，尽管这种错误不太可能发生。

@chamnit– 当然，只要执行双倍的 ISR（现在似乎没有任何支持 250000 的发件人）不是问题，为什么不呢。正如我所说 – 如果这确实是一个广为人知的问题，那么 Arduino 上的 115200 波特率显然有些有趣，没有争论。

@109JB– 你读到一段文字的任何语气都是你自己的解释。无论哪种方式，上次我检查粗体或斜体是强调一个点，尖叫看起来像这样（当然只是作为示范）。有点像你在上面做的事。无论如何，没有人认为波特率本身不可能是问题，我只是指出我有问题归因于波特率的精度。如果你坚持的话，我很乐意继续玩“他说/她说”，但我相信这一点现在已经没有实际意义了。

@blinkenlight– 您只是在争论错误是来自波特率精度还是其他原因的语义。我个人并不关心它是否真的来自波特率精度或与波特率选择相关的其他因素。我只关心如何修复它。以下是事实：

1. GRBL 在以 115200 波特传输时报告错误 – 事实
2. 该错误在 115200 波特时可重现 – 事实
3. 错误在 250000 波特时消失，我无法在此设置下重现它 – 事实
4. 来自其他论坛的研究表明 115200 波特率在 328P arduino 上可能存在问题 – 事实
5. 115200 的理论波特率误差为 2.1% – 来自数据表的事实
6. 250000 时的理论波特率误差为 0.0% – 来自数据表的事实
7. 328P 数据表将推荐的最大接收器波特率误差列为 + 或 -2.0% – 来自数据表的新事实
8. 2.1% 大于 2.0%
9. 0.0% 小于 2.0%

考虑到第 6、7 和 8 点，115200 波特超过了 Atmel 规定的最大推荐波特率误差，而 250000 则没有。数据表将 2.0% 的值描述为“可以容忍的最大接收器波特率误差”。这些是 Atmel 的话，不是我的。最重要的是，8 个数据位的表格仅在 U2Xn = 0、正常速度模式下显示。如果高速模式在 8 个数据位不可用，则 115200 和 8 个数据位的波特率误差不是 2.1%，而是 -3.5%。这将使它远远超出 Atmel 推荐的最大误差范围。

可以接受的波特率容差取决于发射器和接收器的波特率精度，因此您引用的 4% 左右的错误阈值是两者的总错误，而不仅仅是在 Arduino 端。

底线是在 115200 波特率下发生了一些事情，无论多么罕见。它可能来自波特率精度、硬件、GRBL 编码、软糖冰淇淋等。最重要的是，选择 115200 会导致错误，而选择 250000 则不会。

@chamnit– 来自您的评论：
“无论哪种方式，串行 RX/TX 通信都是在 328p 的硬件级别上处理的。只要在下一个 RX 字节进入之前为串行 ISR 提供​​服务，Grbl 就不会丢失任何数据。”

由此我推断，我遇到的错误是“完美风暴”的结果，如果出现类似的情况，它可能只会抬起丑陋的头。我想我的意思是，这只会是一种极其罕见的情况，在现实生活中的加工应用中不必担心太多，如果想安全起见，只需使用 2500000 波特率即可。这是你的看法吗？

谢谢

@109JB：如果确实是外部时钟问题，我会说在制造商和以 115200 波特运行的产品之间很少发生。对于制作精良的产品来说更是如此。这通常来自多年来我看到这个问题突然出现的观察。它几乎总是在便宜的克隆板上，改变波特率就可以解决它。但是，目前关于根本原因究竟是什么，这都是猜测。

@blinkenlight确实提出了一个很好的观点，即串行 RX ISR 必须以 250000 波特的速度提供两倍的服务。以此速率，您可能会在步进频率的上限遇到一些性能问题。我测量过一次 328p 的中断开销。它不是很好，所以它会很快占用可用的周期。

因此，我做了更多测试，并决定从数据表中尝试另一种波特率误差值较低的波特率。76800 波特在低速和高速模式下均显示 0.2% 的错误，因此我将 GRBL 和我的 GUI 中的波特率设置为此，并运行生成错误的文件 3 次，没有错误。它仍然在 115200 处出错，所以那里没有任何变化。与 250000 波特相比，运行时间大约慢 10%，但这同样是一个不切实际的 G 代码文件。到目前为止，我看不到使用 250000 或 76800 波特率的缺点，除非路由器可能切割软材料。哦，所有这些测试都是在 GRBL 设置下进行的，这样 G0 快速移动应该达到 30kHz。使用这些设置，250000 似乎不会对 GRBL 造成问题。

@chamnit: 你认为有什么理由应该避免使用 76800

@109JB：好吧，如果你必须坚持——Arduino 实际上并没有与另一个 Arduino 通信（在这种情况下，将允许的 4.0% 速率误差保持在一半以下的论点会有一些优点）但是使用 ch340g，声明的最大 Tx 错误率为小于 0.3%。很好的尝试，但没有雪茄（事实）。不幸的是，返回的最大可接受错误的表述更加模糊，但无论哪种方式，即使在实际不兼容的情况下，只要流到 Arduino 的数据完好无损，也不应该自行产生错误。修复该特定板（如果速率错误确实是问题）并保持标准波特率的另一种方法可能是将 xtal 更改为 20Mhz 并针对该频率重新编译 GRBL – 这取决于您感觉更舒服更改以及您希望保留的内容。反正，如果它对您来说在 76800 时效果更好，那就太好了。我想少了一个问题。

@blinkenlight– 我已经在 76800 和 250000 之间的波特率下进行了测试，问题出现在数据表中列出的超过 Atmel 最大波特率错误规范的波特率处，并且不会出现在错误百分比低于 Atmel 规范的波特率处. 所以如果这不是某个地方的时间问题，那么你告诉我它是什么？

对于其他人，我决定做更多的测试，因为我有几个 Nano 克隆和几个 Mega 2560 板。当使用我在 115200 波特率下使用任何 Nano 克隆时遇到的问题出现，但在 250000 或 76800 时没有。这些克隆并非都来自同一供应商，从表面上看，有些与板颜色和屏幕颜色略有不同文字印刷。所以，肯定来自不同的批次。当以 115200、76800 或 250000 波特率在 Mega 板上运行时，问题不会出现。Mega 开发板不使用 ch340g 芯片进行通信。我很好奇 UNO 克隆是否存在问题，因为它们也使用 ch340g。不幸的是，我没有要测试的 UNO 克隆。

我刚刚在我的 GUI 中添加了对 250000 波特的支持。事实证明这有点痛苦，因为它是 Posix termios API 不支持的非标准速率。Linux 和 OSX 都有自己奇怪的记录不完整的 ioctl() ，它可以让你在 termios 的背后请求一个任意的非标准速率（在 Linux 上这涉及直接包含一个内核头文件，因为它不受 Glibc 支持）。

它取决于硬件和内核驱动程序是否可以实际使用任何特定的速率。我发现，使用带有 ATmega16U2 USB 接口芯片的 Uno 板，250000 波特在 Linux 和 OSX 上都可以工作，但是在带有 CH340g 芯片的 Nano 板上，它只能在 Linux 上工作。当您请求 250000 波特时，OSX CH340g 驱动程序返回错误。

我没有带有 FTDI 芯片的电路板，所以我不知道这些是否可行。我确实在某处读到过 Raspberry Pi 的内置串行端口能够达到 250000 波特，但前提是您首先更改其中一个启动参数以更改波特率发生器时钟速率。

我认为 serial.c 中的 UBRR 公式不正确

uint16_t UBRR0_value = ((F_CPU / (8L * BAUD_RATE)) - 1)/2 ;

不应该吗？

uint16_t UBRR0_value = ((F_CPU / (16L * BAUD_RATE)) - 1) ;