Jitter is the problem with running an operating system which happily delays your interrupt service.

The ARM micro's come with numerous timer channels and you can prioritise the interrupts. However I like to use a single timer for stepping because it makes it darned easy to keep the accelerations/decellerations in synch. I buffer incoming data from the host PDQ then handle it in background so it doesn't interfere with the stepping.

Two timer interrupts per step, one to set the STEP lines for any steps required, one to step everyone who is primed to go. Makes for nice square pulses and good settle time on the direction lines.

I like to smash my arcs in to individual straight lines in a buffer to keep the timer interrupt fast and simple. The timer interrupt fetches the next when it exhausts the one it is doing.

A line has 3 seperate components, acceleration steps, constant speed steps and decelleration steps.

Lines also have 3 slope values, one for each axis. Basically a number which you add in to a tally and if the tally carries that axis steps.

If the PAUSE button is pressed things get a bit hairy, every step becomes a decelleration step. It tallies decellerations so it can update the buffer to get back up to speed if it gets unPAUSEd.

If you smash the arc into enough segments you keep within 1 step resolution. I check the angle at which individual lines intersect and use a table to guess-timate how fast it is safe to take the corner. My PC does the arc to line/speed conversion with no appreciable delay and I am sure the ARM is up for it.

My mill runs it very smoothly with an 8MHz, 8 bit micro crunching 24 bit numbers. With 32 bit registers it should be a doddle, I could do the whole interrupt in ARM assembler nil problemo.