That code looks like Arduino 'language', yes?
I guess from your comment "I'm not sure how to decrease the wait time less then 1 millisecond" you are new to it.
delayMicroseconds(500);
is 1/2 a millisecond.
So there is plenty of resolution to use.
History, experience, and hard evidence show that people are very poor at identifying the areas of a project that will cause problems. So I recommend you make everything as simple, easy and quick as practical to implement. Get something realistic working early, and use that to discover and understand the actual, interesting, and useful problems to solve.
I recommend you do NOT vary the step resolution dynamically.
So, though it is very unlikely to harm the motor or driver, dynamically changing stepper resolution will introduce extra complexity. In software we talk about 'premature optimisation'. The extra complexity of early optimisation (especially before the problem is properly understood) hampers efforts to get a system working, or improve it. In this project complexity may get in the way of achieving the motors best performance. Worse, the complexity may allow the system to be inconsistent, then making positive changes becomes horribly hard.
Use microstepping from the start, to discover the limits of your hardware and software. It'll be easier to reduce microstepping resolution if you hit problems, than increase it if everything is working at worse resolution.
Microstepping produces smoother motion than simpler step sequences, and reduces resonance. So you might get better performance from it anyway.
I recommend you do NOT use software to drive the Easy Driver pulses. The millis() timer, I/O (e.g. Serial.print) and other parts of the system will introduce 'jitter', which is undesirable, and may confound some attempts to improve the motors performance.
Learn to use the ATmega's timers. They can be used to continuously generate rock-steady pulses without relying on software. IIRC, the Easy Driver can microstep the stepper motor at a constant speed forever without any software involvement. That gives you a stable platform to improve, with lots of flexibility on how you use software and CPU cycles to make the system work better.
Timer/Counter1 is particularly handy. All three timer/counters allow the fundamental counting frequency to be controlled via a clock divider (pre-scaler). This is a not very flexible as the pre-scaler can only divide the main clock by a few fixed values, 8, 64, 256 or 1024. This gets into the right ball-park, but is too crude to adjust the stepper pulse rate, and hence the motor speed.
However, the 16bit timer/counter can also have its frequency controlled precisely by loading a 16bit value which defines the counters frequency (the mode is called "Clear Timer on Compare Match (CTC) Mode")
So this can be used to exactly control the duration of each pulse to your stepper controller. So software could ramp the motor speed up and down in increments of a 1/2 microsecond, if needed.
Then you'll have the task of characterising the motor so that you can accelerate and decelerate it smoothly, and hence change position rapidly and reproducibly. This can take time, and is one of the reasons for trying to get a stable motor drive working early in a project.
You will very likely need to do experiments and measurements on the motor to figure out how fast it can be accelerated, decelerated and driven.
EasyDriver, like the vast majority of stepper controls, drives steppers 'open-loop', without feedback. Overdriving the stepper isn't detected, but will reduce speed and position accuracy. An overdriven stepper will fail to move as many steps as the software thinks it has gone.
A stepper's speed must be ramped up and down quite carefully for best performance. Most steppers will struggle to accelerate instantly even to quite modest speeds, and will lose synchronisation (destroying any ability to reach a specific position) if accelerated too quickly, or driven too fast.
Edit:
I noticed Sparkfun's EasyDriver page links to this article about driving a stepper motor using the EasyDriver. The article is helpful. It shows how to wire things up and quickly get started driving a stepper using the EasyDriver.
However, it may be misleading. It shows a software-only technique, using the millisecond-resolution delay()
function to generate the pulses for the EasydDriver. It does not even mention using hardware to generate the pulse-train. The article was written about 5 years ago, so it's a bit late to ask them to fix it.
Summary:
- Drive the stepper using timer-derived signals so that everything is
stable and reproducible.
- Use microstepping from the start, as that will give the smoothest
motion.
- Ditch the idea of using different stepping resolutions until you have
a problem it can help solve.
- Keep the system simple and consistent/uniform so that it is easier to
measure system behaviour or tune the system for good performance.
- Allow lots of time to test and measure the system if you want to
approach the steppers best performance.