Open ianrrees opened 3 years ago
An year later: For which reason is this issue still open?
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.
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.