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

[Petr Hluzín]

On 13 November 2013 22:05, Markus Hitter <address@hidden> wrote:
>
> While I filed a bug already, I'm new to this list, so:
>
> Hello everybody!
>
>
> The last two days I searched the net up and down to find out how I can
> fit SimulAVR into my task. I found quite some stuff about installation
> (http://www.nongnu.org/simulavr/ looks excellent), but almost nothing
> about using SimulAVR for anything else but attaching GDB.
>
> What I want is to simulate the stepper motor driver part of a RepRap (3D
> printers!) firmware to watch and improve the timing of the steps done.
> Lots of lengthy maths, lots of interrupts, performance only limited by
> processing power exhaustion. Looking from the ATmega (644, 644P or
> 1284P) side, a motor step is simply a raising flange on one of the
> digital I/O pins, so recording these would be awesome. Steps are timed
> between 0 and 40 kHz realtime and done in the millions, so gdb isn't
> exactly a good tool for watching these. All this should work well
> without custom hardware simulation, as there are no inputs other than
> the serial line.

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.

Just my two cents.

>
> Can I simply ask a couple of questions? Perhaps I'm missing the obvious.
>
> - Is installation of SimulAVR a requirement or is it fine to run it off
> the build location?

It is fine to run it without installation. You would not be missing
any feature, except maybe TCP or Python binding.

>
> - Is SimulAVR reasonably cycle-accurate? Like if two pin changes are
> recorded 835 clock cycles apart, does this reasonably reliably mean the
> same happens on the real hardware at a time distance of 835 * 20 MHz =
> 41.75 us?

Yes. Report a bug if it is not. (I broke that once or twice.)

>
> - 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?


-- 
Petr Hluzin