让模拟器在 dev 分支上工作 #386

密歇根

我已经搞砸了一些，并且一切正常。大多。我认为。

由于在将处理的粒度/范围从块切换到段时进行了更改，所以从 protocol.c 中有更多的 protocol_execute_runtime() 调用不会被模拟器版本拦截。这会阻止模拟器在第一个块被缓冲后调用 spindle_run() 期间调用 ISR(TIMER1_COMPA_vect)，因为它开始在从不调用 protocol_execute_runtime() 的拦截版本的代码路径中循环。因此，我正在寻找用于注入对 ISR(TIMER1_COMPA_vect) 的调用的备用拦截点。

我有点困惑，因为模拟报告的完成时间似乎是边缘分支模拟器上运行的完成时间的一半。如果我正确地解释了事情，中断调用之间的定时器间隔是按段调整的，而不是保持基于 30kHz 的恒定值。所以我预计总持续时间会有一些变化，每段间隔会有更多变化；但这超出了我所能接受的范围，而且接近一半的事实让我觉得我错过了什么。我需要将我的控制器从 9a 更新到 9d 以复制实时设备上的运行时间。

为了计算 ISR 间隔，我将 OCR1A 链接到一个模拟器变量，该变量随后用于计算每次模拟器调用 ISR(TIMER1_COMPA_vect) 的运行时间。

在 sim/avr/interrupt.h 中：

extern volatile uint16_t ocr1a;
#define OCR1A (*(volatile uint16_t *)(&ocr1a)

sim/avr/interrupt.c:

volatile uint16_t ocr1a;

这导致 ocr1a 在调用 ISR(TIMER1_COMPA_vect) 期间采用在 stepper.c 中设置的值：

OCR1A = st.exec_segment->cycles_per_tick;

我对 TCCR1A 和 TCCR1B 做了同样的事情，以允许预分频器设置可能存在差异，并根据我认为正在发生的情况检查这些值。

此外，新的定时器是 16 位的，而不是 8 位的，所以预分频器（通常）是关闭的（相对于定时器改变之前使用的 1/8 预分频器。）

我将 TIMER1 的 ISR 间隔计算为：

double interval = (ocr1a + 1) / ((F_CPU / prescaler) * 1.0);

密歇根

时间问题看起来是由于块缓冲区不足和模拟提前终止造成的。

jgeisler0303

我还没有时间研究新的开发者。也许这个周末我能抽出时间。
同时这里有一些提示：

protocol_execute_runtime() 真的应该被模拟器在调用它的地方拦截
在 0.7 中，定时器周期时间用于在加速斜坡期间定期更新。因此，在 0.7 的模拟器代码中，您应该找到用于从定时器寄存器变量恢复周期时间的代码（也许您必须从 timer0 适应 timer1 配置细节）。
不要让明显的相关性（模拟时间的一半）欺骗您。尝试使用 printf-debugging 缩小问题范围以了解发生了什么。（这仅来自我在错误搜寻方面的个人经验）。

密歇根

我的计时器更改看起来很好（本质上只是更新虚拟变量定义，以便它们在运行时可写）。

我的最后一条评论是在将输出中打印的坐标与 9a 模拟器的相同输出进行比较后发表的。我注意到它在中途停止调用定时器中断程序。所以，计时器数学是准确的……对于调用 proc 的次数。我将测试文件中的 gcode 加倍，看起来它在与作业结束相关的大约相同点停止处理，这就是为什么我怀疑问题源于缓冲区的填充/评估方式。随着添加了段缓冲区的新循环层，时间必须有所改变。

我正在使用 CodeBlocks 和 gdb，虽然从 protocol.c 外部对 protocol_execute_runtime() 的所有调用都将转到拦截版本，但从 protocol.c 内部的调用将直接调用它。那就是如果我信任调试器。

我会一直弄乱它，直到我发现我犯的任何简单的错误都会破坏东西。如果您想在本周末查看我的进度（或损坏），我可以稍后提出拉取请求。