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).
Previously, when backing off of X_MIN, X_MAX was also checked,
which of course was already open, so it signals endstop release
even while X_MIN is still closed. The issue exposed only when
endstops on both ends of an axis were defined, a more rare situation.
Essentially the fix simply makes a distinct endstop check case
for each side of each axis.
This even makes binary size 40 bytes smaller for the standard case.
Offending code were lines like these from Repetier Host:
N8965 M117 ETE 29m 10s *86
When firmware received not-G command (M-command or T-command) with X, Y,
Z, E or F coordinate, it will "change" this command to G1.
Now, firmware do change only if received line is not either G- or M-
or T-command.
Examples:
X10 - is changed to G1 X10
E20 F300 - is changed to G1 E20 F300
M117 E1 - is NOT changed to G1 E1
This commit costs 6 bytes binary size.
Markus Hitter
jbernardis
konoppo