`target` is an input to dda_create, but we don't modify it. We
copy it into dda->endpoint and modify that instead, if needed.
Make `target` const so this treatment is explicit.
Rely on dda->endpoint to hold our "target" data so any decisions
we make leading up to using it will be correctly reflected in our
math.
Note a performance improvement opportunity.
Review note by Traumflug: the original commit didn't add a
comment, but replaced the existing code with what's in the
comment now.
According to the comment in issue #223:
Pre-unroll:
LED on time minimum: 3138.44 clock cycles.
LED on time maximum: 5108.8 clock cycles.
LED on time average: 4590.58 clock cycles.
Unrolled:
LED on time minimum: 3016.92 clock cycles.
LED on time maximum: 4987.28 clock cycles.
LED on time average: 4469.06 clock cycles.
Add a function axes_um_to_steps to convert from um to steps on all axes
respecting current kinematics setting.
Extend code_stepper_axescode_axes_to_stepper_axes to convert all axes,
including E-axis for consistency.
It seems like axes_um_to_steps could be simplified to something like
"apply_kinematics_axes()" which would just do the transformation math
in-place on some axes[] to move from 'Cartesian' to 'target-kinematics'.
Then the original um_to_steps and delta_um code could remain untouched
since 2014. But I'm not sure how this will work with scara or delta
configurations. I'm fairly certain they only work from absolute positions
anyway.
Fixes#216.
This also introduces dda_kinematics.c/.h and a KINEMATICS definition,
which allows to do different distance calculations depending on the
bot kinematics in use. So far only KINEMATICS_STRAIGHT, which matches
what we had before, but other kinematics types are present in
comments already.
Phil Hord
wurstnase
Markus Hitter