Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

host to device transfer size #1

Open
lmirel opened this issue Apr 8, 2022 · 3 comments
Open

host to device transfer size #1

lmirel opened this issue Apr 8, 2022 · 3 comments

Comments

@lmirel
Copy link

lmirel commented Apr 8, 2022

Hi, I've tested on Raspberry PI 4 and BeagleBone Black and on both there seems to be an issue with data from host to device.
The issue may come from raw-gadget itself but I'm not sure what would be the right approach.
It seems that when we get data from the host, it could contain more than just one packet (up to info.eps[i].limits.maxpacket_limit) which aside from the weird behavior on the actual device, it may also get lost when sent via libusb_interrupt_transfer in send_data (I'm unable to actually verify this on the device).

On BeagleBone Black I can see this when adding traces for data reception in ep_loop_read:

#[email protected]>481B/0x07/out
#[email protected]>545B/0x07/out
#[email protected]>481B/0x07/out
#[email protected]>545B/0x07/out
#[email protected]>545B/0x07/out
#[email protected]>481B/0x07/out
#[email protected]>481B/0x07/out
#[email protected]>481B/0x07/out
#[email protected]>481B/0x07/out 
#[email protected]>417B/0x07/out
#[email protected]> 33B/0x07/out
#[email protected]> 33B/0x07/out
#[email protected]> 33B/0x07/out

Meaning that at 253.250 (sec.ms) from starting the proxy it received 480 bytes (see first message - I added 1 byte because I am preserving the endpoint info for my own use).
Sometimes the transfer size equals actual payload like in the last 3 cases where 32 bytes were received.

On BeagleBone Black, the maxpacket_limit is reported to be 512 for the EPs assigned for use via proxy.
Any chance this can be tuned to only process one message at a time?

On Raspberry PI 4 the behavior is worse as it transfers 1024 bytes at a time most of the time and sometimes it gets blocked for a second with no transfer at all but the Raspberry PI is somewhat known to exhibit USB issues.

The transfers from device to host don't show any issue and they respect the expected message size.

Thanks in advance for any feedback

@lmirel
Copy link
Author

lmirel commented Apr 9, 2022

solved it like this for lack of a better option.
feel free to close this

@AristoChen
Copy link
Owner

Hi,

First of all, thank you for the interest in this project.

May I know what USB device you are using with this project? I would like to try to reproduce this issue if possible.

There are still some bugs and some code temporarily put there because I haven’t had enough time to think thoroughly yet or lack of relative experience, I will find some time to write a TODO in README.md in the future, and feel free to let me know if you found anything weird in the code, thanks!

@lmirel
Copy link
Author

lmirel commented Apr 11, 2022

I use a gaming controller (steering wheel) to pick up the data and extrapolate some ‘telemetry’ for driving a motion platform see https://github.com/lmirel/mfc
The controller is very fast, polling at 5ms and I had to tune the priority and remove the debug messages. I’ll update the tool as I tune it.
rPI4 would have been perfect but it blocks the input endpoint for a few seconds at some point in time and that makes it unusable.
You could try to reproduce that as I’m curious to see if my setup is the issue and not the rPI4.
Thanks for your effort and this nice idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants