注释
@J-Dunn: 是的。这是有充分理由的。打印和发送消息的时间太长。 |
啊是的,我忘了我读过那条评论。
是的,我可以看到如果 128 字节缓冲区已满,宁愿加载处理器! 也许这可以以更有效的方式完成。GRBL 中有一些非常清晰、优化的代码,这一点似乎有些杂乱无章。(那里有很多 TODO,所以我需要一些帮助。) 是否有一些基本的、非中断的步进代码被这个循环阻塞了? 测试:设置一个轴运行并在恒速段期间发送一系列几个 $$ 命令,因此不调用 st_prep_buffer()。示波器显示所有步进脉冲停止。我显然遗漏了一些东西,但我不明白为什么即使非 ISR 代码被锁定在 serial_write() 的 while 循环中,步进中断也不会完成它们的工作, 谢谢
这很好,但似乎无法解释为什么它会在不需要重新计算的恒速段上冻结步进脉冲。 |
深入了解 TX 阻塞,我发现了一个小的代码大小增益:
12 个字节。每一点都很重要;) |
@J-Dunn: 感谢代码提示。 |
别客气。;) 快速指针会有所帮助。 |
@J-Dunn:请参阅 serial.c 中的第 91 行。 |
谢谢,我意识到这是目前缓慢且低效的,我可能会写一些东西来至少一次处理 PGMstrings。但我仍然希望在每个 TX 字节之间至少从定时器获得一个脉冲,但它似乎完全阻塞。 一旦它处于恒速段,定时器不应该继续发射并脉冲 STEP 输出吗? |
除了串行输出!
所以 st_prep_buffer() 需要每 40 毫秒调用一次,并且在主线程中被阻塞:
我会考虑重构它是否值得。 |
如果机器正在移动,发出 $$ 请求会得到“not idle”响应。为什么?
那里似乎没有任何无效且独立于轴运动的内容。OTH,在相关轴的移动过程中,任何以 $ 开头的参数设置命令都可以合法地被拒绝。
在手动控制期间,能够在可能较长的运动期间询问机器参数作为确认或作为编写进一步命令的前奏是有用的。$$ 拒绝只是对所有 $ 命令的一揽子阻止,还是有原因?