你正在做的事情看起来应该对我有用，但我自己还没有尝试过。Sonny 可能是为数不多的对代码有足够了解的人之一，但他很忙，不能花太多时间来帮助解决这种分心的问题。

当您正在处理听起来像是高度定制的版本时，这可能会引入我们不知道的各种复杂性，我建议您采用标准的 1.1f 代码（最好是在 328P 上）并进行最小的更改来测试这个一点逻辑。

顺便说一句，如果这是由按下按钮触发的，您是否实施了某种去抖动和反重复处理？否则，您可能会在释放按钮之前多次设置该覆盖标志。

谢谢@electrokean. 我很忙，但我仍在尽力回答问题。

@dastultz: 你在做什么应该工作。我不清楚为什么不是。它不应该的唯一原因是新计算的覆盖与当前的覆盖没有什么不同，或者您正在中断内调用 protocol_execute_realtime() 函数（这种方式不起作用）。

我正在轮询主循环中的按钮，不涉及中断，并且正在对它们进行去抖动。

如果你说它应该有效，那么我会坚持下去。给我一个星期的时间来解决这个问题，我会用我的发现更新这个问题。

谢谢。

好的，我发现代码确实有效，但它非常参差不齐，所以我一定是早些时候错过了它。如上所述，我从protocol_main_loop轮询按钮、锅和设置灯的地方调用自己的服务例程。它非常适合慢跑，反应灵敏。但是一旦我开始一个循环（通用 G 代码发送器），似乎我的服务例程被调用 FAR 的频率降低了，这可能是因为系统非常忙于运行，但也可能是因为它主要在定时器和中断上运行？

当然我可以在中断时设置我的按钮，但是去抖动要复杂得多（对我来说）。是否有一个安全的定时器中断例程，我可以利用它来调用我的服务例程？

感谢更新。执行可能暂时不会回到主循环。如果它已满并且在添加下一行动作之前必须等待它清空，我可能会被规划器阻止。参见 mc_line()。