The idea is simple: if you want to time a portion of code
precisely, turn on the Debug LED (see config.h for
DEBUG_LED_PIN) at the start of sequence and turn it off when
done. Running this in SimulAVR, you have two flanges precise
to the clock cycle which exactly reflect the time taken to
run this code sequence. Ideally, you run this code n a loop
to get a number of samples, if it doesn't run in a loop anyways.
Time taken can then be measured in GTKWave. For convenience and
for a better overview, run-in-simulavr.sh also extracts all the
delays into it's own signal, so it can be viewed as an ongoing
number.
The nice thing about these save files is, they provide a display
for the data, so you simply load a .vcd, additionally read a
save file and you're ready to investigate your movement data.
- comment on why the case exists,
- add an M2 at the end to later allow automatic simulation stop,
- move comments to the end to avoid filling the serial buffer with
stuff unrelated to movements,
- make sure there's a line ending at the end of the file and
- use Windows line endings (they're more difficult to handle).
Moves which have no movement intention, e.g. pure feedrate changes,
and moves too small to cause a single step, are a bit tricky to
handle with lookahead. Essentially, they should be joined with the
next movement, without queueing them up.
This script also asks SimulAVR to generate pin traces of the X
and Y axis and even processes this data into a data file with
time, position and current speed of each axis.
Missing:
- Acceleration calculation.
- LOTS of polish.
Markus Hitter