The small stepper drivers like the DRV8825 have digital inputs and work perfectly directly connected to a 3.3V output.
I have been using the DRV8825's and just bought some DM542T's, so these two threads and their solutions are exactly what I needed to understand the problem. The DRV8825's accept anything over 2.5V as logic high, so as you say they work perfectly with Teensy's. The DM542T specs aren't as clear, but look like they need 4-5V minimum.
DRV8825 specs --and--
DM542T specs
Anyway, I can add a corresponding command to the lib if that makes usage easier.
I don't think a command is necessary, but incorporated in an example, just to show how to de-enegize coils when not in use, might be a good snippet in the Readme.
If you describe what information / examples would be useful for you (and probably others) I can add a few chapters to the readme.
First of all, let me say that your library is very well thought out and designed. Although I haven't switched over to it yet, I have read through the documentation numerous times to familiarize myself with it before transitioning, and I think your documentation covers the expected cases very well. You have solved very important problems (simultaneous arrivals), and identified the critical use cases. You have included code snippets for most of the library functions / commands. I'll be transitioning soon, so I know I will personally have more questions.
That said, because I have used Accelstepper for many years, having read and contributed to
the support forum as well, here are the areas that I think need explicit examples to make getting up and using TeensyStep easier:
Simple, complete,
compilable examples showing how best to work simultaneously with other "competing" system resources, e.g.:
1)
Getting input from pins - most critically reading buttons, encoders and analog devices like a pot e.g. three specific examples:
- A run / stop (overloaded state) button (and possibly dir button - would show complexity of using two state buttons simultaneously)
- Variable speed set using Paul's encoder library (this was a challenge for me personally, so I know how hard it can be, e.g. increase / decrease speed based on knob rotation, extra credit for bumping up the speed increment if knob is rotated faster ;-)
- Variable speed reading a pot on an analog pin (lots of beginners have issues with reading a pin occasionally, rather than every pass through loop(), simple interrupt based example would be fine too, but must be complete and commented)
2)
Output to pins - something simple like lighting an LED, in conjunction with motor movement, that users can expand to other output, say at the end of a motor cycle (e.g. motor has finished moving, now trigger a camera shutter).
3)
Serial communication - this is the main area that causes huge problems in Accelstepper performance due to architectural delays. Serial output for anything from debug (println), to getting keyboard input. I don't know what user expectations are for serial usage while moving motors, but there are lots of questions that arise (and performance limitations especially using an Uno and motors, which TeensyStep circumvents for the most part).
4)
Display output - Another area where simultaneous use of devices with motors causes issues and lots of questions. I don't have a good baseline to suggest here, but it is clearly desirable. My own use has almost always involved a display and / or touchscreen for UI, so I have always faced challenges here. I'm not sure an example is easy to create, but advice for how best to work with SPI, I2C and serial devices for output would be very useful (I'm currently using
serial touchscreens from Nextion - enhanced version with flash for pre-installed screens, but have also used
Paul's ILI9341 Color Touchscreen, as well as simple 20x4 LCD's). Because there is no standard here, this could be a quagmire, but perhaps you can come up with a suggested framework (pseudocode?) for how to cooperatively communicate to output devices in general? If there was a "standard" a great example would be current position output to a screen, similar to a DRO.
I hope that helps, and thank you again for the outstanding work, and for sharing TeensyStep with the rest of us.
--Jon