no_std and use in peripherals

[omelia-iliffe]

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

[de-vri-es]

Hey!

Yeah, I'm definitely open to moving the serial port choice to a trait and adding the device side of the protocol.

Duration exists in core, but Instant does not. If we need to, we could have a top-level Platform/System trait that has a few associated types for things like what SerialPort to use and what type to use for Instant and Duration. The std::io::Error can be part of the trait that the serial port needs to implement. Then you would have Bus<ReadBuf, WriteBuf, Platform/System> (I don't want to tie the choice of buffer to the platform/system).

The only downside I see here is that the errors returned by Bus will become generic over the error type of the serial port. This tends to be a little annoying, but we might be able to provide some type aliases for the default platform/system to help with that if necessary (feel free to skip this, there is high bike-shedding potential here).

One thing I'm still thinking about: We should probably implement the client side and the device side in different structs. I don't see a use-case for mixing them (there can be only one node on the network sending instructions), and the Bus API is already quite large. Maybe Device and Bus? Or Device and Client (and keep Bus as deprecated alias)?

Of course, if we split the types it might make sense to add a private low level type that implements the basic message exchanges features, so the high level types only need to implement high level instructions on top of the low level interface.

[omelia-iliffe]

Awesome!
I think I will start with making the serial port generic and go from there. :)