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.
It's also possible to do this by stringifying MCU, but this
requires double redirection, which isn't easily readable in a .c
file. For stringification, see the bottom example at
https://gcc.gnu.org/onlinedocs/cpp/Stringification.html
- "Traumflug" and "Markus Hitter" are the same, mention him only
once.
- Add more common F_CPU choices in comments.
- Hint to another choice in Makefile-example.
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.
Forgotten in commit 74808610c7,
"DDA: Move axis calculations into loops, part 5.".
This and the previous commit makes ACCELERATION_TEMPORAL building
(and working!) again.
Next time, please at least try to compile the code section in
question when explicitely changing the section. In this case,
with ACCELERATION_TEMPORAL enabled. It didn't build.
Was broken with commit 95926a3f113809bde8ff0c84b94c55c73e398f67,
"DDA: Rename confusing variable name.".
Original author @triffid about these files:
"The idea was to be able to program another board from your
electronics without PC intervention, but reprap never seemed
to go down that road."
Should solve Issue #115.
As they're all converted, they're no longer of any use. Still
they were kept up to this commit to allow comparisons between
old and new config.h system.
Likely users don't care too much about the name of the saved file,
so they likely use the default ones. If they mess up, they also
likely want to return to the original, but, d'oh, it's overwritten.
Don't let this happen, enforce a non-original file name for user
saves.
In other words: don't let users shoot themselfs into their foot.
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>
This should convert all files checked into the repository to
LF line endings, with exception of pictures and PDFs. Trying
to commit CRLF text on Unix will issue a warning when doing
"git add" or "git commit -a".
Users prefering CRLF (Windows) can set their local copy of the
repository to convert files on the fly at checkout with
git config --local core.autocrlf = true
Note: Git acts pretty stubborn on files which don't match the
.gitattributes rules, but are already committed. This can
happen after every change to .gitattributes. Git doesn't want
to keep these files as-is in the repository and insists on
conversion as soon as they're touched somehow. The only way to
deal with this is to either edit .gitattributes again (in case
these enforced conversions don't match the intention) or to
commit the enforced changes immediately.
To put a bit more oil into the fire, Git doesn't recognize all
misalignments immediately, but trusts its cache. Accordingly
it's a good idea to clear this cache after any change to
.gitattributes:
rm .git/index
Having this done, all further proceedings will show all
misaligments immerdiately.
For further instructions and descriptions see
http://schacon.github.io/git/gitattributes.htmlhttp://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/http://git.661346.n2.nabble.com/possible-gitattributes-eol-bug-with-new-eol-crlf-lf-support-td5516458.htmlhttps://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings
As we can always only move towards one end of an axis, one common
variable to count debouncing is sufficient.
Binary size 12 bytes smaller (and faster).
Markus Hitter
jbernardis