关于EEPROM写入的问题 #165

109JB

我正在使用 [VER:1.1f.20170324:] [OPT:V,15,128] 并打开回声。这是在带有 16U2 USB 串行芯片的 Arduino UNO 克隆上。

在处理我的 GUI 时，尤其是更新 grbl EEPROM 设置的代码时，我遇到了一个我认为与 EEPROM 写入延迟有关的问题。我的代码的工作方式是从表中读取每个 grbl 设置，如果用户更改了值（与当前 EEPROM 值相比），它会使用发送-响应协议将其发送到 grbl。发生的事情是发送的一些行被截断了。例如，在一次尝试中，发送的行是：

$100=315
$101=315
$102=315

带有“ok”和错误响应的回显响应是：

[回声：$100=315]
好的
[回声：$101=315]
好的
[回声：$102]
错误：3

如果更改了许多设置，则可能会截断几行。在许多尝试中，被截断的行是完全随机的，被截断的字符数也是如此。如果我在获得“ok”响应后人为地添加 50 毫秒的延迟，那么一切正常。我相信正在发生的事情如下；

我相信正在发生的事情是 GUI 收到“ok”响应并发送下一行，但是 grbl 在接收下一行的中间开始为上一行写入 EEPROM，并导致截断当前接收的行。所以有几个问题：

你认为我所描述的是实际发生的事情吗？
是否在 EEPROM 开始写入该值之前发送了“ok”响应
如果问题2的答案是肯定的，那么应该是这样吗？或者应该在 EEPROM 写入完成后出现“ok”。
有没有办法知道 EEPROM 写入何时完成？

香奈儿

@109JB:

不确定发生了什么，但我认为这可能与“回声：”或您的 GUI 如何处理回声消息有关。我经常流式传输设置以快速配置 Grbl 以调试报告的问题。在调用“-s”简单流标志时，我在使用 Python 流脚本时从未遇到过问题。如果您在没有启用回显的情况下仍然遇到此问题，请尝试使用 Python 流式脚本。如果您可以在那里重现此行为，请将您的流文件、构建信息和设置发送给我。
否。EEPROM 写入处于阻塞状态，并且只会在完成后发送“ok”响应。您可以在 setting.c 中看到这一点。
不适用
当您收到“确定”时。

109JB

有趣的。我将深入研究，看看我能找到什么。

双中心

我遇到过同样的问题，因为至少 0.8…多个连续参数写入导致错误。我们通过使用 $RST=* 命令重置为出厂默认设置来解决这个问题。在“$RST=*”出现之前（1.0？），我们使用基本的写/读/验证来确保每个参数实际上都设置正确。我们的第一遍写入率约为 95%…这意味着在写入 20 个参数后有 65% 的机会出现写入错误。

我们的协议与您的不同，因为我们只是每次都重写所有内容（即我们没有首先检查参数是否不同）。我们注意到，当要写入的参数等于已写入的参数时，错误率会大大降低。我不确定为什么会这样，但总而言之，我们通常必须将所有数据写入 2 或 3 次才能正确写入。

正如我上面提到的，当 $RST=* 命令出现时，我们停止了批量写入参数，尽管这确实需要您在编译之前设置所有参数。

有可能我刚刚报告的底层参数写入错误是相关的。

arkypita 提到了这个问题 2017 年 8 月 30 日

GRBL 对 $$ 设置的评论 arkypita/LaserGRBL#86

关闭

关于EEPROM写入的问题#165

注释