Radu 一如既往地非常有效。事实上，我昨晚在将归位参数添加到运行时设置时就在考虑这个问题。我很快注意到，如果我要添加诸如工作空间体积、工作坐标偏移等内容，内存空间就会像自重一样快速被吃掉。我决定留下新的归位参数供人们修改。对于长期解决方案，而不仅仅是运行时和编译时设置，我在想我们可以添加另一组 EEPROM 按需设置。

因此，对于大多数这些设置，您只在非常有限的情况下需要它们，通常执行速度无关紧要，即工作坐标偏移、归位参数。我一直在想，我们可以创建另一组方法，仅在需要时直接从 EEPROM 存储和读取变量，并在完成时从内存中转储。如何有效地做到这一点是另一回事。我还在想办法解决这个问题。

我完全同意我们需要在编译时尽可能多地保留，只要新用户不需要更改它们来试验 Grbl。诸如加速度、每毫米步数、进给率、步进参数等之类的东西都需要在那里，任何人都需要在没有太多麻烦的情况下第一次让 Grbl 运行。如果他们喜欢，他们可以开始调整编译时设置。

今晚晚些时候我会确保将 G20/21 添加到默认设置。:) 但是，这也可能是按需设置的候选者。

还有一件事。当前系统状态（即 G20/21）与默认设置之间也应该有所区别。我想我需要在 Grbl 的状态报告功能中添加一个系统状态指示器，这样用户就知道启用/禁用了什么以及 Grbl 认为它在做什么。

我将使用 G20/21 的示例，但意味着包括所有此类状态变量，用户可能希望 (1) 更改其默认值并 (2) 在重新启动后保持不变。

我认为最紧凑的方法（就运行时大小而言）是（请不要笑）像 AUTOEXEC.NC 这样的东西存储在 EEPROM 中，并将这些变量设置为用户期望的初始值/想要。这适用于 G20/21、G90/91、G54 P、G10 L 等，并且可以在不加倍功能的情况下完成（这很昂贵，因为 RAM 和闪存对我们来说都是非常宝贵的）。
ATmega328P 有 1KiB 的 EEPROM（即 1024 字节），当前设置结构在 50 字节以下——有相当多的 G 代码可以放入，比如说 512 字节。

我不认为添加一个明确的默认指示器有什么好处（即“亲爱的用户，G20/21 当前设置为 G20 ，这是默认设置”），特别是如果我们要采用 AUTOEXEC.NC 方式（用户可以只需在需要时获取/编辑脚本）。

最后，关于为 EEPROM 访问编写代码，如果您将变量声明为EEMEM（类似于PROGMEMflash），avr-gcc 可以为您计算指针，但您仍然必须使用eeprom_read/write/update_*它来访问它（再次，类似于pgm_read_*）。这对于设置应该在 EEPROM 中结束的常量很有用，因为整个工具链都知道它（包括 avrdude）并且可以通过这种方式让您的生活更轻松。

这是一个好主意！我认为实施起来会更直接，对新用户来说也不会那么神秘。我一直在努力想出一个关于如何让用户设置其中一些东西的优雅解决方案。但是，我想知道是否有 g 代码不支持的东西。例如，归位启用、归位进给率等。我们用这些做什么？

无论如何，这肯定会解决某些人如何将他们的 g 代码模式和工作坐标设置和存储为默认值的问题。我们可以支持其中一些标题行，因此用户可以将他们一直保留的标题行 (G20) 和经常更改的标题行分开（甚至用于多个坐标系的 G10）。我确信我们可以将我们需要的一切塞进这 512 个字节。

至于指标，我们之所以需要这样的东西，主要是为了 GUI 和界面。由于这些不需要实时响应，我在想 g 代码解析器状态、工作偏移量、工具编号等内容可以通过一些特殊的 Grbl 命令（如“$$”）通过普通串行线输入来报告或“$G”。这不同于运行时命令“？” 这些需要报告实时数据，如定位等。

尽管我对处理一些新设置所需的额外 RAM 和程序闪存存有严重怀疑，但考虑到我对代码/当前使用的资源量并不十分熟悉，我无法对此发表评论。

不过，我可以告诉你的是，在为我的 CNC 查找基于非 PC 的控制器的过程中，由于缺少可用的运行时，我明确地传递了 grbl 的一些（至少其中一些更高级）分支设置。为了正确看待事情，我只需要学习 Python 并找出数学来计算由其端点和半径确定的原点和弧（我刚刚看到 grbl 也这样做 – 具有讽刺意味）仅仅是因为工具 我生成的 G 代码被证明在舍入方面存在轻微错误，EMC2 坚持不让我在不重新编译的情况下更改圆弧端点公差。幸运的是，我手边没有巫毒娃娃。

我实际上更愿意将所有不是通用常量的东西都配置在一个文件中，但显然这是为操作系统运行的芯片保留的；grbl 目前所做的对我来说是一个可以接受的妥协，但我想明确表示，我不会用十英尺的杆子接触将设置移动到编译时间的 grbl 版本 – 即使我完全有能力并且实际上打算编译我自己的 grbl 版本，我宁愿留在旧版本或不可逆转地分叉它，也不愿失去简单的可配置性。即使我只会将其中的大部分设置一次并且恰好一次。只是我的 0.02 美元…

关于提议的事情，我想知道访问 EEPROM 存储的“自动执行代码”的代码需要多少空间？不是解析它的人，而是将它传入和传出的人？以我的经验，所有“内置/模拟”文件系统最终都会成为一个低效的拐杖，之所以被使用，只是因为它实际上是不可避免的——就像一个运行网络服务器但没有操作系统的微系统中的假文件系统。我们真的要在 EEPROM 中植入（处理）其中的一个微型吗？

显然，“在 EEPROM 中包含 AUTOEXEC.NC”指的是存储上述文件的内容。FAT12 文件系统甚至放不下 512 字节 我建议存储一串 G 代码，我只使用文件隐喻来说明示例。

访问 EEPROM 的代码已经在 grbl 中，因此不会有大小损失。

我上面提到的大小损失与管理运行时设置的接口有关，而不是变量本身（它可能永远不会大于 4 个字节）。查看 settings.c，看看运行时设置的人机界面涉及多少字符串——这些字符串占用闪存空间，比变量本身多得多。

你好眨眼。重要的观点和担忧。并且，感谢您使用 Grbl。我们正在非常努力地工作，使它成为爱好者真正的 CNC 替代品，同时也可供新手使用。无论如何，让我更详细地解释其中的一些问题。

内存绝对是个问题。现在，Grbl 几乎用完了 2KB 的可用空间。其中绝大部分由规划器缓冲区填充，其次是串行缓冲区和 g 代码解析器。剩余的 ~0.5KB 留给其他所有动态运行的东西，比如弧线和规划器。如果我们在设置中添加一大堆 4 字节的浮点值（归位率、多个系统的工作坐标偏移等），这会消耗掉剩下的一点点，我们将不得不减少数量Grbl 可以做的前瞻块的数量来补偿。因此，当它们只需要很少访问时，将它们全部保存在内存中是没有意义的。

作为一个解决方案，Simen 和我离线交换了一些电子邮件，内容是关于如何安装一个单独的按需设置结构，该结构将在需要时从 EEPROM 读取。我需要详细了解它需要多少代码，而不是只将最少的东西保留在持久内存中。我认为利用现有的东西不需要那么多。现在，一切还没有最终确定，但 Radu 关于启动脚本的建议确实解决了很多必须存储和执行大量所需设置的问题。特别是通过减少对任何特殊输入、存储和读取代码的需求来设置这些单独的项目。

至于 EEPROM，我们有 1KB，但只使用了其中的 5%。我们可以毫无问题地使用至少 50% 的启动脚本命令，它应该存储大约 500 个字符的内容。绰绰有余。就代码大小而言，这根本不会花费太多。我们只需要知道内存地址和长度，将其读出，并在 Grbl 初始化时将其直接扔到 g 代码解析器中。很简单的。

最后，对于闪存，我们有大约 32K（我认为），我们使用了大约 70%。我们有很大的灵活性，但我们需要确保不会造成过多的膨胀。这样将来，当我们想要添加一些新功能时，我们就不会束缚自己。

我希望这能回答你们中的一些问题。而且我也同意编译的需要最少。每次您想调整某些东西时都这样做很麻烦。

@csdexter: 好的，这是一个不幸的选择——我知道你实际上并不希望实现一个文件系统；我想知道的是，与只允许访问更多设置的系统相比，允许下载和检索自动执行内容的系统的成本要低多少。我承认，我可能不完全理解你提出的想法的范围和优势，除了将 g 代码存储在 EEPROM 中的明显部分，该部分在启动时由现有的解析器自动执行。

关于 strings.c – 我看过；诚然，我还没有做一个准确的计数，但看起来几乎不超过几百个字节的字符。在过去的 1K MCU 时代，这本来是巨大的，但在 32K 微型计算机中，它不会对任何事情产生影响。

@chamnit: 非常感谢您对grbl资源的现状如此详尽的解释。有时我听起来可能很挑剔，但这不是我的本意，我非常感谢您和其他人在 grbl 上所做的工作。

我确实没想到 RAM 会那么满，显然我被我最近玩过的 Cortex 类微处理器宠坏了——而且，无可否认，我很少使用浮点数，所以经过任何缓冲区，我的变量往往会吃掉 RAM 而不是慢慢地。直接在 EEPROM 中访问变量确实不会有太大的开销，只需几条指令而不是一条指令。正如您所说，对于只需要不经常拉入和插入公式/变量（而不是连续访问）的事情，它应该可以正常工作。