修复了替代配置中的模拟器。 #441

@ashelly: 感谢您的努力！

别客气。这主要是出于自身利益——我想通过某种方式在我每天乘坐火车时测试我的 grbl 客户端。

我真的很欢迎反馈。这个版本理论上比旧版本对实际硬件更准确，但由于它几乎实时运行，它也更慢。我想看看这是否会影响其他用户。（而且我很想听听关于加快批处理模式的想法——我的尝试收效甚微。）

@ashelly: 自利是一个很好的动力。:) 这几乎就是我过去几年一直在开发 Grbl 的原因。大多数其他东西都是乱七八糟的。也不是说 Grbl 是完美的，但至少我有一些控制权，并且可以说它是如何以一种有意识的方式进行的。

我还没有机会使用你的代码，但我对 sim 代码本身也不是很熟悉。这是延斯的领地。@jgeisler0303您有时间看一下新的 SIM 卡代码并就此发表一些评论吗？

今天早上我正在使用 .9f。我花了一些时间在 .9a 上，现在我已经跳到 .9f 了。我在 Delphi 中创建了自己的界面，并意识到 F 发生了很大变化，我不得不调整我的界面。大家都用什么直接发文件给这个？是环球还是别的？.9A 有点挂断了我，所以我想看看 .9f 是否有同样的问题。如果是，那么我知道这是我的界面。我还下载了测试 Gcode 文件来玩。

好的，我试试看。我应该检查 dev 上的当前 HEAD 吗？

@jgeisler0303： 谢谢！dev 分支不再存在。一切都被推送到边缘分支，那里一切都是最新的。

现在我第一眼看到了，我必须说我印象非常深刻！仅提及几件事：

• 两个独立线程的想法很棒，也很好地实现了
• 您在轻松跨平台方面做得非常出色
• avr 代码和作为模拟器基础的模拟器之间的分离经过深思熟虑并且非常通用，它可以独立成为一个项目
• eeprom文件非常方便

我也用 MinGW 编译模拟器没有问题。但似乎只听控制台，所以重定向或管道kbhit()不起作用。因此该示例不起作用。我尝试使用if是一个重定向文件进行快速修复，但这不适用于管道，因为流可以间歇性地运行为空，我相信在这种情况下会返回。要么我为此找到解决方案，要么我将在接下来的几天内提交我现在拥有的内容。getch()stdinsim.batisatty(fileno(stdin))getc(stdin)stdingetc(stdin)EOF

实时功能可能非常有用，但我对 grbl_sim 的初衷是想办法快速获得准确的刀具路径。所以，如果有“比实时快得多”的选项就好了。所以我改变了tick_rate=0;（顺便说一句应该声明为 float，否则 atof 没有多大意义）和simulated_ticks+= F_CPU; //as fast as possible. 但这并没有多大帮助，这很奇怪，因为我有一台非常快的机器，计算和比较timer_interrupts();应该不会花费太多时间。你知道如何使用分析器吗？

F_CPU/1e9*(ns_now-ns_prev)*sim.speedup;我也很好奇实时功能是如何工作的，并为with插入了一个 printf sim.speedup= 1;。它总是成千上万，这很奇怪。因为要么模拟器能够比实时更快，在这种情况下，模拟器有时必须做一些空闲轮次 ( F_CPU/1e9*(ns_now-ns_prev)*sim.speedup==0) 来浪费时间。或者模拟器无法实时运行，在这种情况下F_CPU/1e9*(ns_now-ns_prev)*sim.speedup;应该不断增加，因为它无法跟上每真实纳秒的必要滴答声。或者我弄错了什么。或者platform_ns();在 Windows 中没有按预期工作——也许只报告在该任务中花费的时间？

无论如何，伟大的工作，绝对是要走的路！稍后再打给你。

@jgeisler0303，感谢您抽出宝贵的时间来查看此内容，并提供如此好的反馈。

很抱歉在 MingW 上破坏了 sim.bat – 我以为我已经测试过了，但显然没有。
修复它的一种选择是platform_poll_stdin 默认使用您以前的代码：

if((c = fgetc(stdin)) != EOF)

并且仅kbhit在连接到交互式终端时使用（自动检测到或使用命令行选项设置）。

关于比实时更快的速度。我不得不承认，它也没有按我预期的方式工作。在您发表评论后，我回去再次查看了它。我尝试了您提到的相同印刷品并得到了类似的结果：~1800。1800 滴答声 / 16MHz = 112 微秒/ sim_loop. 当我增加这个speedup因子时，它比线性上升得更快，直到它变得非常不稳定。

我认为正在发生的事情是它可以跟上实时，但没有太多余地。完成一个循环有最短时间。它至少可以在那个时间内模拟相应数量的arduino CPU ticks。但是当你增加speedup因子并要求它做更多的报价时，执行循环需要更长的时间，这会增加下一个循环要处理的报价。在某些加速因子下，它变得不稳定。最终整数溢出限制了它被要求做的最大滴答数，所以它永远不会冻结。但它也从未真正显着加速。

我将尝试一直在 float 中进行计算，并试验实际的最大模拟速率是多少。我做了有限的分析，据我所知，它大部分时间都花在循环的最外层测试上，等待有趣的事情发生。

如果它太慢，我可以通过跳过滴答直到下一个中​​断来尝试使计时器代码更智能，或者可能通过恢复一些确保模拟器保持赶上计划线的钩子来以不同方式处理非交互模式。

@ashelly，不用担心 sim.bat。我认为fgetc(stdin)是阻塞的，因此只适用于在 EOF 之前不会运行为空的重定向文件。对于管道，它会阻塞模拟循环。管道对于在 UGS 等馈线程序中使用模拟器很方便。从我想读到的，检测管道流上是否有可用字符是可能的，但不是那么容易/干净。可能最适合单独的输入读取线程。有了你美丽的抽象层，这甚至可以在 platform_WINDOWS.c 中被概括。

出于好奇：我认为 ^-F 发送一个 EOF，因此从最终调用到fgetc(stdin)重定向文件读取和使用 EOF 将干净地终止模拟器。

您对实时行为的发现正是我所期望的。有趣的是我们的两台机器都能够跟上实时。很奇怪，外层循环竟然要消耗这么多时间来计数和比较。但我不会在预测下一次中断时间的算法上花费太多工作。如果不同的计时器异步运行，这可能会变得很糟糕。

也许比实时更快不再那么重要，因为 UGS 具有图形预览。我不会重新引入那些使模拟器如此依赖 grbls 内部工作的钩子。但这只是我的三分钱。

你如何分析？你能告诉我一本关于使用 gcc 进行分析的入门读物吗？

@jgeisler0303 @ashelly: 仅供参考，我将在周末更改 Grbl 设置编号以及反转遮罩的工作方式。我这样做是为了让未来的扩展更容易、更有条理。这会影响您的模拟器代码吗？我不打算再做这样的事情，因为这是永久性的改变。

重新编号设置不会破坏任何东西。它的行为就像硬件在闪烁新代码后第一次一样——CRC 不匹配，因此它会重新加载默认值。
我认为反转掩码不会成为问题 – 重要的是实际写入端口的值。（而且我实际上并没有监视那些，尽管我想，如果我解决了速度问题）

@jgeisler0303，关于输入，我认为最简单的事情可能是从阻塞输入切换到非阻塞输入的命令行参数。旧式阻塞输入似乎适用于批处理模式。
我不认为^-F发送EOF. 我在输入代码中添加了一个特定的处理程序来处理^-F，EOF因为非阻塞输入从未生成过。

对于基本分析，我使用了 perf tools。 perf record ./grbl_sim.exe < HelloWorld.nc其次是perf report。

我今天做了一些进一步的研究。我使用 gprof，gcc 内置的分析功能（由-pg编译器和链接器的命令行参数激活）。它告诉我运行 HelloWorld.nc 的执行需要大约 360 秒。这不是挂钟时间。可悲的是挂钟时间更像是 10 分钟。

经过一些优化后，我设法将执行时间缩短到 200 秒，但挂钟时间仍然在 3 分钟左右。我不记得我所做的一切，但它主要是在 sim 循环中内联所有内容，并通过等待事件机制替换两次睡眠调用：如果serial_read()检测到一个空的接收缓冲区，线程将被挂起，直到发生唤醒事件发生。当模拟循环推送新角色时会触发此事件。但我觉得这并没有多大帮助。

我尝试的一切都是快速而肮脏的，等待事件机制仅适用于 Windows。所以我不会推动任何东西。

最糟糕的时间杀手仍然存在。我只是不明白为什么需要 6 分钟。用于在执行时间仅为 3 分钟时运行仿真。它运行的机器是四核的。我很确定 grbl_sim.exe 有一个单独的 cpu。

最后是我的最后一个随机发现：我的 3GHz 机器将有 187 个周期用于计算，以实时模拟 16MHz 的三个 atmega 定时器。考虑到 x86 CPU 平均每条指令可能需要一个以上的周期，这并不算多。我估计定时器模拟很容易每次调用 200 条指令。如果这一切都是真的，那么这个概念根本不可能实现比实时更快的速度。（这让我意识到在带有适当外围设备的 RISC CPU 上，你可以从区区 16MHz 获得惊人的能力）。

干得好，坏消息……
我想接下来要做什么取决于人们使用模拟器的目的。如果需要比实时预览模式更快的模式，则必须有一种方法可以通过简化计时器 sim 来实现。我现在正在试验一些东西。对于我们这些需要它的人来说，仍然可以选择近乎实时的精确模拟。

@ashelly：最近我一直在与 Chilipeppr 的 John Lauer 讨论一个想法。我需要将 Grbl 的一部分编译为可执行文件。我需要做些什么才能在 Mac 上编译它吗？我试图编译为 Linux（它应该在 Mac 上工作），但它正在寻找一个仅限 Windows 的文件。

我无法轻松访问 Mac，所以我不确定。当我PLATFORM = LINUX在 ‘sim/Makefile’ 中设置时，我正在使用 gcc 在 Unbuntu 上成功编译。
它抱怨哪个文件？

@ashelly：啊。通过更改 Makefile 中的该参数来修复文件抱怨，但不会编译到 Mac。我将启动 Windows 虚拟机。谢谢。