Re: USB: Question about usb_write() API
As defined by the documentation, write is asynchronous, you can only
be sure write is complete when usb_ep_callback is called.
In practice, there are some hacks in current drivers to make write
block if previous one is not completed (active polling on FIFO for the
dw driver, semaphore for stm32 one).
Today there is no transfer concept at usb device driver level, you
only read/write the TX/RX hardware FIFO (usb_dw), this is up to each
class driver to manage packet splitting and transfer start/end,
including short/zero packet management.
This also means that class drivers need to know the endpoint FIFO size
to delineate packets and transfers. This is significant extra work for
each class driver and not really agnostic.
This is why I would like to introduce transfer concept, letting the
device drivers deal with transfer management.
The interface could be something like: usb_transfer(endpoint, buffer,
buffer_len, callback, flags)
The implementation is hardware specific but usb controller usually
have registers to program transfer size, packet count and IRQ to
indicate transfer completion, FIFO empty...
This is a simplified version of Linux USB Request Block (URB).
On 31 January 2018 at 09:28, firstname.lastname@example.org