Re: [usb] USB pipes

[Rudolf Usselmann <rudi@asics.ws>]

Mike,

thanks for the feedback !

How about the following:

I will use a local memory buffer, say 4-16K (user selectable).
in that local memory, sw can set up a linked list of end points
and various attributes of the endpoints, as well as pointers to
in and out buffers. Since all transfers are initiated by the
host, I can notify the sw (via one interrupt) when there is
activity. Each thread would know the location of it's endpoint
in the linked list and could acess that memory directly and
check for activity.

The only reason it is a linked list is to make the hardware
simpler ....

So for example each entry in the linked list would look something
like:
<endpoint no>
<attributes/ctrl/status bits>
<pointer to in buffer>
<pointer to out buffer>
<pointer to next end point entry>

Any time a pointer is all 1's, it is not allocated and I would
do the appropriate exception in hardware and notify sw.

Further, sw can allocate certain amounts of memory to each thread, and
keep multiple out and in buffers, and just charge the pointer in the list
when the previous buffer has been used.


on 12/31/00 9:17, mike kelly at mike@cogcomp.com wrote:
> Rudolf,
> 
> I don't see myself as a USB expert, but I have developed a number of
> systems using USB, and in each case the number of endpoints was very
> critical to the software folks.  Since each endpoint might be controlled
> by a single thread or task, sharing endpoints creates a fair amount of
> overhead to allow the passing of semaphores, handling interrupts, etc.
> Obviously more is better, but as you say, there are finite limits in
> hardware.  My sense is that for embedded use (my area) 4 endpoints
> plus 1 control endpoint is a minimum amount.  8 may be overkill, but
> if it is a HW compile time option than it seems like a good upper
> limit.
> 
> One other point, it is important to allow the endpoints to be
> programmable by software for Bulk or Isochronous transfers.  The need
> to handle both types can change on the fly during use.
> 
> Michael Kelly