嗨，
由于我已经 2 周没有得到任何答复，我想知道我的问题是否没有被理解？

准确地说，我不想让任何人针对 18.432 MHz 计算出正确的调整（我会自己尝试）。但也许有人有想法，哪些时序可以通过重置 F_CPU 自动纠正，哪些我必须手动进行调整？

我知道 GRBL 通常坚持标准的 Arduino，但也许仍然有人可以提供有关此定制的提示。

谢谢，
莫里斯

PS：在座的德国人中是否有任何人使用 Make 杂志（以前称为 c’t Hacks）的木工机跟踪（甚至构建）了 GRBL-JOG 项目？想联系交流一些经验。

@morres83: 抱歉，您可能没有得到答案，因为没有答案。我从没听说过 GRBL-JOG 项目。但是，Grbl 被编写为能够改变时钟频率，但我从未测试过它，或者从来没有必要这样做。你是我记得的过去四年中第一个尝试这样做的人。从理论上讲，这是可能的，正如您通过更改 F_CPU 发现的那样，但您可能还需要更改其他内容，例如在 Makefile 中。我认为你在这方面是靠自己的，但让我们知道你的进展。

你好。我是这个社区的新人，但我可以重新打开这个问题#608 吗？如问题#837中所述，使用ch340（有时未烧录atmega16u2）使用 115200 波特率存在问题。
所以使用18.432MHz xtal数据传输应该没有问题。
我个人在使用 ch340 和 atmega16u2 时都遇到过问题。

使用 250000 波特对我来说不太好，因为大多数口译员不使用 250000 波特作为默认值。

事实上，如果您使用 18.432mhz xtal，最后两个已知问题都会消失。使用 ch340 的正品和廉价克隆。还是我错了？

我怀疑你会解决 ch340 的问题。问题出在固件中，无法修改。16U2 固件可用，并且已生成修改后的固件以消除 16U2 的问题。如果没有可用的 ch340 固件，则无法修复。有关该问题的更详细解释，请参阅#845

@109JBch340 是基于硬件的。ch340 中不需要任何软件更改。
简单数学：
*16000000/115200=138,88889（你会得到一个错误，因为在不正确的周期中有很小的机会获得 UART 信号）它有周期差异 2.1% +- 0.3% ch340 不稳定性所以它更多（在更糟糕的情况下 2.4%）超过 atmega 可以处理的 1.5%。
*16000000/250000=64（自己证明工作没有错误，没有周期差异）
*别人用的是2Mb baud。所以 16000000/2000000=8（没问题）
*如果我们使用 18.432MHz xtal，我们可以使用所有标准波特率。例如 18432000/115200=160。
如果你想避免错误，你可以使用任何波特率，即 xtal/baud=whole，或者理论上逗号后的波特率更小的值（Residual 不知道它在英文中是否正确）。

据我了解，问题不仅仅是波特率错误，还包括 USB 数据包实现等问题。

@109JB例如，您可以在制作的测试程序中使用 100k 的波特，在 ch340 中使用假的 arduino，您应该不会出错。

我确实在所有波特率下都出错了。有些更少，但我测试的所有内容最终都显示错误。你声称 250000 波特应该不会产生错误，但我在#845的一篇帖子中说明了这一点

在我使用 ch340g 芯片进行的测试中，似乎以 250000 运行会导致更少的错误

请注意，我说的是“更少”的错误，但确实有错误。在我看来，即使是一个错误也太多了。遇到的错误与 ch340 接收数据包的时间和 ch340 发送回主机的状态报告有关。最重要的是，它是 ch340 内部的东西，无法修复。

@109JB你说

我得出了和你一样的结论。高速运行包含大量短段的代码，或快速状态请求，或这些的组合可能会导致更多错误。在我使用 ch340g 芯片进行的测试中，虽然似乎在 250000 下运行会导致更少的错误，而在我的带有 Atmel 芯片的 Mega 板上，250000 会导致更多错误。我在 ch340G @ 115200 上遇到的错误是整个交易的开始。

事实上，正如我在上面的前一篇文章中指出的那样，如果我只是使用发送响应流式传输 G 代码并关闭状态请求，我就无法从 GRBL 中得到错误。如果我打开状态请求，我偶尔会遇到错误。这是相当随机的，但在我看来，放慢定时请求会导致更少的错误，这是有道理的。

当你使用 250000 出错时你一直在使用状态请求你是使用 1start 8data 1stop 位，还是使用奇偶校验位？
你说如果你只发送 g 代码就不会出现任何错误。
据我了解，您使用的是 buggy 版本@AlexHoldenatmeaga16u2软件？删除错误后，atmeaga16u2 版本没有错误，但不是因为没有错误，而是因为它是相同的错误（相同的差异），atmeaga16u2 和 atmega328p 的 xtal 16MHz 相同。

这是我的意见。如果我错了，请纠正我。

也许你会对此感兴趣

也许 CH340 在 250k 波特率下会出现更多错误，因为它使用12MHz 晶振 但使用不同的架构。

那么，任何人都可以告诉我需要更改代码以更改晶体振荡器频率吗？

@109JB你能分享你的测试程序吗？

大多数 Arduino 板上使用的 FTDI FT232 没有显示这个问题，它甚至没有使用晶体。由此得出的结论是，问题很可能不是波特率错误，而是 USB 实现中的问题。我没有查看 16u2 代码以查看为解决该问题所做的更改。

关于将不同的晶体与 Arduino 一起使用，只需编辑引导加载程序代码并将其烧录，然后为 Arduino 编译器创建自定义板定义即可。我已经为 20MHz 晶体完成了此操作，如果有帮助，代码在这里。

@electrokean还有什么不应该修改的吗？没有上升，下降时间有影响吗？

我不明白。什么的上升和下降时间？您询问要更改什么代码。

关于 16u2 的更改：原始代码效率低下且存在错误。在高传输速率下，Arduino->PC 缓冲区可能溢出并破坏 PC->Arduino 缓冲区的内容，通常会导致部分状态响应消息在 Gcode 行的中间反射回 grbl。

谢谢@AlexHolden– 所以与我怀疑的波特率错误无关。

@electrokean是的。这与波特率误差无关，只要您使用 16u2 和 328p，以及相同频率的振荡器即可。如您所见，16u2 和 328p 的实际比特率约为 117.647K，所以没问题。但是，如果您使用 ch340（根据数据表），ch340 端的比特率为 115.2k+-0.3%（从 114.8544 到 115.5456），而 328p 端的比特率为 117.647K。这是从 1.8% 到 2.4% 的差异。建议最大差异，当 U2X=1 和 8 位（无奇偶校验）为 1.5%。

我错了吗？

附加参考表格serial.c：
void serial_init()
{
// Set baud rate
#if BAUD_RATE < 57600
uint16_t UBRR0_value = ((F_CPU / (8L * BAUD_RATE)) - 1)/2 ;
UCSR0A &= ~(1 << U2X0); // baud doubler off - Only needed on Uno XXX
#else
uint16_t UBRR0_value = ((F_CPU / (4L * BAUD_RATE)) - 1)/2;
UCSR0A |= (1 << U2X0); // baud doubler on for high baud rates, i.e. 115200
#endif
UBRR0H = UBRR0_value >> 8;
UBRR0L = UBRR0_value;
// enable rx, tx, and interrupt on complete reception of a byte
UCSR0B |= (1<<RXEN0 | 1<<TXEN0 | 1<<RXCIE0);
// defaults to 8-bit, no parity, 1 stop bit
}

所有迹象表明，Ch380 故障与用力推动时内部缓冲区溢出有关。数据块会丢失，而不是像您预期的计时错误那样丢失单个字节。

@sid123q我知道你要去哪里，但不使用 CH340 似乎要简单得多。我想如果你真的想尝试证明 CH340 问题的原因，那可能会很有趣。正如我所说，您只需要为备用晶振频率构建自定义 ATmega 引导加载程序（例如 Optiboot）和 Arduino 板配置文件，烧录引导加载程序，然后焊接到晶振中。没有太大的努力。

使用 FTDI 芯片时，您可以获得非常好的波特率精度 – 我会说和 CH340 一样好。即使 FT232 不使用晶体，它也有一个与 USB 时钟同步的内部 PLL，并且还允许次整数除数。据我所知，没有人在使用 FTDI 芯片的 Arduinos 上遇到过这个问题，他们也不必调整波特率来补偿 ATmega 波特率除法错误。尽管我不喜欢 FTDI 定价和他们对假冒芯片的处理方法，但他们生产了一些非常有用且非常可靠的产品。

所以这就是为什么我说这很可能是 CH340 USB 实现错误，而不是波特率错误问题。并作为@chamnit说，问题表现的方式也支持这一点。

@109JB你能分享你的测试程序吗？

抱歉，我没有测试程序的代码了。

我使用了 8 个数据位、1 个停止位并且没有奇偶校验。

所有迹象表明，Ch380 故障与用力推动时内部缓冲区溢出有关。数据块会丢失，而不是像您预期的计时错误那样丢失单个字节。

我认为@chamnit上面的评论很有可能。最重要的是，当你用状态请求和快速 g 代码流过分地推动 ch340 芯片时，并非所有数据都能通过 328P。

顺便说一下，当我做其他测试时，我只对 ch340 做了几次测试。

首先是环回测试，其中从 CH340 到 328P 的 TX 和 RX 引脚短路。这只是获取将进入 328P 的数据并将其推回 ch340，然后将其循环回主机。这样做我无法产生错误。然而：

另一个测试是我使用 2 个 arduino，一个带有 grbl，另一个只使用 USB-> 串行芯片。grbl 板是一个带有 ch340 的 Nano，另一个是带有 16U2 的 Mega，但实际的 Mega 什么也没做。我将 Nano 的 RX 引脚连接到 Mega 的 TX 引脚。就这样，16U2把所有通过CH340的都传回了上位机。本质上只是将其循环回去。与此同时，Nano 正在运行 grbl 并设置为将响应回显给主机。我写了一个测试程序来比较 3 个数据集、发送线、grbl 回声和通过 16u2 循环的数据。比较了所有 3 个，结果是损坏发生在 ch340 中。我记得，当发生错误时，16U2 数据始终与从 ch340 到 grbl 的数据匹配，但与发送的数据不匹配。

我想对我来说，虽然我真的很喜欢 nano 平台并且仍然在其他东西上经常使用它，但 CH340 的问题和 16U2 是“固定的”这一事实让我毫不费力地选择了它。我只是不相信 ch340 适合我的机械加工。当您可以以大约 4 美元的价格购买带有 16U2 的 UNO 克隆并避免所有这些问题时，尤其如此。