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

[Markus Hitter]

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.

What Teacup now does is to do acceleration calculations (square root!)
in a separate timer firing every two ms. In case the step interrupt
happens more often than  every 2 ms, acceleration isn't always updated,
so you accelerate in stair-steps, but with this happening 500 times a
second, you're easily close enough to physics. This 2 ms trick raised
the possible step rate from 16 kHz to about 42 kHz (currently not sure
what's limiting this, there are very occasional dropouts for several ms
beyond top speed).


The thing I'm after is look-ahead, though. Look-ahead is joining two
movements without stop in between. This is tricky, because switching
from one movement to the next consumes extra cycles, of course. It
basically works with listening (smooth sound) to the steppers and
printf-debugging being the only tools at hand, but not always perfectly.

Also, Teacup does integer maths only, so you often run into variable
overflow issues. That's where a simulator shines, because when compiling
the same code for an 64-bit i386 host (works already), these things are
simply different.

And then there are more advanced features like stepping not only the
fastest stepper, but all of them /evenly/. The Bresenham algorithm has
it's limits. The ATmega not featuring four 16-bit timers, too.



>> - How would I set up a connection between the UART and a serial
>> terminal/another application, using the (interrupt based) UART handling
>> code of the firmware? UART interrupts can undoubtly have an influence on
>> smooth operations on the real hardware, so this should be part of the
>> simulation.
> 
> Well, either special_output_port or special simulavr "UI" protocol
> over TCP. Never tried that, too awkward.
> 
>>
>> - I see the usage of special_output_port and similar things in
>> http://www.nongnu.org/simulavr/intro.html#simple-example . Does this
>> change the actual code, like in "this requires distinct compilations for
>> the simulator and for the real hardware" or like in "this can change the
>> firmwares' behaviour or timing"?[1]
> 
> Yes, you would need to modify your firmware, this would mean another
> build target for your firmware. It would delay execution by one or two
> cycles per byte send, plus the cycles to format the string.
> 
>>
>> - 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.

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. :-)


Thanks for the help,
Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.reprap-diy.com/
http://www.jump-ing.de/