Takes about 5ms for a read/write

[CaptainKAZ]

I measured the communication time and found that an RW operation for a single axis takes about 5ms, which is super inefficient. It can only support one odrive with 2 axises running at 100hz.
May be use asynchronous API of libusb can speed up the communication and make it possible for multiple odrive running at high frequency

[borongyuan]

Thanks, your report and suggestion has been noted. Many people have asked about communication performance before, but we have not tested it. I will investigate your report later.

[borongyuan]

Hi,
We've recently been thinking about refactoring and addressing this issue. But it's actually more complicated. The main problem is that ODrive uses a request-response communication method. If you want to read a data, you need to send a request from ENDPOINT_OUT first, and then get it from ENDPOINT_IN. The operation of a single ODrive should always maintain the order of "request-response-request-response...". I don't know what happens if this order is broken. But we need to figure out how libusb behaves when multiple transfers are submitted. Here are some related discussions.
libusb/libusb#1077
libusb/libusb#1205
If the order cannot be guaranteed when submitting multiple transfers at the same time, we need to submit the next transfer after one transfer is completed. At this time, using asynchronous API is still expected to reduce the overhead of allocation and filling.
We need to first minimize the communication time with a single ODrive. For multiple ODrives, communication can obviously be parallelized. It can be implemented at other levels even without using the asynchronous API.