The project is a mess: need to deprecate driver-specific crates, update documentation, do a release

[JomerDev]

Is the A4988 driver actually supported? There is conflicting information between the repo and the docs:

The readme links to a A4988 driver crate, but the crate doesn't exist. The documentation on docs.rs doesn't mention the A4988 at all, but mentions a driver that the readme in this repo doesn't mention (DQ542MA).

[hannobraun]

Thanks for opening this issue, @JomerDev. This is a mess :smile:

Here's what I can gather:

• A4988
  • It is supported.
  • No crate for it was ever published. It can be used via the stepper crate.
  • That a crate is mentioned in the README is simply a mistake that I didn't catch in the review.
  • It's not mentioned on docs.rs, because support was added after the most recent release.
• DQ542MA
  • It is supported.
  • No crate for it was ever published. It can be used via the stepper crate.
  • Nor was it ever added in the README.

Some thoughts:

• The idea behind every driver getting its own crate was to improve discoverability. I still think it's an okay way to do it, but keeping that up-to-date requires more maintenance bandwidth than I have available for this project. I'm inclined to just deprecate all the driver-specific crates and only support the stepper crate going forward.
• The README needs to be updated. It should mention all supported drivers. If driver-specific crates are indeed deprecated, links to them should be removed.
• Once all of that is taken care off, a new release should be published.

This doesn't seem like a lot of work, overall. But priorities being what they are, I'm unlikely to find time for that soon.

If somebody wants to volunteer, I'm happy to assist with guidance, reviewing pull requests, and doing cargo publish where required. But this needs a contributor to do the legwork.

[dsluo]

In the Arduino world, AccelStepper and FastAccelStepper only control the movement of the steppers via step, dir, and enable pins, and don't really concern themselves with the drivers. Something like the A4988 is probably fine without a library, but the Trinamic drivers have the TMCStepper library to handle the UART communication with the driver.

The same approach for this crate make sense to me.

[hannobraun]

This project is also focused on STEP/DIR/ENABLE pins. Any drivers with a different interface are definitely out of scope.

There are two reasons we still have driver-specific code in here:

• Driver chips differ in the signal timing they require (which is usually documented in their data sheets).
• Different driver chips differ in the microstepping modes they support.

The driver-specific code enables this library to provide a unified interface, without requiring the user to know about timings or which pins to set how to get a specific mode. And it's really not a big deal to have that.