Our standard performance test is to run these three G-code files
in SimulAVR and recording step pulse timings. While this certainly
doesn't cover everything related to possible performance
measurements, it's a good basic standard to compare code changes.
Current performance:
ATmega sizes '168 '328(P) '644(P) '1280
Program: 19808 bytes 139% 65% 32% 16%
Data: 2191 bytes 214% 107% 54% 27%
EEPROM: 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 308 clock cycles.
LED on time maximum: 729 clock cycles.
LED on time average: 317.393 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 23648.
LED on time minimum: 308 clock cycles.
LED on time maximum: 726 clock cycles.
LED on time average: 354.825 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 308 clock cycles.
LED on time maximum: 719 clock cycles.
LED on time average: 336.327 clock cycles.
This allows to use EWMA_ALPHA in an #if clause, which is needed
for the next commit.
Review changes by Traumflug: made changes to comments more
complete, added rounding ("+ 500") and also adjusted Configtool
for the change.
To the best of my bash script knowledge, this also means we have
to break on the first error, because pipe terms run in a subshell,
so they can't pass variables to the parent.
Add a test that puts the stock config files through the
Configtool input/output parsers and verifies the output matches
the input. If Configtool breaks down in the future and produces
different output, this should catch it.
If this fails because of some intentional change in the tool or
in the stock config files, then the tool or stock config files
should be updated to be compatible again before merging the result.
(Ab)use the old Gen7 v1.3 configuration for this, as this is
rarely in use and because this board also happens to be the board
where the tested code was developed on.
Having a choice with a defined set of options is nice, but it
also requires these options to be #defined somewhere _before_
entering config.h. To keep class-like encapsulation, we'd need
two header files for each code unit, one for the options, another
one for the usual header.
That said, we use other examples of such options, e.g. CPU, F_CPU
or KINEMATICS. For CPU and F_CPU it works fine, because their
options are numbers or other values known by the compiler. For
KINEMATICS it kind of works, because this #define is used in only
one place ... and there it's suboptimal already, because no option-
set.
Anyways, I was unsure about this change and if it turns out to be
a poor decision later, it can be reverted.
Most work by Ruslan Popov, collected from various commits and
made compatible with regression tests by Traumflug.
Display test code is now enabled by #defining DISPLAY_BUS to
i2c_twi.
Implemented and tested for both platforms. This is quite a big
commit. Unlike with the previous changes to now choosable PWM
frequencies, all board configuration files and Configtool had
to be changed immediately to deal with the additional parameter
in DEFINE_HEATER() and keep AVR builds working (and regression
tests passing).
These were dropped accidentally, I assume, during the Configtool
template conversion. Without them the INTERCOM feature does not
compile and so board.gen3.h is broken.
Add the gen3 config to testcases and regressiontests to ensure
this does not drop again.
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>
Markus Hitter
wurstnase
Phil Hord
Ruslan Popov
Witold Sowa
Phil Hord
jbernardis