1. 如果我假设我告诉过您查看并指出我之前的一些帖子，我在其中解释添加更多详细消息和运行时设置将如何耗尽闪存空间，有人会扔石头吗？
2. 由于我们已经有了流式脚本作为一种安全地将 G 代码数据发送到 grbl 而不会溢出其接收缓冲区的方法，我想我们可以使用将错误/状态代码转换为冗长字符串的逻辑来扩展它（脚本）用户阅读。这样，grbl 就可以发送类似ok S12 E1的内容，脚本可以显示完整的OK Machine moving, spindle running, X coordinate clipped.
3. 运行时设置也可以做同样的事情，去掉所有的帮助字符串并将它们移到脚本中。继续，验证/解析逻辑也可以移到脚本中，这样 grbl 就可以得到预先咀嚼的数据，而不是以$.

我的 2 美分，
Radu

PS 考虑到手头的任务（解析 G 代码并进行 CNC 移动），32kB 的可用闪存在优化方面是一个相当高的标准；我怀疑在这个领域是否还有更多的奇迹，除了用汇编程序编写整个东西。

1. 没有石头。:) 我第一次听到你响亮而清晰。我是一名
   科学家，我已经为自己找到了一些东西，但我
   齐心协力将闪存成本降至最低，并且仍然添加
   了我能添加的所有内容（在 v0.8c 中仅添加了 10-12%）。所以，我认为这个
   问题是关于什么可以走，什么可以留下的公开讨论，
   而不是把事情砍掉。

2. 至于消息，我觉得
   新用户进入和学习系统需要最少的反馈。我已经设置好了，这样
   Grbl 就可以用错误代码来回复 GUI 也可以解释。
   所以问题是：需要什么，不需要什么。我听说你有
   多少新消息。我也不喜欢他们，所以这就是我在
   这里提出来的原因。

3. $S 解析器设置的实际代码大小实际上非常
   小。它们可能只占闪存空间的 1-2%，其中
   大部分是确认和帮助消息。我一直在争论是否添加
   这些，但在看到你实际占用的代码空间有多大之后，
   我决定将它们留在里面。但这也有待讨论。

另外还有一个考虑，即 328p 也接近其
生命周期的尽头。它会再坚持几年吗？还是会出现更
强大、更便宜的硬件，让这一切变得毫无意义？不确定
。

还是我们现在就尽可能多地塞满东西，然后在空间用完时继续使用 MEGA？

我很想仔细看看究竟是什么占用了最多的空间以及可以做些什么，但不幸的是我现在正在工作中游到我的耳朵。关于消息反馈带来的“新膨胀”——到底是什么占用了空间，是代码还是字符串？如果是后者，我想人们总是可以对它们进行中世纪处理，将它们从 8 位压缩到 5 位，但当然这仍然会招致一些额外的非压缩惩罚，而且它们显然会在源代码中变得不可读。

顺便说一下，我确实同意非神秘的反馈很重要（而且不仅仅是对新手而言）。我不希望看到 grbl 变得“用户友好——只是对它的朋友是谁非常有选择性”；我认为那绝对是错误的目标。

我想我从你们两个那里听到了我需要听到的。我正在削减一些反馈文本，使其更加简洁，并将一些内容加倍。我也摆脱了“试运行”开关。有人告诉我，它并没有真正在工业中使用那么多，如果有的话，因为单块模式和进给率覆盖（即将到来）在这方面做得更好。空运行也会搞砸一些事情，并迫使我做很多不需要的 if-then 检查。

一如既往地感谢你们的投入。