|
Message
From: "Peter Teng" <peter_teng@e...>
Date: Thu, 11 Jan 2001 13:46:17 -0800
Subject: RE: [usb] Endpoint Numbers
Rudolf,
Since you have suggested to user configuration by compilation, maximum of
31 can be all in place (reserved in addressing). It is only up to the user
configuration, to incorporate the register implementation upon compile time.
In this case, whatever register implemented is the one user need. And 4
register bits are saved from corresponding the register addressing to
endpoint numbering.
If you are planning to implement some sort of standard off-the-shelf
products, that there will no changes can be made to the design, then I will
agree with you. Since this allows flexibility to the software engineers to
tailor the design to suit his needs.
For multiple buffering discussion, let separate the discussions into
1. multiple transactions per uframe
2. the other types
The one I was talking about is about one transaction per uframe. So one
large buffer incorporating all smaller buffers. It is not necessary that for
each transaction to use up all the space in the smaller buffer. All my
intent was to save buffer pointers given that they all belong to one
endpoint. There is no reason to separate them out in different locations.
And for multiple types, then your comment is right. But I don't understand
what you meant by "real challenge for software". That is what pingpong
buffer is used for typical if I understand your comment correctly.
If you don't see my response within 24 business hours to your email, please
email me using pteng@m..., pteng@y... or peter_teng@e..., 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
Mailing address
Olcott Building
2880 Scott Blvd., M/S: SC2302
P.O. Box 58062
Santa Clara, CA 95052-8062
Tel: (408)9692766
Fax: (408)9692435
Email: peter_teng@e.../pteng@m...
-----Original Message-----
From: owner-usb@o... [mailto:owner-usb@o...]On Behalf
Of Rudolf Usselmann
Sent: Thursday, January 11, 2001 11:46 AM
To: peter_teng@e...; usb@o...
Cc: Jennifer Shou
Subject: Re: [usb] Endpoint Numbers
on 1/12/01 2:18, Peter Teng at peter_teng@e... 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@m..., pteng@y... or peter_teng@e...,
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
>
|
 |
Browse
