stepper pulses duty cycle and optimization

I'm trying to stretch the arduino limit, for running faster with my steppers. I want to go as high as 500 mm/sec, with accelration as strong as half G. for that I need a very smooth stepping pulsing. I have the hardware for that...
I notinced that marling creates pulses not in an optimal way, for example, the pulse duty cycle isn't 50%. as for now the pulse is generated like this:
pulse timer interupt -> ...
for axis x,y,z,e, do this serially:
WRITE(*_STEP_PIN, !INVERT_*_STEP_PIN);
counter_y -= current_block->step_event_count;
count_position[Y_AXIS]+=count_direction[Y_AXIS];
WRITE(*_STEP_PIN, INVERT_*_STEP_PIN);

so the pulse width is determined by the arduino's CPU. (BTW, if someone will ever try to run marlin on arduino DUE, this function will have to change alot any ways)
I would have done it in another way, by creating an timer interrupt for the pulse down. if possible do it together with another axis pulse up/down.
if also possible, write pulses on some axis together, like this:
THE_CPU_BYTE_THAT_REPRISENTS_THE_OUTPUT_PINS |= *_AXIS_PULSE | *_AXIS_PULSE

My question is, was there any work done on this task, and is it needed at all?

The rising flange pulses the step, the falling flange of the signal doesn't matter as long as the time between both flanges is long enough to have the driver recognize the signal. Allegro driver chips are known to recognize step pulses as short as 2 ATmega clock ticks; this delay was introduced for slower chips like the Toshiba TB6560.

If you want smoother steps, you have to make sure the rising flanges are evenly spaced. Also checkout Teacup firmware which is pretty good at this and allows up to 40.000 steps/second (experimental branch, on the cross branch with look-ahead).

Teacup even has ACCELERATION_TEMPORAL, which gives evenly spaced signals for all four axes by avoiding the Bresenham algorithm. Not well tested, but it's a start.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I don't think duty cycle matters all that much, so long as the rate of rising edges stays consistent. your limiting factor for speed will be governed by the size of coils in the stepper motor (which is why driving them too fast will skip steps). there's an excellent calculator for working out max RPM of a stepper motor here: [www.daycounter.com] which will let you workout the minimum pulse interval (e.g. for a 4.3mH coil, with max current 1A and 12V drive, the quickest it can step is 0.717 milliseconds per pulse or ~1.4Khz, which works out to around 6.9 revolutions per second - it's fairly fast, but on a GT2 drive belt and a 20 tooth wheel, that's only ~280 mm/s)

The actual speed rates will be governed by the mechanism driven from the stepper (toothed wheel, leadscrew etc). I suppose if you wanted to make it truly 50% duty, then the firmware can work backwards from the speed rates and double it, inverting on each cycle:

CPU_OUTPUT_BYTE = CPU_OUTPUT_BYTE ^ AXIS_DRIVE_PIN;

But you'll be calling the drive routine twice as often, so only getting half the effective pulse rate (which further limits your possible drive speeds). If you're microstepping, then you're reducing the speed by an appropriate factor - at 1/16 microstepping, you'll have to send 16x as many pulses for the same speed, which means 22.3khz drive rate (for the example application) at max speed - so you start running into limits with the CPU speed if you insist upon having 50% pulse width (double calling the drive command means you have to drive at 44.6khz - which is really fast!) - I suppose you can trade off speed for accuracy - it's your call

I'm limiting my application to 250mm/s and 1/4 g acceleration