Re: [Simulavr-devel] Howto UART, howto record pin behaviour

[Petr Hluzín]

On 14 November 2013 00:47, Markus Hitter <address@hidden> wrote:
> Am 13.11.2013 23:27, schrieb Petr Hluzín:
>
>> Does your firmware use timer interrupts at 40 kHz and calculate
>> whether to produce new steps in the ISR?
>>
>> I think that grbl firmware does that. I was wondering if it were more
>> efficient to pre-generate a buffer of approx 80 steps (2ms) in advance
>> - not in interrupt - and then apply a next step in ISR each time when
>> it fires; and keep filling the buffer on the background. This way you
>> would save cycles setting up variables the interpolation function. The
>> buffer could have 1 byte per step. In fact you could probably use
>> timed DMA of ATxmega chips and avoid the inefficiency of interrupts
>> entirely.
>
> First, I'm well aware of GRBL, it's sort of a friendly competitor to
> what I'm doing. My work is Teacup firmware and I hope I found a better
> solution. At least Teacup outperforms GRBL slightly while still doing
> linear acceleration; GRBL accelerates non-linearly.
>
> There's the step interrupt, which decides which motors to step and which
> not. These four axes have to run in sync at different speeds, after all.
> Other RepRap firmwares and GRBL also do acceleration calculation there,
> which means recalculating the time interval between two steps. Each
> interrupt re-setups the timer to adjust to the new timing.
>
> Calculating something in the background doesn't help, because if these
> calculations are not ready in time, you're hosed. Accordingly you can do
> them right where you need them. If you're keen on smooth UART handling
> (another interrupt), you can simply enable interrupts from within the
> interrupt after firing the steps.
> ...

Well, I am trying to say that if you have to do 40k calculations per
second then it is more efficient to do it once (I mean occasionally),
because it takes some time to start and set up registers for the
algorithm that does the calculations. Starting the algorithm over and
over is not efficient. You just have to make sure that other
interrupts are not long and cannot starve the background calculations
for more than few ms. (Second effect is the stepping ISR will be one
simple function and compiler will need to save/restore fewer
registers.)

>>>
>>> - Last, not least, how would I record I/O pin changes into a .vcd file?
>>> How would I define which pins are recorded?
>>
>> Simulavr code does have code that indicates this capability, however I
>> think it was either something different or maybe I failed getting to
>> work so I started my own implementation of value-change-dump tracing
>> two years ago. I think I aborted my attempt, but I could search my
>> disk.
>>
>> You mean VCD files for e.g. GTKWave, right?
>
> Yes, I mean GTKWave. And somehow I can't (yet) imagine what's so
> difficult on this. In a simulator it should be trivial to check a couple
> of bytes after each CPU cycle.

Adding the code to the appropriate places would be easy. I think I
gave up on vagueness of specification of the format, or maybe GTKWave
was not good enough for my needs or similar boring reason. It was not
that I would had exhausted all possible approaches.

Adding a check after each cycle is a poor idea, there are ton of
features that could possibly check for something at each cycle and
they all add up. Instead I was thinking about recording the pin change
immediately when the pin changes and probably delaying the printing to
file until cycle is finished. It is not straightforward since multiple
pins can change in one cycle, possibly on several ports.

>
> Before trying with SimulAVR I tried simavr and it could do such things.
> Well, at least in principle. As soon as one did things not done in the
> examples, there was simply zero support. Stepper timers simply didn't
> fire, serial connections stalled after a few seconds. Code has a clear
> emphasis on eye-candy and developers, well I found year old bugs with
> patches not committed lying around. This brought in some sort of
> mistrust, the entire point of a simulator is reliability, after all.
>
> Looks like there's more work ahead. Especially on documentation. :-)

I fear that some of this is similar here.


-- 
Petr Hluzin