Instead of converting them to absolute first, then back to
relative and having all the fuzz with working on the queue's
start vs. working at the queue's end, mark a movement as relative
and use this directly.
This is a intrusive patch and for now, it's done for the X axis only.
To make comparison with the former approach easier ...
The advantages of this change:
- Converting from mm to steps in gcode_parse.c and back in dda.c
wastes cycles and accuracy.
- In dda.c, UM_PER_STEP simply goes away, so distance calculations
work now with STEPS_PER_MM > 500 just fine. 1/16 microstepping
on threaded rods (Z axis) becomes possible.
- Distance calculations (feedrate, acceleration, ...) become much
simpler.
- A wide range of STEPS_PER_M can now be handled at reasonable
(4 decimal digit) accuracy with a simple macro. Formerly,
we were limited to 500 steps/mm, now we can do 4'096 steps/mm
and could easily raise this another digit.
Disadvantages:
- STEPS_PER_MM is gone in config.h, using STEPS_PER_M is required,
because the preprocessor refuses to compare numbers with decimal
points in them.
- The DDA has to store the position in steps anyways to avoid
rounding errors.
& tests of the debug_flags. Currently the compiler is able to eliminate
the block and the & operation when the constant is zero, but since
the debug_flags variable is a volatile the compiler does not eliminate
the load of the variable. By pretesting and shortcutting the load is
eliminated. Saves a small number of bytes when the debug build is
disabled and costs nothing when it is enabled.
This is without accuracy or other losses and should finally make
decfloat_to_int() free of variable overflow within the decribed
ranges. Surprisingly, this costs 14 bytes program size.