我不确定你是否可以这样说，步进中断显然需要足够快才能跟上最快的步进率，但你还需要处理时间来解释 gcode 并规划步进中断应该做什么.

如果你还在谈论 L6474，你真的不需要和它说话，除了设置或者在用标志引脚发出错误信号的情况下，甚至可以与其中之一共享标志引脚限位销

@J-Dunn：该 ISR 时间注释引用了支持的最大 30kHz 步进频率。如果您预期的最大步进频率较低，例如 5-10kHz，这很常见，您会没事的。

chamnit，谢谢，这澄清了。我想看看在不降低规格的情况下可以做多少..

@langwadt, 是的，这是 L6474 上关键的错误处理。除非你每次发生什么事情都要做紧急停止，否则你需要与 GRBL 运行进行相当多的沟通。Uno 可以用堆叠的三块 L6474 板（禁用中断）做的最好的事情是大约 20us 从一块板上获取状态字。

您需要这样做三次，以找出哪一个（哪些）升起旗帜以及为什么以及哪个（如果有的话）已经进入 HiZ 并且不再驾驶任何东西。

在某些情况下，例如热警告，可以在不丢失计数器和不弄乱工件的情况下执行软停止或其他补救措施。其他情况，比如一名司机进入 HiZ 状态需要在 GRBL 在其他轴上执行足够的步骤之前紧急停止，从而使工作变得一团糟。

这些芯片提供有用的诊断水平。我试图看看这可以在 GRBL 中得到多大程度的利用，尽管它可能正在推动 Uno 的极限，但这也是移植到 STM32f4 的准备工作，在那里可以完全处理它。

我目前的策略是在 ISR 中设置一个全局变量来响应 FLAG 引脚并尽快让开，然后不间断地启动 SPI 对话，让 GRBL 进行 gerbling。

如果它是硬错误条件，我会将其视为硬限制引脚：设置警报状态等。可能需要大约 50 us 的非 GRBL 时间才能达到该决策点，这就是为什么它不能在情报服务侦察员。根据上面的内容，在最坏的情况下以最快的速度大约需要 7 个步骤。由于这些可能是微步，因此应该小于一个完整的电机步。5mm 丝杠上的 200 步进电机的线性运动约为 25 微米。

我正在考虑在读取传入 Gcode 的字符解析循环的顶部为非中断部分提供服务。这是一种可靠的方法还是存在不再被阅读的情况？

谢谢。

@langwadt，顺便说一句，您的位爆炸代码需要多长时间才能从三个 L6474 的菊花链中获取状态？

不记得确切我认为大约 35us。Afaict 3*L6474 状态读取的数据表限制为 ~17us

谢谢。我已经将它降低到 18us，包括一些循环开销和设置 cli() 用于计时目的以停止 grbl 跳入。我正在用 NOP 标记时间而不是等待 SPIF 标志。这大大改善了它。
如果我能负担得起代码空间，一次执行三个 getParam() 应该比该值的三倍更快。所以我上面的最初估计似乎是正确的，应该提供足够快的决定来防止重大的切割错误。

问题是从哪里调用 get_3_status()。外部和引脚更改 INT 的优先级高于 GRBL 定时器，我不想在 GRBL 中引入 50us 的抖动。理想情况下，这只会放在优先级较低的 ISR 上，但我不想开始重新组织成熟且经过良好测试的核心代码。

似乎 GRBL 中主要的非 ISR 代码循环是读取串行输入的循环，但我对 GRBL 的了解不够深入，无法知道是否存在某些情况，例如缓冲区已满，无法依赖它来提供服务故障情况。

欢迎提出建议。

见鬼，我让事情变得比实际情况更糟。大约 19us 的爆炸可以一次返回所有三个状态词。因此，如果 GRBL 在 30kHz 时有大约 8us/33us 的死区时间，下降到 20kHz 意味着 25us/50us 足以舒适地完成 SPI 和服务于主要的 GRBL ISR。最坏的情况是，在相对不常见的非关键错误标志条件下，它会导致 GRBL 时序出现 20us 抖动。

无需设置全局标志并在以后进行处理，都可以在 ISR 中完成。

我仍然更喜欢按正确顺序排列任务优先级，但使用 INT0 应该可以正常工作并且只会稍微降低最大 GRBL 速度。

感谢您的意见，这看起来接近完成。