Hello,

I'm new to rust and this library but giving it a go :)

I am unable to call the sync_read functions as they require a generic type F, which doesn't appear to be used in the function (only in the callback function)

If I remove it I am able to use the sync_read function without needing a generic F

Is there a reason the F is there?
I'm enjoying using your well written library and plan to extend it to include fast sync read at some point :)

If a hardware error occurs it is flagged using bit 7 of the status packet error byte (https://emanual.robotis.com/docs/en/dxl/protocol2/#error)
Currently this causes the read_status_response to return a Err(MotorError) type with the raw field set to the error byte.
This behavior isn't helpful as it prevents reading data from the motor, in particular the hardware error register.

I think it should be restructured so MotorError is only return if bits 6 ~0 are set. And a new error, HardwareError type be defined, wrapping the response field.
This is non trivial as it involves wrapping the <Response<ReadBuffer, WriteBuffer> type

Keen to hear input on other implementations before I go with the first one I thought of lol

Sorry for another issue. Just want to say I am loving using this crate and appreciate all your work! I've learnt loads from it.

Currently, most functions (bus.write, bus.read) expect a response but a response is not always given.

	bus.write	bus.read
id: BROADCAST	no	no
status return level register = 2	yes	yes
status return level register = 1	no	yes
status return level register = 0	no	no

I'm encountering this issue mostly when sending packets with id: packet_id::BROADCAST

My current work around is to use bus.write_instruction when I know a response won't be returned, but this is a bit low level.

A few options:

• We add functions that don't expect responses, like write_no_response, but thats a lot more functions if we do it for every write and read fn. We could just to do it the two main ones write and read
• We add a parameter to the functions, probably something like response: bool

What do you think?

Hello!

I am looking at developing for a no_std environmet and I would like to use this library.
There is good flexibility with the ReadBuffer and WriteBuffer generics but its locked into using SerialPort. I know this has given greater control than just using the std::io::Read/Write traits. Would you be open to considering making the serial_port field of the bus an interface trait to allow other interface implementations?

Other barriers to no_std are the use of

• Duration and Instant in the timeout,
• std::io::Error,
• Vec in various return types,
• std::borrow::Borrow in bulk_write, can be easily switch to core::borrow::Borrow

My use case is actually developing a device/peripheral which uses the dynamixel protocol for receiving communication. As in it receives Instruction packets, parses them and responses with a StatusPacket. Similar to how the Dynamixel2Arduino Slave mode works, if you are familar with that. https://github.com/ROBOTIS-GIT/Dynamixel2Arduino/blob/master/examples/advanced/slave/slave.ino
This could exist as a seperate crate, or if you are interested it could be added to this crate. It would add methods to received and parse Instruction Packets and methods to return a response packet. I began planning it only to realise it would reuse many of the same elements already developed for this crate (ie the instruction_id consts, the find_header method and general architecture)

Let me know what you think :) I have time to impl most of this

Hi,

First of all, thank you for this very useful crate, I was wondering if there is any plan to have asynchronous features for it.

If not do you have any suggestions on how that can be contributed?