@jasoroony：你确定吗？你是在 Arduino 上检查过还是只是看代码？

在进入紧急警报代码中的等待状态之前，有一个明确的 EXEC_RESET 标志调用。它应该在那里等待，直到用户发送了重置命令。

所以，现在有道理了——这不是在 Arduino 上，我试图在 LPC1768 板上工作（像大多数一样）不要将限制引脚放在中断端口上。我的轮询例程（重新利用限制中断例程）是触发循环退出的原因。我在该循环内调用它以及其他需要轮询的东西。

谢谢！

需要考虑的修辞问题 – 难道另一个限制中断然后在真正的 Arduino 上重置机器吗？

这很奇怪——我看到了阻止在已经报警的情况下在中断中设置第二个报警的代码。它现在根本没有多大意义 – 我将不得不进行更多调查。但是我并没有改变太多原始代码（并且按照我在第一篇文章中的建议对我来说确实有效）。

啊，没关系.. 这是我第一次在错误的地方进行投票。进入 protocol_exec_rt_system() 后，[only] 局部变量被分配给 sys_rt_exec_alarm – 如果我的第一个轮询调用在那之后（被调用的地方）立即完成，那么问题就出现了。将它移动到它修复所有问题之前。

带来不便敬请谅解。（哦，我知道轮询不是一个很好的解决方案 – 但我认为它总比没有好……实际上它还不错，现在就在这个 100MHz 芯片上运行测试，它很快就会停止。）

目前尚不清楚您在轮询什么以及何时轮询，但听起来您没有为硬限制使用中断。如果轮询速度足够快，它应该可以正常工作，但取决于是否始终如一地按时轮询。

我应该重新打开这个问题，但我会留给你来决定。经过一些需要的睡眠后，我现在相信我上面的用例已经准确地显示了真正的 Arduino 上的限制中断何时不安全并导致我首先描述的问题。它显示了 protocol_exec_rt_system() 中非常短暂的周期（少量汇编指令），其中在第一条语句之间，初始警报分配给本地，下一个状态分配给中断所在的本地（在警报测试 if 语句之后） （根据定义，这可能发生在那里，但不太可能）会导致不必要的重置。

我很高兴我在问题标题中加上了“可能”，因为虽然这不太可能 – 但我很确定它在理论上仍然会发生。

我想有可能在警报检查之后和重置检查之前发生硬限制可能导致它错过警报。幸运的是，这种情况的可能性非常小，并且由于 mc reset 调用，机器仍然会停止。

有几种方法可以解决这个问题，比如让这些检查成为原子检查。但我倾向于避免对任何主版本（如 v1.1）的代码进行任何重大更改。我还认为 Grbl v1.1 是该行的结尾。我正在为即将发布的 ARM 版本进行重大重构，其中包括状态机大修。我会确保在那里解决这个问题。

唔。很公平。由于它不影响我，我对修复无动于衷，但是您可能不会对许多生命周期结束的软件使用 20 年左右的时间感到惊讶。我也确信我真正的 Arduino 机器（我有一个！）已经意外地重置为最小值（从今天开始我不会因为考虑它而失眠）。相信我，虽然可以找到一个完美的地方，但不要在一些随机项目中进行一些所需的更改 – 它应该工作，但没有。