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)
The problem was, that settings distributed in
configtool.default.ini were overridden once a configtool.ini was
created. Accordingly, users upgrading sources wouldn't see changes
in this file.
The solution is to move settings set by the distribution into a
separate file which isn't replaced by a user-saved one.
This should fix issue #142.
The Steinhart-Hart algorithm allows more precise thermistor
tables, but also requires more parameters, which aren't
available for all thermistors. Accordingly, add support for both,
the traditional logic using the beta parameter as well as the new
one.
This also adds thermistor-presets, so users can simply choose
from a pulldown-menu to set their thermistor.
Also, identical thermistors get merged into one table, saving
binary size.
Last not least, a few bugs in this area got fixed.
Usually, all these things go into separate commits, but they were
contributed all in one and separating them is a bit error-prone
for little gain.
This should address issue #130, #134 and #135.
This is the expected outcome, so explicitely reporting this, with
requiring the user to click a dialog box away, is kind of clutter.
This should solve issue #136.
It's rarely a good idea to overwrite files coming with a
distribution. Not for users, because they can't reset to factory
values; not for developers, because Git would pick up such changed
files.
Instead we read from configtool.default.ini now, but write to
configtool.ini. If configtool.ini is already present, it's
prefered over configtool.default.ini.
Phil Hord
Markus Hitter
jbernardis