Re: [usb] Endpoint Numbers

[Rudolf Usselmann <rudi@asics.ws>]

on 1/12/01 2:18, Peter Teng at peter_teng@el.nec.com wrote:

> Rudolf,
> 
> Rudolf> The endpoint field in the CSR, is the actual endpoint number that is
> matched
> against the endpoint number in a token from the host. Basically this would
> provide a mechanism for changing the endpoint number if desired. I'm not
> sure if that is necessary or useful.
> Peter: Take your spec rev .4 as example, address 14 hex is pointing to the
> CSR of endpoint 1. This endpoint 1 (derived from the addressing) is used to
> compare the endpoint number from the token sent from host, right? Otherwise,

Wrong, the field in the CSR is used for that !

> why do you need to have another field for storing the endpoint number?
> And I have misleading discussion before. There could be an endpoint that can
> be served as both In and Out. This means a total 31 logical endpoints can be
> implemented. For example, endpoint 1 can be used for both in and out. But
> they are logically separated. This means you need to have two separate
> entries for describing them. In this case, you need to have 31 entries of
> endpoint registers to describe them all.

Ah, that's what I thought ! So I do need the endpoint field in the CSR.

I think I have you confused with my naming convention. When I refer to
endpoint 1 in the spec, that is the physical endpoint. It's logical endpoint
number can be different (that's what the endpoint number in the CSR is). For
example, the physical endpoint 1 and the physical endpoint 2, can be both
configured to be logical endpoint 3, one for IN and one for OUT operations.

You are right that the theoretical maximum for endpoint is 31. But I wonder
if I should even bother to offer that many endpoints. Sounds like a lot of
endpoints to me !

> Rudolf> I have now also added 4 buffer pointers and also size registers for
> each
> buffer, so I know how much data to transmit or I will set the size to
> indicate how much data I have received.
> Peter: Instead having more than one buffer pointers, would it be ok to set
> the restriction that the single buffer pointer points to the beginning of
> the buffer. While there is another field describing the number of buffer
> allocated. The buffer allocated shall provide the total contiguous space for
> all the number of buffer required. This saves some gates.

Hmm, lets see, so you are suggesting one large buffer, and I grab each time
MaxPacket size data, except for the last transaction which could be smaller,
right ?
I like it ! But, I think this would be a real challenge for the software, as
it would have to refill/read the buffer as I empty/fill. The next buffer
size could be different.

However, this would work with two buffer pointers, quite well. I would have
to update the pointer after each transfer to keep track where I am.


> 
> If you don't see my response within 24 business hours to your email, please
> email me using pteng@mail.com, pteng@yahoo.com or peter_teng@el.nec.com, or
> please call me direct. Sorry in advance for the trouble that may caused you.
> 
> best regards,
> "Peter" Chu Tin Teng
> Computing technology I/O Group
> NEC Electronics Inc.
> Physical address
> 3301 Olcott St.,
> Santa Clara, CA 95054
>