Add error propagation from the embedded_hal functions

[ripytide]

Also I though it might be nice to reduce the API surface by removing the drive_forward, drive_backward, stop and brake functions which make the library harder to maintain and also adds confusing redundancy as it leaves two ways of accomplishing the same thing, drive() vs the other commands.

I also renamed DriveCommand::Backwards to DriveCommand::Backward to match the non-plural DriveCommand::Forward command.

[rursprung]

thank you for your contribution!

some requests from my side (besides the comments in the code):

• please split this into atomic commits (and possibly atomic PRs; i'm still a bit on the fence about the last point)
  • one for the error propagation
  • one for Backwards => Backward (thanks for catching that!)
  • one for removing the APIs
• please use proper commit messages (also mentioned in the Git Book)

[ripytide]

While in future I will try to note your preference for atomic commits (apologies I forgot since last time you asked), I think it would be not worth the effort for me to split this into multiple commits as I'd have to re-do everything from scratch again.

I don't think its generally a great idea to expect open-source contributors (particularly new contributors) to stick to such a commit-schema as it may discourage committers without enough know-how of git from making pull requests.

[rursprung]

While in future I will try to note your preference for atomic commits (apologies I forgot since last time you asked), I think it would be not worth the effort for me to split this into multiple commits as I'd have to re-do everything from scratch again.

I don't think its generally a great idea to expect open-source contributors (particularly new contributors) to stick to such a commit-schema as it may discourage committers without enough know-how of git from making pull requests.

i think it's important to (try to) uphold the standards also (and especially) in open source projects, both to make them maintainable & understandable in the long-term but also to teach people the best practices.

for this specific PR i think it's fine if you squash the commits together and provide a nice commit message (you can go with a generic "refactor: streamline API and expose errors through Result" and then add a nice description to it - this way you can always claim that it's atomic enough 😉)

i think i'm ok with removing the duplicate methods. for the Result thing i'll briefly ping the rust embedded matrix room to see what the general consensus/recommendation on this is (seeing that the Result thing is a very new thing on the pins).

[rursprung]

@ripytide: sorry for the long delay here! rust-embedded/embedded-hal#576 has been discussed in the last rust-embedded meeting (see the meeting minutes) and the approach chosen here is considered best practices for no_std (with std there are cleaner/easier options).

could you please:

• rebase the PR
• squash everything into one commit with a nice commit message (see previous comment)
  ?

with that i can then ACK & merge it and we can get your other PR in as well and finally release this thing!

[ripytide]

@rursprung I have rebased and squashed the PR

[rursprung]

thanks a lot for this!