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

准确地说，我不想让任何人为 18.432 MHz 计算正确的调整（我会自己尝试）。但也许有人有一个想法，通过重置 F_CPU 哪些时间是自动正确的，我必须在哪里手动调整？

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

谢谢，
莫雷斯

PS：这里有谁跟随（甚至建造）了 GRBL-JOG 项目和 Make 杂志（以前称为 c’t Hacks）的木厂吗？我想取得联系，交流一些经验。

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

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

使用 250000 boud 对我来说不是很好，因为大多数解释器默认不使用 250000 boud。

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

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

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

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

@109JB例如，您可以将 100k 的 boud 用于您制作的测试程序和使用 ch340 的假 arduino，您应该不会出错。

我确实在所有波特率下都遇到了错误。有些少，但我测试的所有最终都显示错误。您声称 250000 波特应该不会产生错误，但我在#845的一篇文章中说明了这一点

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

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

@109JB你说

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

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

当您使用 250000 遇到错误时，您一直在使用状态请求，您是使用 1start 8data 1stop 位，还是使用奇偶校验位？
你说如果你只使用发送 g 代码你不会得到任何错误。
据我了解，您使用的是越野车版本@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 和 8bits（无奇偶校验）为 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 克隆并避免所有这些问题时，尤其如此。