Some target devices need extra avrdude command line switches to
get them to upload successfully. There are dozens of options which
may be useful to different people. Instead of breaking all the possible
options out into separate fields, provide a generic "Program Flags" text
field which the user can fill in similar to the CFLAGS and LDFLAGS
settings.
The Arduino Mega2560 bootloader was changed[1] to report an error when
asked to erase flash because it has never actually implemented erasing
flash. To program this bootloader with avrdude requires the -D switch
to avoid flash erase. But it seems that every arduino will work fine
with -D, as evidenced by the fact that the Arduino IDE always [2]
includes -D in the avrdude commandline. Presumably the flash is erased
during/before programming anyway and the separate erase step is unneeded.
Perhaps the -D should be always added to avrdude command line in
configtool and in Makefile-AVR. But I haven't tested any other boards
yet, and I'm being more cautious even though the Arduino IDE does
otherwise.
[1] arduino/Arduino#543
[2] d8e5997328/app/src/processing/app/debug/AvrdudeUploader.java (L168)
So far for choices based on boolean sets, only, because choices
for values typically need no more readable names.
This elegantly removes the somewhat ugly check for '(', too.
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.
Save a division at runtime by pre-calculating the slope between each
pair of adjacent thermistortable values. Since we use the larger value
each time, save the slope between two values A and B in the table
with the B data. Therefore the slope is that between each value and
its predecessor in the list.
Store this new value in the third element of the now 3-integers-wide
array which makes up the table. Use fixed-point 6.10 format to store
the slope. This is almost too narrow for some slopes and maybe it
should be changed to 8.8 fixed-point. In practice this presents a
loss in accuracy, but it is still significantly better than the
previous fixed-sample-size table production method. In particular no
provision is made to handle values which scale over 65535, and it
seems we should at least warn about this if not simply fail before
letting the user go off compiling his code.
Add a new flag TEMPTABLE_FORMAT and define it as 1 to tell the code
that we are using this new and incompatible format. This lets us
tolerate old hand-crafted thermistor tables by keeping the slower
algorithm in case one is still used. New thermistor tables should be
defined with this new format and with the FORMAT define set accordingly.
With the default 25 samples this adds 100 bytes to the flash image for
the thermistortable storage for two different thermistors. But the
code is simplified and saves me 134 bytes in the bargain for a net
decrease in flash size of 34 bytes.
The Thermistortablefile.py routine prematurely drops the
fractional part of the temperature when computing the 14.2
temperature values to emit in the code. Keep this instead until
the last moment when we finally calculate the integer format we
will store.
Temperature tables are emitted by selecting arbitrary sample values
to be used for the linear lookup table. This is fine in the range
where the thermistor produces linear output, but it is markedly wrong
near the extremes where the thermister output begins to curve.
Introduce a new sample selector which chooses samples based on the "most
incorrect estimate" and improves from there to ensure we get a cleaner
approximation across the selected range.
Traumflug: this topic is tracked here:
https://github.com/Traumflug/Teacup_Firmware/pull/208
Until this commit, the Z axis is disabled after each move and
only enabled when the Z axis will move. Now you can enable this
as a feature. Some printer axes are too heavy or have a high
pitch which are not self locking. In that case simply do nothing.
It's now off by default.
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).
This was forgotten with the recent move to storing configuration
items as tuples (value, enabled). It should fix the refusal to
build reported in issue #86.
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.
Previously they were evenly spaced across the temperature range,
now they're evenly distributed across the ADC range ... which
is not entirely the same.
This is related to issue #176.
This is, the parameter entry fields in the GUI, not in the
generated temperature table. Allowing floats is a tiny bit more
precise and also, more importantly, less confusing for the user.
--Traumflug
This is related to issue #176.
Previously, values of ignored keys simply got lost and were
replaced with the ones from from the metadata file. Now this
value is preserved and perhaps, some time in the future, we'll
use this bit of information to to provide the right value when
re-enabling it.
Previously they were dropped only at save time, which is too late
for the GUI. This is mostly for robustness, the case where a
value was removed from config files, but not yet from the GUI.
Shouldn't cause functional change.
So far, values commented out are still ignored, which is why the
used regexp changed. This will hopefully change in the future,
so a configuration can remember disabled values, too.
This solves the problem of choice menus being populated with too
many entries. Before, such menus would pick up values from
board.metadata as well as from the actually loaded file.
File printer.metadata contains no options, so no adjustment
needed there.
The idea is to open the user's email client automatically, so
(s)he has not much more to do than to write a sentence about what
went wrong. As easy as possible!
This is work related to issue #159.
Phil Hord
Markus Hitter
Ruslan Popov
Phil Hord
Witold Sowa
Wurstnase
jbernardis