Nico Tonnhofer

A small test in the simulator. Clocks measured in dda.c at the two places where the sqrt is calculated. IntSqrt ``` dda->c = (uint32_t)(pgm_read_dword(&c0_P[dda->fast_axis]) * InvSqrt(dda->n)) >> 1; FLASH :...

Looks pretty good. Unfortunately little bit more flash. I add a atomic section to ignore the interrupts. Strange that the times increase. Probably some issues with the simulator? int_inv_sqrt: ```...

22 clocks makes sense when: ``` if (dda == NULL) return; ``` In the spike are 3 more steps. hmmm... ``` s.......s.......s.s.s.s.s.......s.......s ```

No. Maybe c_min is wrong. I need to check this.

~It is some rounding problems.~ In this spike come some parts together. rampup_steps = 65 rampdown_steps = 66 move_step_no = 65 rampup_steps < move_step_no == False rampdown_steps >= move_step_no ==...

 The two downspikes in the end is bresenham. Looks more wrong than it is. Just one step less in this move.

Thanks for your contribution. Your approach will work excellent on single axis movements. But unfortunately not on multiple axis movements. Movements are dependent on each other. The one axis with...

Solved! And should be now a little bit easier to understand what happens there :) https://github.com/Traumflug/Teacup_Firmware/commit/301c5ed149d Also saves ~12bytes.

While working on this I found another issue. With https://github.com/Traumflug/Teacup_Firmware/commit/8a4cd52a68ad9 we force c_min to be set after rampup_steps. This is the right way, but in the homeing process it looks...

Please check https://github.com/Traumflug/Teacup_Firmware/tree/home_overflow