我也在纳米克隆上运行 grvl，我没有问题。你能把你的g代码文件发给我，让我测试一下吗？你使用什么GUI arw？

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

不要忘记我们处理不完美的物理设备，通常会在 aliexpress 之类的产品上制造不合格品 – 所以你不能排除狡猾的 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 板的侥幸，或者它是否可以在另一个板上复制。

@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. 以 115200 波特率进行流式传输时 GRBL 报告错误 – 事实
2. 错误在 115200 波特下可重现 – 事实
3. 错误在 250000 波特时消失，我无法在此设置下重现它 – 事实
4. 其他论坛的研究表明 115200 波特在 328P arduinos 上可能有问题 – 事实
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% 值描述为“可以容忍的最大接收器波特率误差”。这是爱特梅尔的话，不是我的。最重要的是，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 板。当使用我拥有的任何 Nano 克隆时，遇到的问题出现在 115200 波特，但不是 250000 或 76800。这些克隆并非全部来自同一供应商，表面上有些与板颜色略有不同，屏幕不同文本的打印。所以，肯定来自不同的批次。在 Mega 板上以 115200、76800 或 250000 波特运行时，不会出现此问题。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 波特，但前提是您首先更改其中一个引导参数以更改波特率发生器时钟速率。

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

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

不应该吗？

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