Expect that nusb::transfer::Buffer expose more APIs

[wangxiaochuTHU]

Hello, nice to see nusb version 0.2.1 which I think is easy to use.

After a simple tryout, two major issues confused me.

1. My use case needs to copy from only partial data of nusb::transfer::Buffer, but it seems that I cannot get a view : &[u8] from this structure. It is expected that you could add a method to achieve this, saving the user from turning Buffer into Vec.
2. When I turned Buffer into Vec at first and then turned Vec back to Buffer for re-use purpose, I found that the len of the Buffer has changed (actually, the length may become smaller since the transfer is not completely full), which is harmful to reuse. What is your idea about this?

Thank you!

[martinling]

1. Buffer implements Deref<Target = [u8]>. You can call buffer.deref() to get a &[u8]. In most cases you can just treat the Buffer as if it were a Vec already.
2. In nusb 0.2 it's not possible to turn a Vec back into a Buffer any more, so this is no longer a concern. If you want to reuse a buffer you just keep it as a Buffer.

[wangxiaochuTHU]

1. Buffer implements Deref<Target = [u8]>. You can call buffer.deref() to get a &[u8]. In most cases you can just treat the Buffer as if it were a Vec already.
2. In nusb 0.2 it's not possible to turn a Vec back into a Buffer any more, so this is no longer a concern. If you want to reuse a buffer you just keep it as a Buffer.

Great, sorry for not notice that, then my use case would be fine.

[wangxiaochuTHU]

Btw, as just tested on my Win11 system, it seem that Buffer is required strictly that its length should be equal to N * MaxPacketSize with N being an integer.

I feel that sometimes the transfer may be short (e.g, 16 or 32 bytes), so I wonder why it is designed like this, or would it possible to relax the restriction?

[martinling]

The USB protocol allows the device to send anything up to the maximum packet size when it is polled with an IN token.

If the buffer is say, 16 bytes, but the device sends a 17 byte packet, that's a problem, firstly because there's nowhere to put the extra byte, but also because there's no way to even indicate to the rest of the stack that there was an extra byte.

So at the low-level interface to the USB host controller, there's a requirement that a buffer be a multiple of the maximum packet size. That way, there's either space for another packet or there isn't.

If you want to deal with odd-sized reads and writes more easily, you may want to use the adapters in the io module

[wangxiaochuTHU]

The USB protocol allows the device to send anything up to the maximum packet size when it is polled with an IN token.

If the buffer is say, 16 bytes, but the device sends a 17 byte packet, that's a problem, firstly because there's nowhere to put the extra byte, but also because there's no way to even indicate to the rest of the stack that there was an extra byte.

So at the low-level interface to the USB host controller, there's a requirement that a buffer be a multiple of the maximum packet size. That way, there's either space for another packet or there isn't.

If you want to deal with odd-sized reads and writes more easily, you may want to use the adapters in the io module

Ok, thanks for the explanation.