奇怪，可能是 Teensy 崩溃，但我不能立即理解为什么您在重新启动时收到 TSender 消息。如果在建立连接后串行端口上有传入数据（并且如果控制器重置，则在设置中指定的 resetdelay 之后显示此消息：应用程序）。

Tsender 是否在没有任何错误消息的情况下退出？
如果在这样的崩溃之后，你连接到一个终端而不是那是怎么回事？
您使用的是哪种 USB 模式？

使用 USB 串行 2。没有退出消息。下次发生这种情况时，我将使用串行终端进行检查。

我让它运行了一夜，它似乎没有崩溃，但肯定有问题。不能将轴归零或全部归零。慢跑似乎是随机的距离。点击几下，现在它不接受任何输入。我关闭了 TSender 并运行了一个终端。这是一个截图。它只是不断地显示相同的行。截屏后，我尝试输入，它继续发送 ok。

重新启动 TSender 但它没有响应。

顺便说一句，我将使用最新更新重建 grblHAL 并重新运行测试。

好吧，那么我相信这一定是由于从串行流（在控制器中）读取数据已经以某种方式一遍又一遍地重复序列而变得混乱。

我现在也在使用 USB 串行 2 进行测试，也许我应该终止它并使用 USB 串行 1 进行测试以避免重复工作？

作为旁注，可以提到我通过不处理错误而故意让 TSender 中的某些数据易受攻击（目前）——但是这应该会在退出前导致错误消息。如果发生这种情况，串行数据在链中某处出现乱码。我还没有决定发生这种错误时要采取什么行动——通常我不喜欢继续处理……

我用最新的更新重建了。（顺便说一句，需要一种方法来自动插入我的更改，如 ioports）。

我已将 USB Serial 设置为 1 并重新运行测试，所以继续你的测试。

我的测试在 4 小时以上后变得混乱，打开终端并看到与您类似的重复消息。我之前没有注意到（在您的屏幕截图中）第二个 Bf: 值在两个值之间交替，这可能是一个线索（第二个值是 RX 缓冲区中可用的字节数）。所以我发出了一个重置​​命令 (CTRL-X)，因为这会刷新输入缓冲区 – 在 PJRC usb 驱动程序和由 grblHAL 添加的驱动程序中。奇怪的是，启动消息反复出现，表明重置命令以某种方式被重新读取。

这是 PJRC 驱动程序或我的代码中的错误吗？交替的 Bf: 值表示数据实际被读入 grblHAL RX 缓冲区。轮询数据时，我做的第一件事是获取 PJRC 驱动程序可用的字符数，如果没有可用的轮询则完全跳过。

我在 3 月 7 日改为获取可用字符数，因为我想从 PJRC 驱动程序读取一个数据块，以避免过于频繁地禁用中断（PJRC 驱动程序在读取单个字符时执行此操作）。从我阅读代码的方式来看，这让我想知道这是否是 PJRC 错误……

我也对 USB 串行 1 进行了类似的更改，这也会失败吗？

我的测试（USB Serial 1）已经运行了 2.5 小时。应该需要大约 12 小时。会让你知道会发生什么。

在稍微修改代码后，我运行了一个 USB Serial 2 测试以完成，在 MSP432 上并行运行的测试（TSender 在同一台机器上运行）也成功完成。

我所做的修改表明 PJRC 代码可能存在错误 – 或者它不是设计为在中断上下文中运行（轮询是从系统定时器中断完成的），即使 PJRC 声称如此。

修改后的代码：

void usb_execute_realtime (uint_fast16_t state)
{
    char c, *dp;
    int avail, free;

    if((avail = usb_serial_available())) {

        dp = rxbuf;
        free = usb_serialRxFree();
        free = free > BLOCK_RX_BUFFER_SIZE ? BLOCK_RX_BUFFER_SIZE : free;

        avail = usb_serial_read(rxbuf, avail > free ? free : avail);

        while(avail--) {

原文（删除第一行，第二行更改）：

        avail = avail > free ? free : avail;

        usb_serial_read(rxbuf, avail);

代码更改是从usb_serial_read()调用中重新分配 avail 值，这向我表明，usb_serial_available()当出现此问题时，调用由于某种原因返回了不正确的值。 是一个 20 个字符的“prebuffer”——这解释了为什么在返回不正确的值rxbuf时一遍又一遍地重复相同的输入。usb_serial_available()

我将运行一些进一步的测试，看看从中断上下文运行轮询是否是这个问题背后的真正原因，或者 PRJC 驱动程序中是否存在一个简单的错误。

USB Serial 1 轮询是从前台进程完成的，如果这没有失败，我不会感到惊讶。

使用 USB 串行 1，我现在进行了 14 1/2 小时的测试运行（忘记覆盖进给率）。所以，你是对的，没有失败。推送更改后，我将重建并使用 USB Serial 2 进行测试。

顺便说一下，Teensy 4.1 正在进行 Beta 测试，我已经申请了 Beta 副本。希望我能得到一个。它肯定会支持以太网，因此您肯定会从我这里听到一些关于此的问题。

提交cc7c59a应该有望结束 USB 传奇。我对 USB 1 和 2 进行了多次长时间测试，没有出现任何问题。

PJRC 驱动程序不喜欢在中断上下文中运行，我猜 USB IRQ 的优先级低于系统定时器 IRQ，这就是它随机失败的原因。

好的，今天将下载、构建和测试。感谢您解决这个问题，这不是一个简单的问题。