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

Restrict endpoint packet sizes at usb-device level? #71

Open
ianrrees opened this issue May 19, 2021 · 2 comments
Open

Restrict endpoint packet sizes at usb-device level? #71

ianrrees opened this issue May 19, 2021 · 2 comments

Comments

@ianrrees
Copy link
Contributor

The USB spec imposes some constraints on the max packet sizes allowed for particular types of endpoint. In the ATSAMD implementation of usb-device, we have a bit of code that panics if an endpoint allocation is attempted that doesn't fit requirements. My immediate problem is that code not allowing isochronous endpoints to be their full range of sizes (it's fine for an isochronous endpoint to have a max packet size of 200B for instance), but that code doesn't have visibility of the type of endpoint being allocated.

So, I'm wondering if it makes sense to have usb-device check that endpoint sizes are OK in terms of the spec, perhaps here - there will obviously be additional constraints imposed at the hardware layer, but this would have usb-device enforce the USB spec requirements, leaving the hardware requirements to the their implementations.

@stappersg
Copy link
Contributor

afbeelding

An year later: For which reason is this issue still open?

@ianrrees
Copy link
Contributor Author

Hi @stappersg , thanks for your interest! I have not been working on Rust USB firmware for a few months, but believe that this is still a valid suggestion. The project I was working on at the time is using a fork of usb-device which adds support for #33 and DMA but I never actually implemented a solution to this particular issue so can't immediately PR one.

This crate only was moved in to rust-embedded-community recently, because the original maintainer was no longer keen to maintain it - there is a backlog of work to catch up on, and I think this fits in to that category.

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