asynchronous operations

[gabrik]

Hi, as mentioned in #1 here is a PR that implements asynchronous operations for interacting using the Dynamixel2 protocol.

Features

• Added the default sync feature for the current behavior and interface
• Added async_smol feature for asynchronous operation within async_std
• Added async_tokio feature for asynchronous operation within tokio
• Feature gated all the differences between the implementations.

There is still (a lot) a code copy-pasted from sync to async implementation, mostly because of the different signatures and await here and there.

I tested it on my MacBook with a OpenCR board, I'm really open to feedbacks

[de-vri-es]

Hey, just wanted to let you know I haven't forgotten about this yet. I'm a bit busy, but I will definitely make time for this.

/edit: And of course, thanks for opening the PR! :)

[gabrik]

I see that the build fails because of the --all-features flag in the CI configuration, I'll expand the configuration to build with different feature sets

[gabrik]

It should be fine now, tested locally, and on my fork, I had issues with the clippy action, but I guess it is because of the token.

[de-vri-es]

I haven't done an in-depth review yet, but it looks like now, enabling a feature changes the existing Bus into an async one, right?

In general, enabling features should not break code that doesn't need/use the feature. This is especially important because two crates might use the same dependency with different sets of features. It's not very likely for this crate, but we should still support it.

So I suggest a slightly different approach: each feature should enable a new submodule that contains the implementation for that back-end. So the tokio feature would enable a crate::tokio module that contains an async Bus. And the smol feature would enable a crate::smol module with another Bus. This way, all features can be used together.

The current implementation could be moved to a sync feature so we can even make the serial2 dependency optional. It would be neat to move that into a sync module too, and re-expose it at the crate root with deprecation warnings that point to the new sync module.

[de-vri-es]

Another thing that I was considering: it would be cool to see if we can still re-use the decode code. Maybe an internal decode module could help with that. And maybe the same goes for the encoding code.

The different async/sync implementations would then all call the same encode/decode functions, but take care of the reading/writing/buffer-clearing.

[gabrik]

Thanks for the comments, I'll rearrange the code as you suggested