Now it waits for an "ok" before sending the next line, like all
the G-code sending hosts do. This allows sending arbitrarily long
G-codes. The 60 seconds simulated time limit is still in place to
avoid endless simulations.
The standard performance simulation now runs more G-code and
results in slightly different numbers accordingly:
cd testcases
./run-in-simulavr.sh short-moves.gcode smooth-curves.gcode triangle-odd.gcode
FLASH : 20540 bytes 144% 67% 33% 16%
RAM : 2188 bytes 214% 107% 54% 27%
EEPROM : 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 304 clock cycles.
LED on time maximum: 720 clock cycles.
LED on time average: 313.256 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 36511.
LED on time minimum: 304 clock cycles.
LED on time maximum: 706 clock cycles.
LED on time average: 349.172 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 304 clock cycles.
LED on time maximum: 710 clock cycles.
LED on time average: 332.32 clock cycles.
It was so far unnoticed that the "simulavr" program is only a
script when run from within the build directory. Still killing it
by name worked, because bash's exec didn't terminate the initiating
script.
Apparently this week Ubuntu updated bash and the new version now
terminates the initiating script (which is a good idea), but now
the executable to kill by name has a different name. It's prefixed
with "lt-". As this "lt-" is hardcoded we can rely on it.
Note by Traumflug: this
while read -r LINE; do
some commands
done << (some other command)
didn't work here (bash 4.3.11 on Ubuntu 14.04), so I had to swap
the sequence of these two commands for using a pipe. Anyways,
excellent idea, shortens some simulator runs drastically!
As it's still a bit cumbersome to go through the whole .vcd file
to find the highest delay between On and Off, do this search
automatically and output an statistics. Can look like this:
Statistics (assuming a 20 MHz clock):
LED on occurences: 838.
Sum of all LED on time: 262055 clock cycles.
LED on time minimum: 306 clock cycles.
LED on time maximum: 717 clock cycles.
LED on time average: 312.715 clock cycles.
This should give an reasonable overview of wether and roughly
how much a particular code change makes your code slower or
faster. It should also show up showblockers, like occasionally
huge delays.
BTW., the above data was collected timing the step interrupt when
running short-moves.gcode with the current firmware.
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.
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
Erik Jonsson