For now this is just a number of different configurations and a
makefile target, "make regressiontests", to build with them.
Further tests, e.g. using SimulAVR or the hostside simulator
to check actual behaviour of the firmware are welcome.
This was previously made obsolete in the firmware code already.
See previous commits.
This should solve issue #138.
In case it ever turns out this was a poor decision, it's likely
a good idea to re-add this to the board configuration instead of
the printer configuration.
Debug stuff is meaningful for developers, only. Also often
enabled on a per-file basis depending on the problem at hand.
Two reasons to remove it from Configtool and one reason to
remove it from the config files.
This should solve issue #137.
These are no longer needed, as they're now created on the fly by
Configtool.
Also pick unique information from there over to Configtool, see
the change in configtool/addsensordlg.h.
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.
It was certainly a good idea, but also always a suspect of
malfunctions and as such, almost never used. Newer code
organisation moves most of the code behind it to dda_clock()
anyways, so it also became mostly obsolete.
Rest In Peace, STEP_INTERRUPT_INTERRUPTIBLE, you were matter
of quite a number of interesting discussions and investigations.
Changes for Configtool by jbernardis <jeff.bernardis@gmail.com>
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!
There's nothing special about this config.h, it's just the one I
happened to use for first profiling investigations. To allow
everybody else to do the very same profiling runs, I add it here.
Doing profiling isn't too complicated:
mv config.h config.h.backup
ln -s testcases/config.h.Profiling config.h
git checkout -b work
git cherry-pick simulavr # add tweaks convenient for simulation runs
make
cd testcases
./run-in-simulavr.sh short-moves.gcode smooth-curves.gcode triangle-odd.gcode
After being done you can restore your config.h and delete this work branch.
Currently, performance is as following (with convenience commit applied):
SIZES ATmega... '168 '328(P) '644(P) '1280
FLASH : 20270 bytes 142% 66% 32% 16%
RAM : 2302 bytes 225% 113% 57% 29%
EEPROM: 32 bytes 4% 2% 2% 1%
short-moves.gcode
Statistics (assuming a 20 MHz clock):
LED on occurences: 888.
Sum of all LED on time: 279945 clock cycles.
LED on time minimum: 306 clock cycles.
LED on time maximum: 722 clock cycles.
LED on time average: 315.253 clock cycles.
smooth-curves.gcode
Statistics (assuming a 20 MHz clock):
LED on occurences: 9124.
Sum of all LED on time: 3297806 clock cycles.
LED on time minimum: 311 clock cycles.
LED on time maximum: 712 clock cycles.
LED on time average: 361.443 clock cycles.
triangle-odd.gcode
Statistics (assuming a 20 MHz clock):
LED on occurences: 1636.
Sum of all LED on time: 546946 clock cycles.
LED on time minimum: 306 clock cycles.
LED on time maximum: 712 clock cycles.
LED on time average: 334.319 clock cycles.
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.
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
jbernardis
Erik Jonsson